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

From: The IESG <[email-masked]>
Date: Fri, 27 Sep 2013 09:08:05 -0700

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 <[email-masked]>
  Keith Drage <[email-masked]>

Assigned Area Director:
  Gonzalo Camarillo <[email-masked]>

Mailing list
  Address: [email-masked]
  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)

---

From: James Polk <[email-masked]>
Date: Fri, 27 Sep 2013 13:54:01 -0500

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:
>_______________________________________________
>insipid mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/insipid

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 27 Sep 2013 19:12:59 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf
> Of James Polk
> Sent: 27 September 2013 19:54
> To: 'Gonzalo Salgueiro (gsalguei)'; DRAGE, Keith (Keith); Gonzalo
> Camarillo
> Cc: [email-masked]
> Subject: Re: [Insipid] WG Review: INtermediary-safe SIP session ID
> (insipid)
> 
> Chairs and AD
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sun, 29 Sep 2013 11:34:51 +0300

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 29 Sep 2013 09:27:18 +0000

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

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Gonzalo Camarillo
> Sent: Sunday, September 29, 2013 11:35 AM
> To: DRAGE, Keith (Keith)
> Cc: James Polk; [email-masked]; 'Gonzalo Salgueiro (gsalguei)'
> > Not sure why the new milestones are missing - there should ultimately
> be two new ones. May Gonzalo Camarillo can comment.
> >
> > regards
> >
> > Keith
> >
> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of James Polk
> >>> 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.
> >>>
> >>> 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.
> >>>
> >>> 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"
> >>> 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
> >>> 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)

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sun, 29 Sep 2013 12:57:58 +0300

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 29 Sep 2013 10:00:29 +0000

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

Dan

> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: Sunday, September 29, 2013 12:58 PM
> To: Romascanu, Dan (Dan)
> Cc: DRAGE, Keith (Keith); James Polk; [email-masked]; 'Gonzalo
> Salgueiro (gsalguei)'
> Dec 2012 Requirements and use cases for new identifier sent to IESG (as
> informational)
> 
> Mar 2014 Protocol for marking SIP sessions for logging to IESG (Proposed
> standard
> 
> Cheers,
> 
> 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
> >
> >
> >
> >
> >> updated by the chairs and the responsible AD without going through
> >> IETF, IESG, and IAB reviews.
> >>
> >>>> 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
> >>>>> The INtermediary-safe SIP session ID (insipid) working group in
> >>>>> the Real-time Applications and Infrastructure Area of the IETF is
> >>>>> 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.
> >>>>>
> >>>>> 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.
> >>>>>
> >>>>> 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.
> >>>>>
> >>>>> ID", for example considering the possibility to make it
> >>>>> intractable for nodes to correlate "session IDs" generated by the
> >>>>> same user for different sessions.
> >>>>>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sun, 29 Sep 2013 13:03:42 +0300

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 29 Sep 2013 10:07:42 +0000

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

> Sent: Sunday, September 29, 2013 1:04 PM
> To: Romascanu, Dan (Dan)
> >> (as
> >> milestones are in the past, obviously not in synch with the rest of
> >> the text.
> >>>
> >>> Regards,
> >>>
> >>> Dan
> >>>
> >>>
> >>>
> >>>
> >>>>>> From: [email-masked] [mailto:[email-masked]]
> >>>>>> On Behalf Of James Polk
> >>>>>> 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?
> >>>>>>
> >>>>>> been working on for some time now, and that doesn't appear to
> >>>>>> have changed. Additionally, there are no new milestones.
> >>>>>>
> >>>>>>> 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.
> >>>>>>>
> >>>>>>> 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
> >>>>>>> conjunction with the Call-ID header to make the dialog-id) as
> >>>>>>> the session signaling passes
> >> through.
> >>>>>>>
> >>>>>>> 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.
> >>>>>>>
> >>>>>>> organizations have identified the need for SIP and H.323 to
> >>>>>>> carry the same
> >>>> "session ID"
> >>>>>>> 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.
> >>>>>>>
> >>>>>>> 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)
> >>>>>>>
> >>>>>>>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sun, 29 Sep 2013 13:12:57 +0300

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 29 Sep 2013 10:18:03 +0000

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

> Sent: Sunday, September 29, 2013 1:13 PM
> To: Romascanu, Dan (Dan)
> > 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
> >
> >
> >
> >
> >> yes, because the first two are the existing milestones. The last two
> >> are added as a result of this charter update.
> >>
> >> Cheers,
> >>
> >> Gonzalo
> >>
> >>> OK, thanks, this makes sense. The announcement included only the
> >>> first
> >> two.
> >>>
> >>> Dan
> >>>
> >>>
> >>>
> >>>
> >>>> the proposed milestones can be found on the slides Keith mentioned
> >>>> in his email below. I copy them below for your convenience:
> >>>>
> >>>> 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
> >>>>>> On Behalf Of Gonzalo Camarillo
> >>>>>> updated by the chairs and the responsible AD without going
> >>>>>> through IETF, IESG, and IAB reviews.
> >>>>>>
> >>>>>>> If you go to the link in this message you will see a slide with
> >>>>>>> a
> >>>>>> coloured version just for your benefit.
> >>>>>>>
> >>>>>>>> From: [email-masked]
> >>>>>>>> [mailto:[email-masked]] On Behalf Of James Polk
> >>>>>>>> To: 'Gonzalo Salgueiro (gsalguei)'; DRAGE, Keith (Keith);
> >>>>>>>> Gonzalo Camarillo
> >>>>>>>> Cc: [email-masked]
> >>>>>>>>> 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
> >>>>>>>>> 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)
> >>>>>>>>> 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.
> >>>>>>>>>
> >>>>>>>>> Some of these requirements come from other working groups
> >>>>>>>>> within the RAI area (e.g., SIPRec).  Moreover, other standards
> >>>>>>>>> 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.
> >>>>>>>>>
> >>>>>>>>> same aim as the From-tag, To-tag and Call-ID conjunction, but
> >>>>>>>>> is less likely to be mangled by intermediaries.  In doing this
> >>>>>>>>> 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
> >>>>>>>>>   Dec 2012 - Requirements and use cases for new identifier
> >>>>>>>>> sent to IESG (as informational)

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sun, 29 Sep 2013 16:18:48 +0300

Hi Dan,

OK, I just sent a note as you suggested.

Cheers,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sun, 29 Sep 2013 16:18:20 +0300

Folks,

note that as a result of this rechartering, the milestones will be the
following:

(Proposed standard)

Cheers,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sun, 29 Sep 2013 16:34:38 +0300

Hi,

a clarification in case somebody gets confused by the dates in the past.
We are adding the last two additional milestones as a result of the
rechartering. The dates of the two already-existing milestones (the
first two on the list below) will be updated to reflect the current
estimates for their completion.

Cheers,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sun, 29 Sep 2013 21:51:05 +0300

Hi,

yes, as I mentioned in a different email earlier today, the dates of the
existing milestones will be updated by the chairs as soon as the new
charter is approved.

With respect to explicitly mentioning "two" documents in the charter, I
did not like that particular wording either because it is confusing.
However, some people felt strongly about mentioning the number of main
documents the WG is working on for some reason. As you pointed out,
while the group will *focus* on designing the two mechanisms, they will
also produce the requirements documents. However, the requirements are
not considered to be the focus of the WG. If somebody proposes better
and clearer text, I will be happy to edit the charter proposal accordingly.

Regarding privacy, the WG will of course consider privacy whenever it is
relevant. The charter just identifies certain areas explicitly because
it is very clear that they will have privacy implications. Again, if
somebody wants to provide text that is clearer, that would be great.

Thanks,

Gonzalo

On 29/09/2013 5:14 PM, SM wrote:
> Hi Gonzalo,
> 
> Thanks for bringing this up.
> 
> At 06:18 29-09-2013, Gonzalo Camarillo wrote:
> The above milestones are in the past.  I suggest updating the dates if
> the work items are still due or removing them is they have already been
> delivered.
> 
> The proposed charter discusses about two documents whereas there are
> four milestones.
> 
> It is not clear whether the working group would have to pay attention to
> privacy implications for the last two work items.  Does the privacy
> implications cover the work items, wherever it is relevant, or examples
> of "session ID" only?
> 
> Is the privacy implications only about correlation?  I am asking the
> question as correlation is only one of the privacy-specific threats
> identified by the IAB?
> 
> Regards,
> -sm

---

From: SM <[email-masked]>
Date: Sun, 29 Sep 2013 07:14:58 -0700

Hi Gonzalo,

>Feb 2013 Specification of the new identifier sent to the IESG (PS)

The above milestones are in the past.  I suggest updating the dates 
if the work items are still due or removing them is they have already 
been delivered.

> > correlate "session IDs" generated by the same user for different

It is not clear whether the working group would have to pay attention 
to privacy implications for the last two work items.  Does the 
privacy implications cover the work items, wherever it is relevant, 
or examples of "session ID" only?

Regards,
-sm

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 1 Oct 2013 01:11:48 +0000

This seems to be more a comment on the existing charter rather than the additional new bits.

In that respect, comments against that might be better made against the requirements document that is with IESG at the moment.

https://datatracker.ietf.org/doc/draft-ietf-insipid-session-id-reqts/ 

In regard to the extended charter, my understanding at least is that it adds nothing to the correlation aspects. What gets added is an extra indicator that goes with the session-id as defined, and indicates the the network entities involved that they should create a log of the information contained in all messages with this session i-d.

How those logs are collected together and analysed does not form part of the charter. It is certainly not expected that those logs would be available to an end user or indeed to another operator, as part of any work performed under this charter. That does not preclude the indicator being passed between operators or to the end user, rather than removed, but I am not sure I see a privacy concern with that.

Regards

Keith

> Of SM
> Sent: 29 September 2013 15:15
> To: Gonzalo Camarillo
> Cc: [email-masked]