Subject: [Insipid] Alissa Cooper's Discuss on draft-ietf-insipid-session-id-26: (with DISCUSS and COMMENT)

From: "Alissa Cooper" <[email-masked]>
Date: Tue, 16 Aug 2016 07:46:17 -0700

Alissa Cooper has entered the following ballot position for
draft-ietf-insipid-session-id-26: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-insipid-session-id/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

== Section 12 ==

"This document allows for additional parameters (generic-param) to be
   included in the Session-ID header.  This is done to allow for future
   extensions while preserving backward compatibility with this
   document.  To protect privacy, the data for any generic-param
   included in the Session-ID header value MUST NOT include any user or
   device information."

To preserve the privacy properties of the session identifier, I think
this prohibition needs to extend further -- not just to any user or
device information, but to any identifier that persists beyond the
current session. Otherwise some parameter defined in the future could
easily be used to correlate sessions, while the identifier is currently
specified so as to avoid that.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

== General ==

I do not think RFC 7206 needs to be a normative reference, but I'm also
fine with the downref.

== Section 6 ==

"It should be noted that messages received by an endpoint might
   contain a "local-uuid" value that does not match what the endpoint
   expected its peer's UUID to be.  It is also possible for an endpoint
   to receive a "remote-uuid" value that does not match its generated
   UUID for the session.  Either might happen as a result of service
   interactions by intermediaries and MUST NOT affect the communication
   session."

The MUST NOT at the end there is vague and also seems a bit contradictory
to the statement in Section 4.2 that "How a device acting on Session
Identifiers processes or utilizes the Session Identifier is outside the
scope of this document." Could you clarify what the intent of the last
sentence is, and how it squares with the idea that actions taken (or not
taken) based on session identifiers are not being specified here?

== Section 7 ==

"The Session-ID header field value included in a CANCEL request MUST
   be identical to the Session-ID header field value included in the
   corresponding request."

Does "corresponding request" mean original request, as in Section 6? I
think it would be clearer if the text said "original INVITE request" both
here and in Section 6.

== Section 11 ==

'altering the nil "remote-uuid"' seems like it could be phrased less
awkwardly.

"Standard implementations SHOULD NOT expect pre-standard implementations
to be consistent in their implementation" -- I don't think this needs
normative language.

== Section 12 ==

I think the note about billing purposes is outside the scope of the
document and should be removed. Or if not, it needs further motivation --
if someone wanted to bill based on the number of sessions a UA initiated,
why would using the session identifier be an inappropriate way of
counting those?

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 16 Aug 2016 10:14:52 -0500

A quick reply to the DISCUSS point and first comment, inline. I'll leave 
the other comments for the authors:

Thanks!

Ben.

On 16 Aug 2016, at 9:46, Alissa Cooper wrote:

> Please refer to 
> https://www.ietf.org/iesg/statement/discuss-criteria.html

Section 4.2 says, "The SIP User Agent (UA) initiating a new session by 
transmitting a
    SIP request ("Alice"), i.e., a User Agent Client (UAC), MUST create 
a
    new, previously unused, UUID and transmit that to the ultimate
    destination UA ("Bob")."

Is that sufficient, or do you think it needs more emphasis in section 
12?

I assume you've seen my DISCUSS point on this. I could be convinced that 
this could be informative. However, the use of "communication session" 
here and in that document is not the same as people might expect from 
other contexts. In particular, a communication session for the context 
of a session-id may span multiple sessions as we might currently think 
of them. (e.g. certain call transfer or end-point initiated conference 
use cases.) There is a fairly lengthy discussion of that in 7206. So I 
personally lean towards thinking 7206 is necessary to understand this 
draft.

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 16 Aug 2016 11:28:37 -0400

Hi Ben,

> On Aug 16, 2016, at 11:14 AM, Ben Campbell <[email-masked]> wrote:
> 
> A quick reply to the DISCUSS point and first comment, inline. I'll leave the other comments for the authors:
> 
> Thanks!
> 
> Ben.
> 
> Section 4.2 says, "The SIP User Agent (UA) initiating a new session by transmitting a
>   SIP request ("Alice"), i.e., a User Agent Client (UAC), MUST create a
> Is that sufficient, or do you think it needs more emphasis in section 12?

I thought that applied only to the local-uuid part of the ABNF (and remote-uuids, since remote-uuids are local-uuids sent in reverse). I was commenting on the generic-param.

> I assume you've seen my DISCUSS point on this. I could be convinced that this could be informative. However, the use of "communication session" here and in that document is not the same as people might expect from other contexts. In particular, a communication session for the context of a session-id may span multiple sessions as we might currently think of them. (e.g. certain call transfer or end-point initiated conference use cases.) There is a fairly lengthy discussion of that in 7206. So I personally lean towards thinking 7206 is necessary to understand this draft.

I think we tie ourselves in knots about this all time unnecessarily, since documents containing definitions are often informational and documents that reference them in this way are often not. No matter what sort of labels or process magic we apply, it will be a mistake for someone to implement this spec without reading RFC 7206, someone may make that mistake, and there will be nothing we can do if that mistake is made. So basically what I’m saying is I’m fine with this reference being in either category. And I know there is separate ongoing work happening around this topic generally to help us avoid having the same discussion repeatedly about different documents.

Thanks,
Alissa

---

From: "Paul Giralt (pgiralt)" <[email-masked]>
Date: Wed, 17 Aug 2016 02:20:31 +0000

Alissa,

Thank you for the feedback. Please see inline…

> On Aug 16, 2016, at 10:46 AM, Alissa Cooper <[email-masked]> wrote:
> 

I agree with your assessment, however I think the restriction has to be carefully worded because I think the ability to correlate sessions in some meaningful way could be something a future extension might want to do. For example, in an omni-channel contact center environment, we might want to be able to correlate the different channels of communications by including some other identifier (which would have to adhere to the privacy restrictions put in place here). Another potential use would be to include something like a “Related Session-ID” when two sessions are merged together in a way that is not addressed by this specification and it is desirable to include information to link the two sessions together.

I think your concern is more around temporal correlation where two unrelated sessions from the same user could be somehow be associated with each other. If I’m understanding the concern correctly, I can add some verbiage to address this concern without completely eliminating the possibility of a future version having the ability to somehow correlate related sessions that cannot be correlated with the specification as it stands.

As Ben already pointed out, there will be a separate discussion about this.

> taken) based on session identifiers are not being specified here?

The point of this statement is to ensure that no matter what is in a Session-Id header, it MUST NOT affect how the session is actually processed. We are basically saying we do not stipulate what a device does with the information contained in the Session-Id header, but the data (or lack of data) in the Session-Id header will not affect how the session is processed (e.g. a call would not be rejected because of invalid information in the Session-Id header).

Please let me know if you feel additional clarification is needed.

> think it would be clearer if the text said "original INVITE request" both

As CANCEL only applies to an INVITE, I think it’s implied, but would be happy to change for clarity.

> 'altering the nil "remote-uuid"' seems like it could be phrased less

Thanks - will try to rephrase.

> to be consistent in their implementation" -- I don't think this needs

I agree. I will modify.

> why would using the session identifier be an inappropriate way of

I believe this was added as a result of a concern in the WG early on. I think this had to do with the fact that there are possibilities where the Session Identifier can get out of sync, so basing billing decisions on it would not be a good idea. I will need to do some research to find the reason for it unless one of the other authors remembers and can comment.

---

From: Brett Tate <[email-masked]>
Date: Wed, 17 Aug 2016 07:02:33 -0400

Hi,

Reply is inline.

> -----Original Message-----
> From: insipid [mailto:[email-masked]] On Behalf Of Paul Giralt
> (pgiralt)
> Sent: Tuesday, August 16, 2016 10:21 PM
> To: Alissa Cooper
> Cc: [email-masked]; [email-masked]; The IESG;
> draft-ietf-insipid-
> [email-masked]; [email-masked]
> Subject: Re: [Insipid] Alissa Cooper's Discuss on
> draft-ietf-insipid-session-
> id-26: (with DISCUSS and COMMENT)
>
> Alissa,
>
> > email addresses included in the To and CC lines. (Feel free to cut
> > this introductory paragraph, however.)
> >
> >
> > Please refer to

<snip>

> > think it would be clearer if the text said "original INVITE request"
> > both here and in Section 6.
> >
>
>

Although RFC 3261 section 9.1 recommends not sending CANCEL for other
requests, the RFC still allows sending CANCEL for non-INVITE requests (even
though section 9.2 renders it useless to do so for some requests).

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 17 Aug 2016 09:31:47 -0400

> On Aug 16, 2016, at 10:20 PM, Paul Giralt (pgiralt) <[email-masked]> wrote:
> 
> Alissa,
> 

Sounds good.

> Please let me know if you feel additional clarification is needed.

Ok, I think it would be clearer if it said “MUST NOT affect how the endpoint processes the session.”

Thanks,
Alissa

---

From: "Paul Giralt (pgiralt)" <[email-masked]>
Date: Wed, 17 Aug 2016 16:03:45 +0000

> On Aug 17, 2016, at 9:31 AM, Alissa Cooper <[email-masked]> wrote:
> 
>>> 

Ok - I like the wording. I will make the change.

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 17 Aug 2016 17:12:43 -0500

On 16 Aug 2016, at 21:20, Paul Giralt (pgiralt) wrote:

[...]

> I agree with your assessment, however I think the restriction has to 
> be carefully worded because I think the ability to correlate sessions 
> in some meaningful way could be something a future extension might 
> want to do. For example, in an omni-channel contact center 
> environment, we might want to be able to correlate the different 
> channels of communications by including some other identifier (which 
> would have to adhere to the privacy restrictions put in place here). 
> Another potential use would be to include something like a “Related 
> Session-ID” when two sessions are merged together in a way that is 
> not addressed by this specification and it is desirable to include 
> information to link the two sessions together.
>
> I think your concern is more around temporal correlation where two 
> unrelated sessions from the same user could be somehow be associated 
> with each other. If I’m understanding the concern correctly, I can 
> add some verbiage to address this concern without completely 
> eliminating the possibility of a future version having the ability to 
> somehow correlate related sessions that cannot be correlated with the 
> specification as it stands.

I don't object to this path forward, but I think we will need to be 
careful that the future use cases we enable do not become the exact 
persistent correlation issue that Alissa was concerned about. Is the 
potential  not already covered by the rather expansive definition of a 
"communication session"?

[...]

Thanks!

Ben.

---

From: Paul Giralt <[email-masked]>
Date: Wed, 17 Aug 2016 20:18:11 -0400

> On Aug 17, 2016, at 6:12 PM, Ben Campbell <[email-masked]> wrote:
> 
> I don't object to this path forward, but I think we will need to be careful that the future use cases we enable do not become the exact persistent correlation issue that Alissa was concerned about. Is the potential  not already covered by the rather expansive definition of a "communication session"?

I don’t think it’s enough on its own because a single UUID could end up in more than one communication session (in the case of a transfer or conference), so stating that an identifier must be constrained to a single communication session is not accurate; however, from the point of view of a single endpoint, it is true that it must generate a unique identifier for each communication session it participates in. The other issue is that communication session is defined in a very SIP-specific way (user agents, SIP messages, etc… ) but a future enhancement could potentially include something related to something other than a SIP session.

I think I completely understand the concern here and think I can write some text to address it by just imposing restrictions on reusing an identifier across unrelated communications sessions.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 17 Aug 2016 21:18:40 -0400

> I think I completely understand the concern here and think I can write some text to address it by just imposing restrictions on reusing an identifier across unrelated communications sessions.

I look forward to seeing that, because IIUC reusing the session ids was 
the primary reason for making the two-part session-ids.

	Thanks,
	Paul