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

Alissa Cooper <alissa@cooperw.in> Wed, 17 August 2016 13:31 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: insipid@ietfa.amsl.com
Delivered-To: insipid@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9857412D93D; Wed, 17 Aug 2016 06:31:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Level:
X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=l8c7mTOG; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=RCGS5jrH
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKafwC5lXB8Y; Wed, 17 Aug 2016 06:31:50 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D87212D93A; Wed, 17 Aug 2016 06:31:50 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id EBD4920846; Wed, 17 Aug 2016 09:31:49 -0400 (EDT)
Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Wed, 17 Aug 2016 09:31:50 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=OGoNjfZp5ItrPlk5KZW0IocjS/s=; b=l8c7mT OG5RPCzvr4JZ7EPogO9G/VvhoqwOg6Qf4RMEoT59IjonDwQaZ9+42COSeusqy3m6 7pUv1i0CG43vy0KMiqI9Ne/ZyZ6909GwAx3Jh33GsYDVEZJfdmFgSAzLZnk/+kJP gbwdrbWULSzXXfoH+To0/79JlfjIVwb6vWTgs=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=OGoNjfZp5ItrPlk 5KZW0IocjS/s=; b=RCGS5jrHWt5fx/JXUvNyAsK+6Mpj+jhA49YLB/ivvA3ppOE m/Xj9yYrFDPsd9OyKV/UbIfZdWCIqGkYjAUmj0CJA3/AIMrAz+qVotwZ6WFyrgOz jWgyio8NOzjSbUQgemHqt9yH34wwhZkphgcwD5sSYOdHJbDyk/2/qewJsiUU=
X-Sasl-enc: ee7mHGfBEu5Tv4fu0HSANA2rW2UoJ1yQ0usw2T/2Vdis 1471440709
Received: from dhcp-10-150-9-151.cisco.com (unknown [173.38.117.72]) by mail.messagingengine.com (Postfix) with ESMTPA id 5BD63CCE65; Wed, 17 Aug 2016 09:31:49 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <2377966D-0E2D-4C90-806A-8F82D8C2C33C@cisco.com>
Date: Wed, 17 Aug 2016 09:31:47 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <2F31B653-D4EC-4662-9CF9-F219C037F062@cooperw.in>
References: <147135877745.22972.7550246068971515295.idtracker@ietfa.amsl.com> <2377966D-0E2D-4C90-806A-8F82D8C2C33C@cisco.com>
To: "Paul Giralt (pgiralt)" <pgiralt@cisco.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/insipid/P14gkcrH9Hgk_VxkwLyEC45zcOY>
Cc: "insipid-chairs@ietf.org" <insipid-chairs@ietf.org>, "insipid@ietf.org" <insipid@ietf.org>, IESG <iesg@ietf.org>, "draft-ietf-insipid-session-id@ietf.org" <draft-ietf-insipid-session-id@ietf.org>, "christer.holmberg@ericsson.com" <christer.holmberg@ericsson.com>
Subject: Re: [Insipid] Alissa Cooper's Discuss on draft-ietf-insipid-session-id-26: (with DISCUSS and COMMENT)
X-BeenThere: insipid@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: SIP Session-ID discussion list <insipid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/insipid>, <mailto:insipid-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/insipid/>
List-Post: <mailto:insipid@ietf.org>
List-Help: <mailto:insipid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/insipid>, <mailto:insipid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Aug 2016 13:31:53 -0000

> On Aug 16, 2016, at 10:20 PM, Paul Giralt (pgiralt) <pgiralt@cisco.com> wrote:
> 
> Alissa,
> 
> Thank you for the feedback. Please see inline…
> 
>> On Aug 16, 2016, at 10:46 AM, Alissa Cooper <alissa@cooperw.in> wrote:
>> 
>> 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.
>> 
> 
> 
> 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.

Sounds good.

> 
> 
>> 
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> 
>> == General ==
>> 
>> I do not think RFC 7206 needs to be a normative reference, but I'm also
>> fine with the downref.
>> 
> 
> As Ben already pointed out, there will be a separate discussion about this.
> 
> 
>> == 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?
>> 
> 
> 
> 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.

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

Thanks,
Alissa

> 
> 
>> == 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.
>> 
> 
> 
> As CANCEL only applies to an INVITE, I think it’s implied, but would be happy to change for clarity.
> 
> 
>> == Section 11 ==
>> 
>> 'altering the nil "remote-uuid"' seems like it could be phrased less
>> awkwardly.
> 
> 
> Thanks - will try to rephrase.
> 
>> 
>> "Standard implementations SHOULD NOT expect pre-standard implementations
>> to be consistent in their implementation" -- I don't think this needs
>> normative language.
>> 
> 
> I agree. I will modify.
> 
> 
>> == 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?
>> 
>> 
> 
> 
> 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.
> 
> 
> 
>