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

"Ben Campbell" <ben@nostrum.com> Tue, 16 August 2016 15:15 UTC

Return-Path: <ben@nostrum.com>
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 5D38B12D88D; Tue, 16 Aug 2016 08:15:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.147
X-Spam-Level:
X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no
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 FSo1nGcJPt8H; Tue, 16 Aug 2016 08:14:58 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C851812D880; Tue, 16 Aug 2016 08:14:58 -0700 (PDT)
Received: from [10.0.1.4] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u7GFEq7d072168 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 16 Aug 2016 10:14:53 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.4]
From: "Ben Campbell" <ben@nostrum.com>
To: "Alissa Cooper" <alissa@cooperw.in>
Date: Tue, 16 Aug 2016 10:14:52 -0500
Message-ID: <EF3A247A-7284-4260-9DE1-F54358B793B9@nostrum.com>
In-Reply-To: <147135877745.22972.7550246068971515295.idtracker@ietfa.amsl.com>
References: <147135877745.22972.7550246068971515295.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.4r5234)
Archived-At: <https://mailarchive.ietf.org/arch/msg/insipid/gIt8UgGOFn1MDklw0veBRGFE7Es>
Cc: Christer Holmberg <christer.holmberg@ericsson.com>, insipid@ietf.org, The IESG <iesg@ietf.org>, "draft-ietf-insipid-session-id@ietf.org" <draft-ietf-insipid-session-id@ietf.org>, insipid-chairs@tools.ietf.org
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: Tue, 16 Aug 2016 15:15:00 -0000

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:

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

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?

>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> == General ==
>
> I do not think RFC 7206 needs to be a normative reference, but I'm 
> also
> fine with the downref.

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.

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