[Insipid] Alissa Cooper's Discuss on draft-ietf-insipid-session-id-26: (with DISCUSS and COMMENT)
"Alissa Cooper" <alissa@cooperw.in> Tue, 16 August 2016 14:46 UTC
Return-Path: <alissa@cooperw.in>
X-Original-To: insipid@ietf.org
Delivered-To: insipid@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 790EF12D859; Tue, 16 Aug 2016 07:46:17 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alissa Cooper <alissa@cooperw.in>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.29.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147135877745.22972.7550246068971515295.idtracker@ietfa.amsl.com>
Date: Tue, 16 Aug 2016 07:46:17 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/insipid/lMn_h-1wgskXZM4YgQbSUZyMFMw>
Cc: insipid@ietf.org, insipid-chairs@ietf.org, draft-ietf-insipid-session-id@ietf.org, christer.holmberg@ericsson.com
Subject: [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
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: Tue, 16 Aug 2016 14:46:17 -0000
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?
- Re: [Insipid] Alissa Cooper's Discuss on draft-ie… Paul Giralt
- Re: [Insipid] Alissa Cooper's Discuss on draft-ie… Ben Campbell
- Re: [Insipid] Alissa Cooper's Discuss on draft-ie… Paul Giralt (pgiralt)
- Re: [Insipid] Alissa Cooper's Discuss on draft-ie… Alissa Cooper
- Re: [Insipid] Alissa Cooper's Discuss on draft-ie… Brett Tate
- Re: [Insipid] Alissa Cooper's Discuss on draft-ie… Paul Giralt (pgiralt)
- Re: [Insipid] Alissa Cooper's Discuss on draft-ie… Alissa Cooper
- Re: [Insipid] Alissa Cooper's Discuss on draft-ie… Ben Campbell
- [Insipid] Alissa Cooper's Discuss on draft-ietf-i… Alissa Cooper
- Re: [Insipid] Alissa Cooper's Discuss on draft-ie… Paul Kyzivat