Re: [Insipid] WG Review: INtermediary-safe SIP session ID (insipid)

["Romascanu, Dan (Dan)" <[e-mail]>]

OK, thanks, this makes sense. The announcement included only the first two. 

Dan




> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[e-mail]]
> Sent: Sunday, September 29, 2013 12:58 PM
> To: Romascanu, Dan (Dan)
> Cc: DRAGE, Keith (Keith); James Polk; [e-mail]; 'Gonzalo
> Salgueiro (gsalguei)'
> Subject: Re: [Insipid] WG Review: INtermediary-safe SIP session ID
> (insipid)
> 
> Hi Dan,
> 
> the proposed milestones can be found on the slides Keith mentioned in
> his email below. I copy them below for your convenience:
> 
> Dec 2012 Requirements and use cases for new identifier sent to IESG (as
> informational)
> 
> Feb 2013 Specification of the new identifier sent to the IESG (PS)
> 
> Dec 2013 Requirements for marking SIP sessions for logging to IESG
> (Informational)
> 
> Mar 2014 Protocol for marking SIP sessions for logging to IESG (Proposed
> standard
> 
> Cheers,
> 
> Gonzalo
> 
> 
> On 29/09/2013 12:27 PM, Romascanu, Dan (Dan) wrote:
> > Hi Gonzalo,
> >
> > I understand that the process of review and approval of the milestones
> is different, but at such point in time when the charter is sent for
> external review I think it would be good to synchronize the two
> processed. It does not make sense to me to review a charter whose
> milestones are in the past, obviously not in synch with the rest of the
> text.
> >
> > Regards,
> >
> > Dan
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: [e-mail] [mailto:[e-mail]] On
> >> Behalf Of Gonzalo Camarillo
> >> Sent: Sunday, September 29, 2013 11:35 AM
> >> To: DRAGE, Keith (Keith)
> >> Cc: James Polk; [e-mail]; 'Gonzalo Salgueiro (gsalguei)'
> >> Subject: Re: [Insipid] WG Review: INtermediary-safe SIP session ID
> >> (insipid)
> >>
> >> Hi,
> >>
> >> with respect to the milestones, the review of charters follows a
> >> different review process than the milestones, which can be easily
> >> updated by the chairs and the responsible AD without going through
> >> IETF, IESG, and IAB reviews.
> >>
> >> So, once the charter is approved, the chairs will add the updated
> >> milestones to the tracker.
> >>
> >> Cheers,
> >>
> >> Gonzalo
> >>
> >> On 27/09/2013 10:12 PM, DRAGE, Keith (Keith) wrote:
> >>> The relevant mail was:
> >>>
> >>> http://www.ietf.org/mail-archive/web/insipid/current/msg00642.html
> >>>
> >>> Sent on 2nd August 2013.
> >>>
> >>> If you go to the link in this message you will see a slide with a
> >> coloured version just for your benefit.
> >>>
> >>> Not sure why the new milestones are missing - there should
> >>> ultimately
> >> be two new ones. May Gonzalo Camarillo can comment.
> >>>
> >>> regards
> >>>
> >>> Keith
> >>>
> >>>> -----Original Message-----
> >>>> From: [e-mail] [mailto:[e-mail]] On
> >>>> Behalf Of James Polk
> >>>> Sent: 27 September 2013 19:54
> >>>> To: 'Gonzalo Salgueiro (gsalguei)'; DRAGE, Keith (Keith); Gonzalo
> >>>> Camarillo
> >>>> Cc: [e-mail]
> >>>> Subject: Re: [Insipid] WG Review: INtermediary-safe SIP session ID
> >>>> (insipid)
> >>>>
> >>>> Chairs and AD
> >>>>
> >>>> Lacking a good local diff tool, can you articulate what exactly is
> >>>> being proposed to change from the existing charter, and why was
> >>>> this necessary or needed or asked for?
> >>>>
> >>>> I mean, the focus of the charter is still on the 2 drafts we've
> >>>> been working on for some time now, and that doesn't appear to have
> >>>> changed. Additionally, there are no new milestones.
> >>>>
> >>>> I seemed to have missed the memo that brought this all about.
> >>>>
> >>>> James
> >>>>
> >>>> At 11:08 AM 9/27/2013, The IESG wrote:
> >>>>> The INtermediary-safe SIP session ID (insipid) working group in
> >>>>> the Real-time Applications and Infrastructure Area of the IETF is
> >>>>> undergoing rechartering. The IESG has not made any determination
> >>>>> yet. The following draft charter was submitted, and is provided
> >>>>> for informational purposes only. Please send your comments to the
> >>>>> IESG mailing list (iesg at
> >>>>> ietf.org) by 2013-10-07.
> >>>>>
> >>>>> INtermediary-safe SIP session ID (insipid)
> >>>>> ------------------------------------------------
> >>>>> Current Status: Active WG
> >>>>>
> >>>>> Chairs:
> >>>>>   Gonzalo Salgueiro <[e-mail]>
> >>>>>   Keith Drage <[e-mail]>
> >>>>>
> >>>>> Assigned Area Director:
> >>>>>   Gonzalo Camarillo <[e-mail]>
> >>>>>
> >>>>> Mailing list
> >>>>>   Address: [e-mail]
> >>>>>   To Subscribe: https://www.ietf.org/mailman/listinfo/insipid
> >>>>>   Archive: http://www.ietf.org/mail-archive/web/insipid/
> >>>>>
> >>>>> Charter:
> >>>>>
> >>>>> An end-to-end session identifier in SIP-based multimedia
> >>>>> communication networks refers to the ability for endpoints,
> >>>>> intermediate devices, and management and monitoring system to
> >>>>> identify and correlate SIP messages and dialogs of the same
> >>>>> higher-level end-to-end "communication session" across multiple
> >>>>> SIP devices, hops, and administrative domains.  Unfortunately,
> >>>>> there are a number of factors that contribute to the fact that the
> >>>>> current dialog identifiers defined in SIP are not suitable for
> >>>>> end-to-end session identification. Perhaps the most important
> >>>>> factor worth describing is that in real-world deployments of
> >>>>> Back-to-Back User Agents (B2BUAs) devices like Session Border
> >>>>> Controllers (SBC) often change the call identifiers (e.g., the
> >>>>> From-tag and To-tag that are used in conjunction with the Call-ID
> >>>>> header to make the dialog-id) as the session signaling passes
> through.
> >>>>>
> >>>>> An end-to-end session identifier should allow the possibility to
> >>>>> identify the communication session from the point of origin,
> >>>>> passing through any number of intermediaries, to the ultimate
> >>>>> point of termination. It should have the same aim as the From-tag,
> >>>>> To-tag and Call-ID conjunction, but should not be mangled by
> intermediaries.
> >>>>>
> >>>>> A SIP end-to-end session identifier has been considered as
> >>>>> possible solution of different use cases like troubleshooting,
> >>>>> billing, session recording, media and signaling correlation, and
> so forth.
> >>>>> Some of these requirements come from other working groups within
> >>>>> the RAI area (e.g., SIPRec).  Moreover, other standards
> >>>>> organizations have identified the need for SIP and H.323 to carry
> >>>>> the same
> >> "session ID"
> >>>>> value so that it is possible to identify a call end-to-end even
> >>>>> when performing inter working between protocols.
> >>>>>
> >>>>> Troubleshooting SIP signalling end-to-end becomes impractical as
> >>>>> networks grow and become interconnected, including connection via
> >>>>> transit networks, because the path that SIP signalling will take
> >>>>> between clients cannot be predicted and the signalling volume and
> >>>>> geographical spread are too large.
> >>>>>
> >>>>> This group will focus on two documents:
> >>>>>
> >>>>> The first document will specify a SIP identifier that has the same
> >>>>> aim as the From-tag, To-tag and Call-ID conjunction, but is less
> >>>>> likely to be mangled by intermediaries.  In doing this work, the
> >>>>> group will pay attention to the privacy implications of a "session
> >>>>> ID", for example considering the possibility to make it
> >>>>> intractable for nodes to correlate "session IDs" generated by the
> >>>>> same user for different sessions.
> >>>>>
> >>>>> The second document will define an indicator that can be added to
> >>>>> the SIP protocol to indicate that signalling should be logged. The
> >>>>> indicator will typically be applied as part of network testing
> >>>>> controlled by the network operator and not used in regular client
> >>>>> signalling.  However, such marking can be carried end-to-end
> >>>>> including the SIP terminals, even if a session originates and
> >>>>> terminates in different networks.
> >>>>>
> >>>>> Milestones:
> >>>>>   Dec 2012 - Requirements and use cases for new identifier sent to
> >>>>> IESG (as informational)
> >>>>>   Feb 2013 - Specification of the new identifier sent to the IESG
> >>>>> (PS)
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> insipid mailing list
> >>>>> [e-mail]
> >>>>> https://www.ietf.org/mailman/listinfo/insipid
> >>>>
> >>>> _______________________________________________
> >>>> insipid mailing list
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/insipid
> >>
> >> _______________________________________________
> >> insipid mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/insipid