Minutes: INtermediary-safe SIP
session ID (INSIPID) Working Group
=================================================================
Chairs: Gonzalo Salgueiro (gsalguei@cisco.com)
Keith Drage
(keith.drage@alcatel-lucent.com)
Note Takers: Paul Kyzivat
Andrew Allen
Jabber Scribe: Gonzalo
Salgueiro
Audio: http://www.ietf.org/audio/ietf88/ietf88-plazac-20131104-1720-pm3.mp3
----------------------------------------------
INSIPID WG Status Update
========================
Presentation: http://tools.ietf.org/agenda/88/slides/slides-88-insipid-2.pdf
- James Polk: Agenda bash to present solution draft prior to the backwards compatibility discussion
- Updated charter that includes logging was recently approved by IESG.
- The two additional logging milestones have been added already.
- The Kaplan draft has been through one IETF LC, but due to some IPR filing issues it needs to go through LC again. The IPR statements have now been properly filed.
- A new version of the Kaplan draft is pending that addresses some Directorate review comments and clarified IANA registration proposed by Designated Expert (Adam Roach).
- The Kaplan draft will temporarily register the Session-ID header and then the solution draft will deprecate the Kaplan usage (if it uses the same header field name) when it makes its registration.
- Gonzalo Salgueiro (as document shepherd) and Gonzalo Camarillo (as AD) will follow-up with Hadriel over email (DONE).
- Once Hadriel publishes a new version, the Kaplan draft will go to a 2nd IETF LC.
- There are some pending LC comments by Apps Directorate (Vijay Gurbani) that need to be resolved for the session-id requirements draft (DONE).
- Once completed, the -09 version of the requirements draft will be ready to proceed to IESG Review.
- The Session-ID solution draft is mired in backwards compatibility issues that will be discussed later in this meeting.
- Will try and do a call for adoption of the logging requirements draft at the meeting with follow-up on the mailing list.
- The logging requirements draft has some solution proposals in it that will be presumably be removed prior to adoption.
- Request that any logging solution proposals be published soon so we can begin the process of converging on a suitable WG document as a starting point.
End-to-End Session
Identification in IP-Based Multimedia Communication Networks
===============================================================================
Draft: draft-ietf-insipid-session-id-02
Presentation:
http://tools.ietf.org/agenda/88/slides/slides-88-insipid-10.pdf
- No additional open issues since Berlin.
- Agreed to all of Paul Kyzivat's comments on the -02 version.
- Editors missed the deadline but plan to submit an -03 version with Paul's comments addressed and the resolution to the backwards compatibility discussion.
- Still haven't reached consensus on the disaggregated media example, but it is just a conference and we handle those already.
- Backwards compatibility is the big impediment to WGLC and that is the forthcoming discussion.
A Proposal for Backwards
Compatibility of the INSIPID Session-ID
================================================================
Draft: draft-polk-insipid-bkwds-compatibility-proposal-03
Presentation: http://tools.ietf.org/agenda/88/slides/slides-88-insipid-7.pdf
- Published a draft for this specific issue to have a focused discussion.
- The draft lays out a proposal for putting an indication in to identify which version transmitter *and* receiver is without adding new code to one version
- There was a lengthy discussion on alternative proposal using option tags and feature tags. Lots of issues raised.
- Option tags are to determine remote UA’s support for SIP extensions
- Charles Eckel: Option tag can be used for version support. Kaplan draft is not a version of the INSIPID solution. It says nothing about Kaplan support, only support for new INSIPID support.
- Andrew Allen: Agree. INSIPID is only standards-based solution and it would indicated support for that. Kaplan is only an informational thing done in the past.
- Hadriel: You will never get this Option tag in a Support, Required or Proxy-Require header from a Kaplan implementation.
- Hadriel: There was some confusion on mailing list on whether Option tags or Feature tags.
- Paul K: There is another problem with Option tags. Option tags only apply to the UAC and UAS. Proxies aren't supposed to. But Proxies can insert the new INSIPID Session-ID.
- Keith: Option tags can only indicated support for INSIPID solution. So if an implementation supports both it will only indicate support for INSIPID Session-ID.
- Hadriel: This is not a problem, it is a feature.
- Hadriel: We can wordsmith around the Option tag not being able to be supported by Proxies. It is ugly, though.
- Hadriel: The bigger problem is that B2BUAs will either not pass on Option Tags because it could be some new extension they don't support and could break things or a B2BUA will strip it if they don't understand that Option tag. So using an Option tag unnecessarily raises the bar for this solution.
- Andrew/Keith/Hadriel: Back and forth on Andrew's new draft on FCI but discussion went back to Option tags and lack of B2BUA support.
- Hadriel: The nice thing about the Kaplan draft and the current version of the INSIPID solution is that it would work through alot B2BUAs that knew nothing about it.
- Christer/Hadriel/Keith: Discussion about feature tag vs Option tag but point being that feature tags would not work well.
- Hadriel: Lets get to the third proposal that is discussed in the draft..
- James: Hindered by the fact that we cannot expect any new Kaplan
indication.
- James: Also hindered by the fact that Kaplan implementations merely
copy the contents of the header-value, and not always just sending out
1 UUID.
- James: We don’t exactly know how any/all Kaplan implementations behave.
- Keith: We know what requirements exist in the Kaplan draft. We can't guarantee that a solution implements what exactly is in an RFC.
- Hadriel: This is a slippery slope. Lets get to your proposal. We're not sure that all of them copy the whole contents of the Session-ID header value. Some may only copy the Session-ID portion without parameters, while others will copy the whole thing. But this shouldn't affect your proposal and we can word it properly so that it works.
- Went over some sample call flows illustrating different permutations between a Jones implementation and a Kaplan implementation
- Finally, the proposal (Alternative #3) is to negotiate backwards compatibility (determining support) implicitly within the signaling protocol using Session-ID header (using the remote parameter)
- Hadriel: The one nuance that is easy to get around is that the Kaplan generated message *may* not contain the parameter in the Session-ID.
- Gonzalo S: We can word this appropriately in the backwards compatibility section of the solution draft.
- Hadriel: Agree. This needs to be added but it is something we can workaround.
- Christer: Indicated on the list that this solution would be fine, but that perhaps we need 32 zeroes instead of just one or some unspecified number zeroes. I think the question is if you don't get the remote parameter in the 200 OK, what does Alice put in the Ack?
- James: Alice should put two UUIDs one being null and one being her original one from the INVITE as a broadcast to all intermediaries as a broadcast as to what she supports.
- Christer: The draft needs to explicitly state this.
- James: Will write this.
- Hadriel: As a Jones implementation need to be liberal on receive and strict on send.
- Paul K: The 32 zeroes in remote bother me. They aren't necessary since it isn't part of the Kaplan solution.
- Andrew: Is there any problem with a Kaplan implementation receiving something it didn't send (remote parameter).
- Keith/Hadriel: Should not be a problem as the draft doesn't state that.
- When a Jones implementation detects peer is Kaplan, then should behave as a Kaplan (No remote parameter sent at all).
- Agreed Decision:
- There will need to be text in the draft dealing
with reception of unknown parameters and how you deal with them (i.e.,
ignore them).
- Keith: Consensus in the room is that we use Alternative #3 (indicating support in the signaling) and not Alternative #1 or #2 (Option or feature tags). Will take it to the list for confirmation.
- Editors agreed that revised solutions draft expected by early December that implements this decision (as well as Paul K's earlier review comments).
- This will be finalized on the mailing list (Keith to send a summary email of this decision).
==================================================
Draft: draft-dawes-dispatch-logme-reqs-03
Presentation: http://tools.ietf.org/agenda/88/slides/slides-88-insipid-8.pdf
- Christer Holmberg presenting on behalf of Peter Daawes.
- Enough interest in the logging work and is now added to the INSIPID charter and milestones list
- Requirements are stable now.
- Proposal is to remove the solution text in the current version and adopt the requirements part as WG draft.
- Paul K: Had a bunch of comments. Not sure the subset of requirements is ready to be adopted. There is still a bunch of trust issues with storing the log.
- Gonzalo S: Solution discussion has not even begun yet. This is purely the requirements we are talking about.
- Hadriel: Requirement 9 has some location discussion (URL). Could pose issues.
- Keith: This is not WGLC, just trying to adopt something to advance the work. There is now a milestone for this and there is no competing draft despite multiple requests for that. Might as well make it a WG draft.
- Andrew: Need a vehicle to begin the work, so may as well adopt.
- Hadriel: There are several requirements that are problematic and could use some editing, but we can do that at WG time.
- Call for consensus of adopting requirements one through eight. Consensus reached to adopt.
- Paul K objected, but overridden. Main issue is with the log server requirement 9 so it will be left off.
- This is to be confirmed on the list.
-
No interim meetings needed at this time.