[Sip] Draft minutes, SIP at IETF 70

[Dean Willis <[e-mail]>]

I'll get these on the various sites shortly.

-------------

Draft 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.



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  
servcing 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.

RKR 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.




_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip