Re: [Insipid] I-D Action: draft-ietf-insipid-session-id-23.txt

"Paul Giralt (pgiralt)" <> Tue, 28 June 2016 20:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4A4AD12D848 for <>; Tue, 28 Jun 2016 13:07:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.947
X-Spam-Status: No, score=-15.947 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.426, 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 dbd8c1sYdh24 for <>; Tue, 28 Jun 2016 13:07:22 -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 8CA8012D828 for <>; Tue, 28 Jun 2016 13:06:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3218; q=dns/txt; s=iport; t=1467144383; x=1468353983; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=zObnH1TjMsjUU5RnPUP6E+6B7zvApbqoaxa1QD5nVOw=; b=kYVj72mWa7yZnjieSUFloycC3jmbB/8flfCpvAfTH+45fPlNfVWiagsH aTkM1hhXQg1mHwfFJQwX768USMgYgV4I7XUwkWipbf58bj2mnpTwkInUd zKG2peyUveVx2hjFZMCzXjBfFgDxD6Rpk7j0WS7z+ZWSdF7kRjvBXJv6w Q=;
X-Files: signature.asc : 842
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A1AgAG2HJX/49dJa1bgz6BWborgXuGG?= =?us-ascii?q?AKBNDgUAQEBAQEBAWUnhE0BAQMBI1YFCwIBCEICAjIlAgQKBBOIGgizbJAwAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBDg6GKIF3CIJOhBGDMCuCLwWGBJJ+AYMtgWyGV?= =?us-ascii?q?4JJjySPfgEeNoIIHIFMiR9/AQEB?=
X-IronPort-AV: E=Sophos;i="5.26,542,1459814400"; d="asc'?scan'208";a="291107378"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Jun 2016 20:06:22 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id u5SK6M8b007650 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 28 Jun 2016 20:06:22 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 28 Jun 2016 16:06:21 -0400
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Tue, 28 Jun 2016 16:06:21 -0400
From: "Paul Giralt (pgiralt)" <>
To: Ben Campbell <>
Thread-Topic: [Insipid] I-D Action: draft-ietf-insipid-session-id-23.txt
Thread-Index: AQHRzdIv8M2blTO35k+l2Gt9c0ch+5/5BxMAgAUeHYCAAXNIgA==
Date: Tue, 28 Jun 2016 20:06:21 +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=_44C67915-BCC7-43E5-AF23-057304BC8FA6"; protocol="application/pgp-signature"; micalg=pgp-sha512
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>
Subject: Re: [Insipid] I-D Action: draft-ietf-insipid-session-id-23.txt
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: Tue, 28 Jun 2016 20:07:24 -0000


Thanks for the guidance. See inline…

> - The text states that, since the session-IDs must not contain device or user identifying information, they have no privacy considerations. That sort of statement is a bit of a red flag during IESG review. In particular, it would be good to also say something about the use of a session-ID as a persistent identifier to correlate across session.

Ok - I will fix this.

> As it is, 4.2 says they generate a new, previously unused UUID. Is there any normative text about reusing the UUID for more than one "session"? (Not counting the text about transfers, etc.).

The only the only text  is Section 6 which describes the conditions under which the UUID is maintained. The transfer / redirect cases are the only time a UUID is “reused” and even then, it’s not really being reused for a different “session” but that depends on what you fine as being a session. That may be the issue - that we don’t clearly define what a session is.

I added an additional line at the end of paragraph 1 in section 4.2 to highlight the persistence of the UUID mentioned in Section 6:

	Section 6 describes how the UUIDs selected by the source and destination UAs persist
        for the duration of the session.

Not sure if that’s necessary, but I figured it can’t hurt.

Would it help if we give a clearer definition of what a “session” means in the context of this specification?

> - The statement that session-id "MUST NOT be used for billing purposes" will probably draw objections. I suggest that be changed ot "is not appropriate for billing purposes." (Not really new text, but the revisions drew my attention to it.)

Ok - fixed.

> Thanks!
> Ben.