Minutes, SIP at IETF 70 Edited by Dean Willis based on notes by Ben Campbell, Miguel Angel Garcia-Martin and Brian Rosen Session 1 ======== Topic: Agenda and Status led by Chairs Slides presented and included in proceedings Issue: How to deal with extensions in experimental RFCS like "e2m" Proposed that we change the process of RFC 3427 to allow experimental track RFCs to register SIP extension headers. Discussion concluded that using an "X-" prefix in the registry would be self-defeating. There are also concerns about setting the bar too low -- we want any registered extension headers fields to be both reasonable and well-documented. The group reached a consensus on making a change to RFC 3427 allowing any RFC produced by the SIP working group to register extension headers. Issue: Robert's fork-loop-fix draft Not enough people appear to have read the draft yet for us to have a strong sense of whether the changes satisfy issues raised in WGLC. The consensus is that the chairs shall conduct another short WGLC. Topic: Location Conveyance led by James Polk Slides presented and included in proceedings Issue: Should we have an error message to describe what's bad about the civic address data contained in a prior message? Several points were raised in discussion, including whether we have enough of an understanding of location validation to be able to do this sort of detailed response coding at this time. The current draft allows for a human-readable string, and this may suffice for current needs. Whether this is sufficient depends in large part on whether we expect automata to be able to respond to a a validation error, correct the location data, and resubmit it. There may also be the possible that the automata could parse the error response and ask a human a specific question, such as "What floor are you on?" if needed. No conclusion was reached in the meeting, and the author was asked to lead a discussion of the issue on the mailing list. Issue: What are the semantics of the "recipient" parameter in the Geolocation header? Debate centered on whether this parameter is a hint, a provider of context, or a binding constraint on authorization to access the location information. The discussion became somewhat heated. The working group did indicate a strong consensus to develop a protocol mechanism for location-based routing. Debate during the meeting session was inconclusive, and it was proposed that we have an ad-hoc breakout session on this topic. The ad-hoc session resolved to move this semantic into the geopriv object itself, and to send the work item for this back to GEOPRIV to complete. Issue: Are the error codes proposed too complex or too granular? Debate centered on whether the error codes helped users or automata recover from correctable conditions or are intended for post mortem debugging. Debate was extensive, with no immediate consensus forthcoming, so this topic was also deferred to the the breakout session. The breakout session resulted in a consensus on restructuring the error response codes. Minutes of this session are included later in this document. Topic: Info Harmful led by led by Eric Burger Slides presented and included in proceedings Discussion was deferred until after the presentation of the INFO Events draft. Topic: Info Events led by Christer Holmberg Slides presented and included in proceedings Issue: If an endpoint can receive an info package (i.e., indicates it can receive such events), does that mean it will do something useful with an event if it receives it? Discussion seems to indicate that each INFO event package will determine the requirements for that package, with the general trend being "only say you know it if you want it". So, event packages, where available, would be higher-priority than older techniques with less negotiation flexibility. Issue: If the other end doesn't understand an INFO event you want to send, what do you do? Discussion concluded that a node can only send events that the other side has indicated a willingness to receive, so if the other end doesn't understand something, don't send it. This may mean that event-dependent applications won't work, or that one might have to do something tricky like falling back to actually talking to the other party instead of sending events. Issue: Backward Compatibility Noted that in the bad-old-days of INFO, all backward compatibility was handled manually by configuration. That technique can still be used. However, for the ISUP and QSIG uses, we can provide for backward compatibility using Accept header fields as these payloads have MIME types that are not used in other contexts. Also noted that we need to consider these sort of backward compatibility issues in each event package. Issue: Do we want to enable transmission of user-to-user information in an INVITE initiated dialog? This was one of the arguments against dialogs of MESSAGE methods. Discussion indicated that we're probably OK with this for the class of things we seem to think will end up in INFO events. It was noted by a chair that there is little sense in trying to "protocol police" this sort of thing -- the requirement is just t make sure that the protocol allows the applications involved to understand what they're doing and not step on each other's extensions. Issue: Use cases? Whether DTMF is a convincing use case was discussed without conclusion. Noted that other SDOs appear to be developing things using INFO. This MAY be because INFO is the right thing, or it may be simply because they don't have to negotiate with IETF to use it, and that if we adjust INFO to encourage them to work with IETF, they might just find some other loophole like X-headers. Proposed that there are non-DTMF needs for end to end traffic, but that these needs may be better met by end-to-end sessions like MSRP. Of course, this raises the issue of negotiating the semantics of these end-to-end sessions, like "Why are you sending me these JPEG images in an MSRP session? What AM I supposed to do with them?", so there would still be a need for some sort of package definition. However, DTMF may be unique in being both signaling and media, and we might solve much of the problem by just finding a fix at the SIP level for DTMF and ignoring the remainder of the problem. Discussion on whether use cases could motivate the work. At one point, a poll by the chairs indicated that few of the people opposed to INFO events would be persuaded even if confronted with a large number of valid use cases. Issue: Registration policy. If we were to define INFO events, what would the IANA policy be on registering an INFO event package? Chair Dean Willis proposed that the policy be "specification required", given that our goal is not to police the architectures of everybody who wants to use SIP, but that we do need to make sure that the feature negotiation mechanism work well enough that conflicts are avoided. We really should NOT have to use SIP working group time to discuss whether or not some other SDO's use of their SIP-absed signaling channel is valid. Issue: Where to go from here? Noted that there ARE other SDOs actively engaged, and that we are not servicing the community well by giving no guidance. Eric Burger noted that the two drafts are not incompatible, and that the INFO events draft solves all of the "harmful" aspects of current INFO use noted in his draft. The meeting concluded with an agreement to further consider use cases, but no commitment to further action. (Note: subsequent discussion occurred on-list, shortly after the meeting session). Session 2 ======== Topic: Agenda and Status led by Chairs Slides presented and included in proceedings Discussion of Essential Corrections will be added to the agenda if time allows. The XCAP Diff event draft will be revised and submitted as draft-ietf-sip-xcapevent-00 Connection reuse was rescoped to allow some requests in the reverse direction and discourage connection reuse for virtual servers. Some further clarifications are needed. Topic: Outbound led by Rohan Mahy Slides presented and included in proceedings Issue: TCP Keepalive Current text removed. Noted that even if you use TCP keepalive, you still need to do the keepalives as specified in this draft. Issue: interaction with GRUU. Group seemed to indicate consensus on the proposal by Rohan for the 2nd option listed in the slides -- GRUU should check that an incoming REGISTER matches any Call-ID already registered by this device. This would appear to require a change in the GRUU document. Issue: What error does the registrar send if it gets a register with require: outbound but the edge proxy doesn't support outbound? Christer Holmberg suggested that most cases would need a 500-class. Jonathan Rosenberg noted that this depends on what might happen if the requested were to be retried. If it is always going to fail, the response would be in the 400 class. If success on retry is possible, a 500 might be more reasonable. Cullen Jennings noted that It is also important to consider what clients will do with the response. Adam Roach observed that a 420 response would make it hard to debug the problem from a client perspective, and that a new error code would be better. Jonathan suggested using a proxy require that the proxy would translate to require, but Rohan reminded us of prior discussion where we had decided this would not work. Christer concurred with Adam, saying that this problem is more general, essentially an "invalid path". The resolution is to develop a new 400 class response code indicating the problem with this path. Adam Roach volunteered to send text. Issue: How do subsequent in-dialog requests follow across an Outbound edge link? Proposed by Rohan that the Outbound proxy MUST record route if the top Route header has an :ob" parameter. Extended discussion followed, noting that this makes us dependent on proxies for mid-dialog requests, which has impacts on reliability designs. Francois Audet noted that the current text is hard to understand. Chairs conclude that the room seems to mostly support the resolution proposed by Rohan, but that the final text needs to be reviewed and agreed on-list. Issue: The "keep" parameter. Ted Hardie argued for keeping the text as-is. Aki Niemi argued in favor of deprecating the "keep" parameter, based on its lack of usefulness and potential to confuse people. Christer Holmberg suggested deprecating the parameter when used with an outbound proxy, but allowing it for non-outbound cases. Poll by chairs indicated strong consensus for removing the "keep" parameter. Issue: Replace timed-keepalive parameter with a new header Proposed by Aki that weuse a new header, such as "Flow-Timer" to be returned in register response. Noted by Rohan that this might fix the non-outbound case for keepalive. Christer questions this, as it is still necessary to know if keepalive is supported. Poll by chairs indicated strong consensus to define a new header for this purpose. Issue: Detecting client support for keepalives without "outbound" Proposed new option tag for client support, included by client in Supported. Poll by chairs indicated preference to consider this approach outside of the Outbound draft. Christer Holmberg may pursue a draft on this topic. Procedural point: Francois Audet has volunteered to act as the protocol shepherd for getting this draft through the process. Derek reminded Rohan to add text relating to the route construction issue. Derek will try to send text on this to Rohan. Topic: Resource Priority Header in Responses led by Janet Gunn Slides presented and included in proceedings Discussion centered on the role of the RPH header in a response and the assumptions underlying a network in which it would be useful. The key issue is that since SIP cannot challenge responses that if the response is not signed (as in SIP Identity) then there is no way to tell upstream where the RPH header came from. There may be no coupling between the proxy layer and the access network for media priority enforcement. Noted by EKR that given the security model, where the user is not trusted but all the proxy nodes are, that this requires integrity protection on the connections, with peer authentication. A proxy receiving a response with RPH has to know that it's getting this response from a trusted proxy and not somebody else. Several parties suggested that this sort of mechanism is more appropriate for a P-header with an applicability statement that explains the transitive trust model. Keith Drage, as chair, asked people to consider the stateless proxy use case from James' draft relative to the security assumptions, P-header concept, and authentication issues. Topic: Media Identity led by Dan Wing Slides presented and included in proceedings Issue: SBCs break 4474 because SDP signed by Identity is rewritten by SBC Francois observed that this problem may only occur when it is an SBC outside the domain of the Identity server that is doing the rewriting. Hannes suggested extending IDENTITY to be like DKIM, which can selectively sign pieces. General discussion revealed that most of the material in the signaling is problematic from a signature perspective. IP Addresses are essentially meaningless, especially across domain boundaries. Phone numbers are little better, with end-nodes having no real way to test assertions about them (and perhaps a service provided signature is the best we can do here). RFC 4474 already documents limitations with respect to telephone numbers. There seems to be an emerging thread of consensus here that what we need is some way to bind media to signaling -- that is, to by inspection of the media and the signaling be able to say with some level of certainty that they are related -- and specifically, to say "this media is a result of that signaling". Chairs noted that there is additional work required her to be able to frame this into the sort of requirement that could be added to a charter. Topic: DTLS Framework led by Jason Fischl Slides presented and included in proceedings Issue: 4474 for phone numbers We may be lacking documentation on when RFC 4474 does and does not work, and what security we get when using it with phone numbers. Jon Peterson seems to think that 4474 already offers this guidance. Jonathan Rosenberg disagrees and believes the text in 4474 is inadequate and more is needed. Consensus noted that even if we do need more here, it is outside of the scope of the DTLS framework. However, the framework should at least note the issue. Issue; Anonymity Agreed that text must be updated to say it does not break existing anonymity. Issue: Middle boxes. SBCs may block key exchange before 200 OK. This is not specific to DTLS-SRTP. Proposed by Christer that we at least mention this issue in the draft. EKR noted that much of this SBC difficulty should be documented in Brian's middlebox draft. Issue: SRTP/TCP Consensus: DTLS-SRTP over TCP rather than RTP over TLS. Issue: Priority for advancing. Chairs observed that an AVT document is dependent on this, making this a high priority to move along, However, the AVT chair reported that the AVT document is not as ready as we might have thought. Topic: Essential Corrections led by Keith Drage Slides presented and included in proceedings Issue: general intent of essential corrections We seem to have some disagreement as to the intent and value of the essential corrections process. The chairs restated the goal as being to batch together the updates to RFC 3261 so that readers do not have to look in many places to find the current "corrected" specification. Issue: record-route-fix Is this an essential correction or an enhancement? It does identify specific failure cases that occur if RFC 3261 is used as-is. The chairs noted that drafts making normative changes to a standards track draft need to be standards track themselves, not BCPs. However, BCPs would be appropriate for documents that, for example, argue for using one option in an an existing standards-track document over an alternative in that document. Robert argues that this fix is needed, although it would be acceptable to advance it individually rather than in the essential-corrections procss. Conclusion: robert and Jonathan are to go discuss this and come back with a recommendation. Issue: IPV6 ABNF error Consensus that this is an essential correction we would consider anything that behaves as per 3261 to be erroneous. Issue: 503 corrrection JDR argues that it is known that 3261 doesn't perform well in overload conditions, and that we have ongoing work to improve this behavior. Volker Hit concurs, noting that the overload team is still working to get better simulation results. Conclusion: We'll continue to discuss this document but not move towards WGLC yet. Issue: Mutual authentication Noted that there does seem to be a use case for this extension in IMS and cable networks, but that it probably doesn't meet the litmus test for an essential correction. Conclusion: It shall be discussed as an extension. Issue: invfix Conclusion: this is an essential correction. Author Robert Sparks is to revise for WGLC. Topic: INFO Chairs proposal is for Hadriel and Christer to continue their draft, rolling in the supporting motivation from Eric's draft. We will also discuss use cases for the INFO package model. if we don't find three agreeable use cases by the next meeting, we'll go ahead and publish Eric's "INFO Considered Harmful" draft so that there will be some firm guidance in RFC format. Session: Location Ad-Hoc ======================== An additional break-out session was held to discuss issues related to location conveyance and SIP, due to the failure to reach consensus on key issues during the regular session. Notes reported by Dean Willis Session chaired by Keith Drage Note-Well reviewed Discussion led by James POlk Slides presented Issue: Error codes in Geolocation-Error header Issues raised in SIP meeting include general sense that current error codes are just "too much" and should be reduced. Discussion of actionable vs. diagnostic errors ensued (started by James Winterbottom). Are the text strings fixed so that they can be processed by automata? Are we doing trend analysis or trying to make a call succeed that was failing? Comment by Henning Schulzrinne: Not really a question of whether 14 or 17 is the right number, but as to whether the civic address (CA) type information is appropriately included in the responses. Just including a CA type doesn't help solve the problem and may confuse the situation. Robots cannot usefully "fix" defective CA information, but require human interaction. I fear that the software will say "A1 and A7 are wrong" and the user will have no idea what to do. Response: Do you want to be able to say things like "The city field was missing and we need it." We could put this in the current draft for now. Counteproposal: We should leave CA types out for now and add them back in only if experience shows that they would have been useful. It's better to drop it now. We seem to have a consensus to delete the CA type information from error responses. As for other error codes, EKR suggests that those that are repairable by automata be included. Henning agrees, suggesting we also have one error code for human-fixable errors that can be communicated in text. Ted Hardie categorizes errors in 3 groups : 1) Same things that might work later, 2) vague "something you gave me is wrong", 3) bit-toggleable "permission" errors. Possibly a 4th class, "things an automata can fix", like refreshing its location calc and resending. Noted that SIP "Accept-Language" mechanism provides the human-language negotiation mechanism. Poll: does anybody have issues with Ted's plan? Mostly agreed: James will revisit. Issue: Recipient= Henning discussed differences between URN routing and URI routing in the presence of a location body. He has concerns that it might not be possible to make a reasonable determination in an implementation and this has lawsuit potential. Ted counter-argues that this was concluded in GEOPRIV. Massive debate ensued. Proposed: Easy solution for SIP working group is to move the functionality formally known as "recipient =" out of SIP and into PIDF-LO as a routing-allowed flag. This will require deleting the subject from the SIP draft and creating a new GEOPRIV draft. Jon Peterson volunteered to write the GEOPRIV draft. NOTE: The GEOPRIV draft will require careful definition of "retransmission" so as to not interact with the fact that SIP proxies operate by retransmitting SIP requests.