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

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

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