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

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

I think that the problem is mostly with the folks out of the WG who could not see the messages distributed before. Re-sending the external review announcement with the complete set of milestones would solve this. 

Regards,

Dan
 



> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[e-mail]]
> Sent: Sunday, September 29, 2013 1:13 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,
> 
> so, in practical terms, what do you want me to do? I (and the chairs
> before) have already distributed the milestones before so that the WG
> can review them. Do you want me to do something else?
> 
> Thanks,
> 
> Gonzalo
> 
> On 29/09/2013 1:07 PM, Romascanu, Dan (Dan) wrote:
> > But we ARE discussing a charter update. So let is also include the new
> milestones in the discussion. This does not change the process, it just
> allows to comment the text related to the scope and the milestones on
> the same occasion.
> >
> > Regards,
> >
> > Dan
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: Gonzalo Camarillo [mailto:[e-mail]]
> >> Sent: Sunday, September 29, 2013 1:04 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,
> >>
> >> yes, because the first two are the existing milestones. The last two
> >> are added as a result of this charter update.
> >>
> >> Cheers,
> >>
> >> Gonzalo
> >>
> >> On 29/09/2013 1:00 PM, Romascanu, Dan (Dan) wrote:
> >>> 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.ht
> >>>>>>> ml
> >>>>>>>
> >>>>>>> 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
> >>>
> >