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 [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
