[Insipid] AD Evaluation of draft-ietf-insipid-session-id-22
"Ben Campbell" <ben@nostrum.com> Sun, 15 May 2016 00:46 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 10F8712B071; Sat, 14 May 2016 17:46:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.326
X-Spam-Level:
X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 6dhiLhuzFOQS; Sat, 14 May 2016 17:46:46 -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 6111012B025; Sat, 14 May 2016 17:46:43 -0700 (PDT)
Received: from [10.0.1.18] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u4F0kfip033126 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 14 May 2016 19:46:41 -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.18]
From: Ben Campbell <ben@nostrum.com>
To: draft-ietf-insipid-session-id.all@ietf.org, insipid@ietf.org
Date: Sat, 14 May 2016 19:46:42 -0500
Message-ID: <D126986C-5821-4DD3-AB10-CD54B2387491@nostrum.com>
MIME-Version: 1.0
X-Mailer: MailMate (1.9.4r5234)
Archived-At: <http://mailarchive.ietf.org/arch/msg/insipid/JIO3D_bAcwFBAa7YI-qQI31pE6o>
Subject: [Insipid] AD Evaluation of draft-ietf-insipid-session-id-22
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: Sun, 15 May 2016 00:46:48 -0000
Hi, This is my AD Evaluation of draft-ietf-insipid-session-id-22. I have a number of comments, and think that at least the "substantive" comments should be addressed prior to IETF last call. Thanks! Ben. ------------- Substantive Comments: - Abstract: The abstract makes it sound like the draft is multi-protocol. It's not, it's SIP specific. I recognize the idea is that the syntax could be used across signaling protocols, but this particular draft only defines how to do so for SIP. Please clarify. - General - 4.1, 2nd paragraph: Why is the requirement for version 4 or 5 UUIDs only a SHOULD? It seems like we should really avoid any sort of persistent identifies in the UUID. If we really need the SHOULD, please describe when it might be reasonable to choose otherwise. - 4.2, 2nd paragraph: "such as when a UA first initiates a SIP request," Should that be a SIP INVITE request, or SIP dialog-initiating request? -- 2nd to last paragraph: Is there a normative statement elsewhere than devices other than conference-focuses MUST NOT reuse UUIDs? (Also, the MUST in this paragraph belongs with the section on MDUs. If this text means to simply point out that the MDU section has this requirement, then please state it descriptively here.) -- last paragraph: I'm a bit uncomfortable with making storage completely out of scope, due to the potential "information-at-rest" security or privacy implications. (I note that RFC7206 cites 6872 for this purpose). - 6, paragraph 8: Has the working group discussed the privacy implications of requiring an endpoint to keep the same UUID after a redirect, refer, or INVITE-with-replaces? It may be that the peer and intermediaries already know the source of the 2nd dialog is the same that of the first, but I think it's a topic that needs some mention in the text. -- paragraph 10: Both the MAY and MUST seem incorrect here. The MAY is a statement of fact, and the MUST is a description of rules elsewhere in the draft. I suggest using descriptive language for both. -7, first paragraph: Does the assumption of no "special treatment" means the intermediary passing the session-id unchanged? Removes it? Either? -- 4th paragraph: What happens when a B2BUA that does not implement session-id aggregates responses? If it passes through the peer UUIDs unchanged, does anything break? Can the UAC be misled about the UUID of the resulting peer? -- 3rd paragraph from end: I'm confused by "A non- redirected or rejected response", since responses neither get redirected or rejected. Do you mean a redirection response or a rejection response? (Perhaps using response code classes would be more clear.) "MUST replace its own UUID" - In what message(s)? -- 2nd to last paragraph: Why are the SHOULDs not MUSTs? Can you describe situations in which one might reasonably not follow the SHOULDs? -- last paragraph: The first "MAY" seems like a statement of fact. Is the 2nd MAY appropriate? That is, intermediary allowed to _not_ do this, and let endpoints get out of sync? -8, last paragraph: Why is the SHOULD not a MUST? When might one reasonably not follow it? -9, 2nd paragraph: Does this assume that the conference is new to each subsequent MCU? That is, one would never use this approach to bridge two existing conferences that already have their own UUIDs? - 10.3: Why doesn't the b2bua send a re-invite to update the uuid as in the next example? - 10.5: Please don't use the name of a trademarked, commercial service in an RFC. Can you recast this as a "web-based conference service"? Also, this should be clarified to be one of many ways to implement this use case, not necessarily a preferred way. (For example, endpoints might initiate the INVITE requests toward the focus.) - 10.7, first bullet: It seems highly unlikely that a 3pcc server would not be dialog stateful. - 11: This section creates MUST level requirements for an implementation to be backwards compatible with a pre-standard, proprietary version. That seems to be a stretch. Did the working group really intend that an implementation could not choose not to implement this section? -- 4th bullet: Wny isn't the presence or absence of remote-uuid sufficient for responses? -- 5th bullet: This seems out of place; it's about non-compliant implementations of this document, not about backwards compatibility. - 6th bullet: Why would an "old" implementation include "remote-uuid" at all? - 12, first paragraph: The MUST here seems to conflict with the previous SHOULD about using UUID versions other than 4 or 5. (see previous comment). -- 3rd paragraph: Is there an impact if something tampers with or lies about session-Id values? - 15: Thank you for including this. Editorial Comments and Nits: -1, first paragraph: Please expand SIP on first mention. - 4.2, 4th paragraph: Please expand PBX on first mention. -- 2nd to last paragraph: This referes to conference focus, but most of the relevant section discusses MDUs. Please use consistent terms. (either may be okay, but "focus" probably better captures the signaling vs media role.) -6, paragraph 9: What is meant by "negatively affect"? Is this allowed to affect the session in neutral or positive ways? -- paragraph 11: Consider s/"MUST take care to ensure"/"MUST ensure". The "take care" part softens the message. -- 2nd to last paragraph: Redundant normative statements. Consider making the first one descriptive, since the second is the more precise of the two. (This pattern repeats in section 7 paragraph 7) - 7, 2nd paragraph: "which is why intermediaries" I think that's one reason why. There are likely others. -- 7th paragraph: "If an intermediary receives a SIP message without a Session-ID header field or valid header field value..." Does this mean either without session-id, or with session-Id but without a valid value? (As worded, the second part reads like it means without any valid header fields, but that doesn't make sense.) -8, first paragraph: This seems redundant to previous sections. 10.1, paragraph before SIP detail: It's not really complete if you omit stuff :-) 10.3: There's no description of the initial re-invite. 11, paragraph 5: It's not clear what "that" refers to.
- [Insipid] AD Evaluation of draft-ietf-insipid-ses… Ben Campbell
- Re: [Insipid] AD Evaluation of draft-ietf-insipid… Ben Campbell
- Re: [Insipid] AD Evaluation of draft-ietf-insipid… Paul E. Jones
- Re: [Insipid] AD Evaluation of draft-ietf-insipid… Ben Campbell
- Re: [Insipid] AD Evaluation of draft-ietf-insipid… Paul Giralt (pgiralt)
- Re: [Insipid] AD Evaluation of draft-ietf-insipid… Paul Giralt
- Re: [Insipid] AD Evaluation of draft-ietf-insipid… Ben Campbell
- Re: [Insipid] AD Evaluation of draft-ietf-insipid… Ben Campbell
- Re: [Insipid] AD Evaluation of draft-ietf-insipid… Paul Giralt (pgiralt)