SIPCORE, 78th IETF Maastricht, Netherlands

Status Overview (Reference agenda presentation slides posted in Meeting Materials)

Gonzalo Camarillo: Robert had comments after AD review. Now simplified and settled. Ready to go.

Security flows - issue of whether it waits for SHA-256. Cullen wants to get the present document done, and come back to SHA-256 later if needed. Needs to be cleared up with Security ADs.

RFC 3265bis - doesn't seem to be objections to changes proposed last time. Will be ready for WGLC as soon as the changes are made.

Cullen Jennings: had a question on flows draft accompanying RFC 4424bis, whether sub-addressing service should be separated out.

Location Conveyance

Keith Drage: Believes the authors did not have WG consensus to make the changes that have been made to the draft.

Jon Peterson: explained that this was better than nothing, because they were too late to submit individual draft.

Multiple Locations

Main issue is multiple locations. The essence of the changes made is that now we have a single PIDF document, which can be composed to represent multiple locations if needed.

Proposal: instead of having a geolocation header that points to multiple docs, have a single geolocation header that points to a single location in a PIDF-LO.

Keith Drage: Asked whether his understanding was correct, that you have to go and fetch the PIDF document to get some of the information that previously in the header.

Martin Thomson: Concerned that people have already implemented what was previously in there. May be we just have to accept duplications between body and header. Could say that you should compose things into a single body, but keep the header information too.

Adam Roach: Figuring out which one location to use has got to happen somewhere.

Jon Peterson: In the past, the mechanism was optimised to having multiple locations in the request, which might not be such a common case. Saying that there is only one location header doesn’t mean we have only one location

Martin Thomson: Concerned more about some of the new drafts like rough-loc - intermediaries inserting is more a red-herring. Having just LbyR would probably work, but need to be pragmatic.

Brian Rosen: Doesn't like the mechanism, not because it doesn't work (it probably does work), but because intermediaries will still go ahead and do what they want. Mistake to make it so hard for intermediary to add location.

Jon Peterson: The document does provide a mechanism for this, either adding LbyR or using 424 to get it resent with LbyR.

James Polk: All the old stuff has to come back in if you allow multiplexing in the header, as per old mechanism.

Hannu Hietalahti: Described enterprise use case. Also pointed out that the draft has been his/3GPP dependency for a long time, and is holding up release of a frozen 3GPP release.

Jon Peterson: My goal was to simplify the document, so we can finally get it published.

Keith Drage: Even if there is only one location, the header needs to provide information for an entity to know whether it needs to go and look for the location.

Jon Peterson: Agree that this draft doesn't provide anything not supported in the earlier draft.

James Polk: We have lost the inserted-by indication. But this was only there to discriminate between multiple locations, and is not needed if there is only one location.

Adam Roach: If an intermediary inserts information, it does it by brute force, eliminating existing information. But before, it just pushed the problem down to the UAS to decide which is valid. How does the UAS differentiate a better location from a worse one?

Brian Rosen: Reason the new mechanism won't work is that intermediary does not know anything about the accuracy of the information already there, and for liability reasons will not kick that out in favour of its own information.

Jon Peterson: I do think the retention of presence model of device, person, etc. in the PIDF-LO is important, but to transfer all this parametric information to the header is not as good.

Brian Rosen: The only change we need to make is to allow multiple values, which we can do without re-introducing all the old parameter.

Jon Peterson: Agree it is important to distinguish who added a location, device, service, user. But information is in body. Should either be in body or in header, not both. Easier to go with body.

Brian Rosen: Making the barrier too high. Happy to recommend composing in PIDF, but will not be able to enforce this as the only method. I think we're in trouble if we forbid multiplexing in the header.

Keith Drage: Previously all information was in header to tell you wish location you might want to fetch first, which might be critical in an emergency call situation.

Jon Peterson: Don't understand how the information we could put in the header would help this.

Martin Thomson: What we are looking at with multiple URIs is multiple schemes, or perhaps multiple targets.

Keith Drage: I believe I am losing capabilities that I had in the previous draft.

Jon Peterson: If we agree to say that its allowed to put multiple URIs in the same header, and that we "should" use just one. Keith, is that helpful?

Keith Drage: Not sure what’s being proposed - should go back to previous draft version, then work through incremental changes.

Jon Peterson: Multiple URIs is ok if we assume they all represent the same target. (some consensus)

Hannes Tschofennig: Good that we shortened document, but guess that environments that Keith is looking at they will just put it in body. And while people implementing it would have been focusing on near-time cases, and have not done much with the header.

Compromise proposed that is to restore Geolocation header that has multiple URIs, even though we would not recommend it. The header parameters distinguishing URIs would not be added back in.

Brian Rosen: All the information you need is in the body. The proposed compromise seems reasonable.

Martin Thomson: So I think we’re saying, "should not", and if inserting two - then consumer must know how to distinguish the two.

Keith Drage: Doesn’t matter so much that there are two locations, still making a decision of how much to trust either location (or which to use).

Jon Peterson: Pizza example - if I’ve got two locations, which one does the pizza delivery service use?

Hannes Tschofennig: For emergency case, use what you have, ask if you want confirmation.

Jon Peterson: So I would go with this compromise, whereby if the bar is just too high to compose a new PIDF, you could convey multiple locations.

James Polk: Does this mean that we’re going to put back in "inserted-by"...?

Jon Peterson: No, we wouldn't re-introduce those parameters. Information is in the body.

Martin Thomson: Anyone subsequently inserting location "must" assume full responsibility for all location information

Jon Peterson: If you take the short cut of inserting multiple locations, you lose the semantics that would be in a composed PIDF-LO. The proposal is not insane. Is everyone okay with the proposed compromise?

Keith Drage: Not OK with the statement about being responsible - can only be responsible for information you insert, not responsible for the whole set of locations.

Jon Peterson: Need to articulate exactly what the responsibility situation is. Would be a SHOULD NOT for adding multiple location.

Call for consensus around proposed compromise ("Restore Geolocation header that has multiple URIs, even though we would not recommend it. Entities inserting persence are responsbile for any resulting errors. The header parameters distinguishing URIs would not be added back in."). Result: IN FAVOR (overwhelming) OPPOSED (few - if any)

Chairs: If Keith believes the document lacks required functionality, he needs to bring use cases to the mailing list.

424 Header Insertion

Issue of 424 header insertion. Proposal that an entity that inserts a location must deal with any 424 response. No objection.

Content-Location

Content-Location issue: It seems the compromise above obviates the need to discuss this. Will construct a new ABNF.

Privacy Text

Issue of privacy text: Probably existing privacy text is inadequate. Several items from the list traffic still need to be explained.

RFC 5606 was taken out - Authors think this is an oversight, and plan to add it back.

Martin Thomson: Enough information elsewhere, and a short amount of text (2 or 3 paragraphs) might be sufficient, referencing what exists.

Error Codes

geo: URIs

Geo-URI issue: Already implicitly allowed as a form of absolute-URI. But does it meet the privacy and policy requirements of GEOPRIV?

Richard Barnes: Main focus of the comment that raised the issue of geo: URIs was in context of multiple locations, which is obviated by compromise above.

Adam Roach: Good idea to mention it if you want people to use it, else they will think it is not allowed.

Richard Barnes: RFC 5808 privacy/security around a using protocol addresses this.

Martin Thomson: Present text we have about RFC 3693 doesn't relate too well to what we have in the document at moment. Needs rewrite.

Keith Drage: Is there stuff way back in the SIP archive - maybe need to go back - since you’ve said this came up before.

Summary

Brian Rosen: Because you’ve got a retransmission - you need an stated exception for emergency calls.

Event Rate Control

Proposal to go ahead with what is described on slides for Event header field in 200 OK to NOTIFY. Document would be revised quite quickly.

Paul Kyzivat: Some of the use of min/max terms would benefit from editorial changes. Comments were made on the list.

Krisztian Kiss: Yes, I didn’t want to change the parameter names, but otherwise, yes, I’m ok with that.

Raw Notes

John Elwell

Status slides Re-invite draft about to go into last call. Security flows - issue of whether it waits for SHA-256. Cullen wants to get the present document done, and come back to SHA-256 later if needed. Needs to be cleared up with Security ADs. Keep-alives - more review urged. RFC 3265bis - doesn't seem to be objections to changes proposed last time. Cullen had a question on flows draft accompanying RFC 4424bis, whether sub-addressing service should be separated out. draft-ietf-sipcore-location-conveyance-03 - Jon Peterson Keith: Believes the authors did not have WG consensus to make the changes that have been made to the draft. Jon explained that this was better than nothing, because they were too late to submit individual draft. Main issue is multiple locations. The essence of the changes made is that now we have a single PIDF document, which can be composed to represent multiple locations if needed. Keith: Asked whether his understanding was correct, that you have to go and fetch the PIDF document to get some of the information that previously in the header. Martin Thompson: Concerned that people have already implemented what was previously in there. May be we just have to accept duplications between body and header. Could say that you should compose things into a single body, but keep the header information too. Jon: In the past, the mechanism was optimised to having multiple locations in the request, which might not be such a common case. Martin: Concerned more about some of the new drafts like rough-loc - intermediaries inserting is more a red-herring. Having just LbyR would probably work, but need to be pragmatic. Brian Rosen: Doesn't like the mechanism, not because it doesn't work, but because intermediaries will still go ahead and do what they want. Mistake to make it so hard for intermediary to add location. Jon: The trade-off is between this and the simple case. Brian: In the 1% case, should allow intermediaries to insert. Jon: The document does provide a mechanism for this, either adding LbyR or using 424 to get it resent with LbyR. James Polk: All the old stuff has to come back in if you allow multiplexing in the header, as per old mechanism. Arnot????: Described enterprise use case. Also pointed out that the draft has been his/3GPP dependency for a long time, and is holding up release of a frozen 3GPP release. Keith: Even if there is only one location, the header needs to provide information for an entity to know whether it needs to go and look for the location. Jon: Agree that this draft doesn't provide anything not supported in the earlier draft. James Polk: We have lost the inserted-by indication. But this was only there to discriminate between multiple locations, and is not needed if there is only one location. Martin: I read it that the intermediary because UAC if it wants to insert LbyR without using the 424 mechanism. Adam: If intermediary inserts information, it does it by brute force, eliminating existing information. But before, it just pushed the problem down to the UAS to decide which is valid. Brian: Reason the new mechanism won't work is that intermediary does not know anything about the accuracy of the information already there, and for liability reasons will not kick that out in favour of its own information. Jon: Can still do so by changing the PIDF-LO. Brian: The only change we need to make is to allow multiple values, which we can do without re-introducing all the old parameter. Jon: Agree it is important to distinguish who added a location, device, service, user. But information is in body. Should either be in body or in header, not both. Easier to go with body. Brian: Making the barrier too high. Happy to recommend composing in PIDF, but will not be able to enforce this as the only method. Martin: Agree with Brian. Some discussion about different bodies relating to different targets ???? Keith: Previously all information was in header to tell you wish location you might want to fetch first, which might be critical in an emergency call situation. Jon: Don't understand how the information we could put in the header would help this. Keith: ???? Martin: What we are looking at with multiple URIs is multiple schemes, or perhaps multiple targets. Keith: I believe I am losing capabilities that I had in the previous draft. Jon: Need to understand requirements in this area. Hannes: Good that we shortened document, but guess that environments that Keith is looking at they will just put it in body. Andy while people implementing it would have been focusing on near-time cases, and have not done much with the header. Compromise proposed that is to restore Geolocation header that has multiple URIs, even though we would not recommend it. Brian: All the information you need is in body. Compromise seems reasonable. Richard: Compromise seems good. Martin: Just need to say that if you add to, you must ???? Brian: If multiple PIDFs, how do I know the difference? All in PIDF. Keith: Question of how I trust the location. Hannes: For emergency case, use what you have, ask if you want confirmation. Jon: So I would go with this compromise, whereby if the bar is just too high to compose a new PIDF, you could convey multiple locations. James: Asking about other header parameters. Jon: No, we wouldn't re-introduce those parameters. Information is in the body. Martin: ???? Jon: If you take the short cut of inserting multiple locations, you lose the semantics that would be in a composed PIDF-LO. Keith: Not OK with the statement about being responsible - can only be responsible for information you insert, not responsible for the whole set of locations. Jon: That is not the case here. Jon: Need to articulate exactly what the responsibility situation is. Would be a SHOULD NOT for adding multiple location. Jonathan Lennox: ???? Jon: Anyone unclear on what the compromise is. Nobody. Hum: All in favour of going ahead with making the changes to the document that Jon has just proposed as compromise. Chair: If Keith believes there is more that needs to be accomplished, need to bring use cases along. Issue of 424 header insertion. Proposal that an entity that inserts a location must deal with any 424 response. No objection. Content-Location issue: It seems the compromise above obviates the need to discuss this. Issue of privacy text: Probably existing privacy text is inadequate. Martin: Enough information elsewhere, and a short amount of text might be sufficient, referencing what exists. Error codes issue: - Skipped Geo-URI issue: Already implicitly allowed as a form of absolute-URI. Richard: Main focus of earlier comment was in context of multiple locations, which is covered by compromise above. Adam: Good idea to mention it if you want people to use it, else they will think it is not allowed. James: ???? Richard: ???? James: What to do about "using protocol"? Richard: Completely sufficient just to refer to existing RFC. Martin: Present text we have about RFC 3693 doesn't relate too well to what we have in the document at moment. Needs rewrite. Keith: Was some discussion in SIP way back about URIs. Jon: In summary, we have path forward for revision of the document. draft-ietf-sipcore-event-rate-control-03: Krisztian Kiss Proposal to go ahead with what is described on slides for Event header field in 200 OK to NOTIFY. Document would be revised quite quickly. Concerning other comments, will make changes.

Roger Marshall

SIPCORE Meeting Notes

7/26/2010 – Monday 09:00-11:30

Chairs introduction - Adam Roach & Paul Kyzivat

Meeting Note-takers: Roger Marshall, Peter Musgrave (backup), Jabber scribe,

Agenda Overview:

0900 - 0915 15 minutes Chairs Agenda and Status draft-barnes-sipcore-rfc4244bis

draft-ietf-sipcore-location-conveyance

draft-ietf-sipcore-sec-flows

draft-ietf-sipcore-keep

draft-ietf-sipcore-rfc3265bis

draft-ietf-sipcore-reinvite

0915 - 0945 30 minutes James Polk or Jon Peterson Conveying Location Information in SIP draft-ietf-sipcore-location-conveyance-03

0945 - 1015 30 minutes Krisztian Kiss (tentative) AD Feedback on Event Throttling (if needed) draft-ietf-sipcore-event-rate-control-03

1015 - 1130 75 minutes - Open

Status Overview

(Reference agenda presentation slides posted in Meeting Materials)

Gonzolo: ReInvite draft about to go to WGLC

Cullen Jennings (indiv.): SHA-1 vs. SHA-256 questions

Adam: take off-line and talk about it.

Cullen: Questions to Mary re: 4244bis

Mary Barnes: Ok - ???

PRESENTATION - Jon Peterson, draft-ietf-sipcore-location-conveyance-03.txt

Keith Drage: Don’t believe you’ve had a wg go-ahead to do this major rewrite

Major reduction, eliminated a bunch of stuff.

Open Issue: What to do about multiple locations.

PIDF-LO has always had the ability to have multiple locations, but how to refer to those...

Proposal: instead of having a geolocation header that points to multiple docs, have a single geolocation header that points to a single location in a PIDF-LO.

Keith: Clarification – how has the document changed...

Keith: So we’ve lost quite a bit

Martin Thomson: I’m a little concerned when we say that we’ve only got one location... this is an old document, people have implemented this – maybe we’ve got to swallow it and not cut off the things that we’ve already got. Don’t want a fight-to-the-death, only one location remains – highlander mode.

Adam: It’s got to happen somewhere.

Jon: Again, saying that there is only one location header doesn’t mean we have only one location...

...

Brian Rosen: I don’t like this mechanism, not because it doesn’t work, (it probably does work), but because I think that it won’t be followed. Intermediaries will likely blow away what’s there, and replace with what they want.

Jon: Multiple location URIs would be a different slide than this one (multiplexing)

James: If you allow intermediaries to insert location, it would require bringing all these deleted params back in.

Hannu: Release 9 was recently frozen – on my dependency list - it’s holding up the implementation of a frozen release.

Jon: my goal was to simplify

Keith: LR’s need to know something about whether or not to try to dereference.

James: to clarify what Keith stated,

Keith: lost the inserted-by

Martin: current draft says the intermediary does not insert locations

Adam: (Brian’s statement) if you did have multiple insertions, how would the consumer differentiate a better one from a worse one.

Brian: all we need to do is to allow the header multiplexing

Jon: I do think the retention of presence model of device, person, etc. in the PIDF-LO is important, but to transfer all this parametric information to the header is not as good.

Brian: I think we’re in trouble if we don’t allow multiplexing in the header

Martin:

Jon:

James: only each PIDF-LO in the past must point to the same entity.

Keith: used to be that all we needed to do was to play with header info – didn’t need to mess with the bodies.

Jon: Don’t understand how each differentiates to know which to go for first.

Keith:

Martin:

Jon: If we agree to say that its allowed to put multiple URIs in the same header, and that we “should” use just one. Keith, is that helpful?

Keith: Not sure what’s being proposed – should go back to previous draft version, then work through incremental changes.

Jon:

Hannes:

Brian: I do think that the parameters that were in the header – it makes sense to include in the body. I am convinced by what I’ve seen, that parameters aren’t needed.

Richard: second what Brian’s saying – the document is better.

Jon: The COMPROMISE – to restore the ability to have multiple URIs in the geolocation header.

Martin: So I think we’re saying, “should not”, and if inserting two – then consumer must know how to distinguish the “two”.

Brian:

Keith: Doesn’t matter so much that there are two locations, still making a decision of how much to trust either location (or which to use).

Jon: Pizza example – if I’ve got two locations, which one to use?

Hannes:

Jon: I’d like to guage from the room: The notion that we were going reinstitute the ability to have multiple URIs in the geolocation header, but say that we shouldn’t use it.

James: Does this mean that we’re going to put back in “inserted-by”...?

Jon: no

James:

Martin: Anyone subsequently inserting location “must” assume full responsibility for all location information

Jon: Suggestion is not insane... everybody ok?

Keith: not Ok. Was ok until heard “must” take full responsibility.

Jon: back to compromise – “You break it – you bought it”

Jon: (Hmm) All of those in favor of restoring multiple URIs in the geolocation header.

Hmm result: IN FAVOR (overwhelming) OPPOSED (few - if any)

NEXT ISSUE – 424 Error after header insertion

Something we didn’t get right in the current draft.

Jon: Again recommendation, is that the intermediary takes responsibility for 424 errors.

NEXT ISSUE – Content-Location

Martin: This is solved per our previous conversation and agreement – will construct a new ABNF

NEXT ISSUE – Privacy text inadequate? RFC 5606 was taken out – oversight?

Jon: Probably inadequate – several things from the list traffic that we need to explain.

Martin: 2 or 3 paragraphs is probably all that’s needed – privacy text.

NEXT ISSUE – error codes (skip per Martin)

NEXT ISSUE – geo URI

Does this meet the privacy and policy req’s of geopriv?

Richard: Largely overcome by the agreement that we’ve just come to.

Adam:

Jon: absolute URI already allows for this.

James:

Richard: RFC 5808 privacy/security around a using protocol addresses this.

James: Do we whack the using protocol?

Richard: Sufficient to just refer to 5808.

Martin: references to 3693 doesn’t really tell the story that we want told – privacy

Keith: Is there stuff way back in the SIP archive – maybe need to go back – since you’ve said this came up before.

Jon: I think we’ve got a path forward.

Brian: Because you’ve got a retransmission – you need an stated exception for emergency calls.

Jon: Is there something that SIP needs to say in that regard.

Brian: Will think about it.

NEXT DRAFT - Krisztian Kiss draft-ietf-sipcore-event-rate-control-04

Slide presentation:

Version -04 highlights

Event header field in 200 OK to Notify

Paul: Some editorial comments, labels Maximum-rate- vs. Minimum-interval... (?) would be better with some rewording.

Krisztian: Yes, I didn’t want to change the parameter names, but otherwise, yes, I’m ok with that.

END.

Peter Musgrave

SIPCORE

(Backup Minutes)

Agenda Discussion

WG Items overview

4424bis ready for WGLC

Cullen: sub-address stuff should be in a normative doc (sec 3.7).

Remove or xfer out

Mary Barnes: Agree

reINVITE: Robert had comments after AD review. Now simplified and

settled. Ready to go.

sec-flows needs some changes with new certs work and SHA-256

Cullen: SHA-1 still meets todays needs, can we do this now and get

it done? (Will follow-up offline)

keep alives. 3 comments so far - more participation needed.

3265bis - soon ready for WGLC

Location Conveyance (Jon Peterson)

Keith Drage: Was there consensus for total re-write of WG doc? Should

the mailing list have been consulted?

Jon: Might have better as an individual doc…time did not permit

model moving to multiple locations in a single pidf body. This needs

a lot of discussion might be semantic and not just syntactic.

{Keith] what about losing information about not having location info

directly in the body/header

(Martin) Removing information from the old scheme and one location

value is perhaps breaking people who have already implemented an early

version. Can some of the info be retained (but perhaps be not

recommended).

(Martin) Concerned about rough location, access policy etc etc.

[Jon] Location by reference would solve this (agreement that it

would but might be agreeable to all)

[Brian Rosen] Don't like the mechanism - doesn't think people will use

it. This will hurt the emergency use case. Mistake to make it hard for

intermediary to add location.

[Jon] This is the tradeoff. Is intermediary addition the common case?

[Jon] Insertion is not disallowed. Intermediary would add to the info

in a new composed doc which it can provide a reference to

[James] In the re-write the parameters which were removed. If we want

to add intermediaries those parameters need to return.

[Jon] That stuff can be added in the pidf doc.

[?2] Clear that we will get location from multiple sources along the

path. This draft is on dependency list for 3GPP for years. Now needed

for emergency calls. Please decide soon!

[Keith] James is right - must provide info inserted in header when a

location is added. UAs need information in header to decide which

references it wants to follow.

[Jon] I don't understand the objection.

[James] (to Keith) If intermediary inserts as URI then don't have

inserted by. But inserted by was never for identifying but for

providing information on error response.

[Adam] If an intermediary want to insert a better value - how will

receiver know which location is better?

[Brian Rosen] Difficulty is who has what liability (esp. in emergency

case). Each intermediary does not know if preceding location stuff is

bad. So will require people to construct a new message and they now

have responsibility for getting it right. Need to add multiplexing in

the header.

[Jon] Thinks useful to distinguish devices, services and users.

Replacing stuff in the header would releive this concern but why not

just mux all the stuff in the body. Same amount of syntax. Should just

mux in one place, header or body. Body already has all this stuff so

why replete in header.

[Brian] Barrier is too high - people will lose information. Can pidf

body idea be just a recommendation. If it;s the only way we;re in

trouble

[Martin] agree with Brian

[Jon] If we allow multiple URIs do we need all the parameters back?

[Keith] Can prioritize location lookups based on URIs?

[Jon] Multiple URIs is ok if we assume they all represent the same

target. (some consensus)

[Keith] Feels capabilities have been lost from the previous draft.

[Brian] Rewrite makes clear most of header params are in the body.

Re-write was helpful in this regard. Convinced parameters are not

needed. Seems like a good direction.

[?3] Current doc is good.

Compromise Suggested: Allow multiple URIs in header. Recommend that

one one is used.

Multiple locations was discussed. How can you decide which to use?

[James] How is error info sent back to the inserter?

[Martin] Inserter assumes full resposibility.

[Jon] Is room in favour of restoring multiple URIs (but try to limit

to SHOULD NOT) but no parameters?

Humm...

[Adam] Obvious agreement.

[Keith] Agrees - but this is just the same as we had. Still feels it

is a big change and we may have lost useful capabilities.

Went on to rest of slides.

privacy text is probably inadequate - will need some more work

should we allow geo URIs in geolocation header?

[Richard Barnes] Was not suggesting explicit text - compromise mitigates it.

[Adam (individually)] absolute URIs are used all over the place but

they are not really used in practice (e.g. data URIs cannot be used in

may places)

General discussion about geoUri. Generally viewed as not appropriate.

[Keith] This discussion has occurred before - consult the archives?

Is retransmission allowed ? Are there changes in SIP required for this?

RATE CONTROL

slides presented

[Robert] HOw quickly can we rev this?

Soon

[Paul K] Some of the use of min/max terms would benefit from editorial

changes. Comments were made on the list.

Date:	Monday, July 26th, 2010
Location:	Maastricht, Netherlands
Chairs:	Adam Roach, Paul Kyzivat
Notetakers:	John Elwell, Roger Marshall, Peter Musgrave
Audio Splicing:	Vijay Gurbani

Presenter:	Chairs
Slides:	http://www.ietf.org/proceedings/78/slides/sipcore-0.pdf
Audio:	http://www.softarmor.com/sipcore/IETF78/agenda.mp3

Presenter:	Jon Peterson
Slides:	http://www.ietf.org/proceedings/78/slides/sipcore-1.pdf
Audio:	http://www.softarmor.com/sipcore/IETF78/loc-conveyance.mp3
Document:	draft-ietf-sipcore-location-conveyance-03

Presenter:	Krisztian Kiss
Slides:	http://www.ietf.org/proceedings/78/slides/sipcore-2.ppt
Audio:	http://www.softarmor.com/sipcore/IETF78/event-rate.mp3
Document:	draft-ietf-sipcore-event-rate-control-04