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

"Paul Giralt (pgiralt)" <> Wed, 17 August 2016 02:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5DFC612D16F; Tue, 16 Aug 2016 19:20:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.768
X-Spam-Status: No, score=-15.768 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id grfud33Suqao; Tue, 16 Aug 2016 19:20:34 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 385871288B8; Tue, 16 Aug 2016 19:20:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=7881; q=dns/txt; s=iport; t=1471400434; x=1472610034; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=WN9ExBMUJjmOqiwhitKhymi4mrpYOEgdYB6g1fIUTDE=; b=cslYxPJ3+pqUCw81xnvWQ/GzxNhDZa+5Che47lAWlLIPS4Joh1Q7yybc P54urbkuOT1PJZGgoKHrp9kcX4bmbulnkfGk9yV3D/RSEGLHKuRfdx30Z 0WF32ltH5txL9Y5zCXP6NOWq7PsN/TiSohleR4jsBJb6v+lvMEvliejRn I=;
X-Files: signature.asc : 842
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BFAgD0yLNX/5hdJa1eAYNEVnwHtzqCD?= =?us-ascii?q?4F9JIV5AoFcOBQCAQEBAQEBAV4nhF4BAQQBI1YFCwIBCBgqAgIyJQIEDgUOiBs?= =?us-ascii?q?IDq5XkC4BAQEBAQEBAQEBAQEBAQEBAQEBAQ8JBYYqgXiCVYQSEQFOgk8rgi8Fi?= =?us-ascii?q?CoMhx2JcQGDPYFzb4h7gWuEXIkBjDmDdwEeNoISHBeBNW4BhSo3fwEBAQ?=
X-IronPort-AV: E=Sophos;i="5.28,529,1464652800"; d="asc'?scan'208";a="309864597"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Aug 2016 02:20:33 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id u7H2KWfK015547 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 17 Aug 2016 02:20:33 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 16 Aug 2016 22:20:32 -0400
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Tue, 16 Aug 2016 22:20:31 -0400
From: "Paul Giralt (pgiralt)" <>
To: Alissa Cooper <>
Thread-Topic: Alissa Cooper's Discuss on draft-ietf-insipid-session-id-26: (with DISCUSS and COMMENT)
Thread-Index: AQHR98z0yw3SCwXgGEGWQR1DRtj3RKBMr0qA
Date: Wed, 17 Aug 2016 02:20:31 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/signed; boundary="Apple-Mail=_34EC576B-5E5A-4C78-BE7A-CF9F56AC1952"; protocol="application/pgp-signature"; micalg=pgp-sha512
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>, "" <>, The IESG <>, "" <>, "" <>
Subject: Re: [Insipid] Alissa Cooper's Discuss on draft-ietf-insipid-session-id-26: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: SIP Session-ID discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 17 Aug 2016 02:20:36 -0000


Thank you for the feedback. Please see inline…

> On Aug 16, 2016, at 10:46 AM, Alissa Cooper <> 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
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> == 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.

> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> == 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.

> == 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.