Re: [Insipid] AD Evaluation of draft-ietf-insipid-session-id-22
"Paul E. Jones" <paulej@packetizer.com> Wed, 25 May 2016 20:10 UTC
Return-Path: <paulej@packetizer.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 08E2112D543; Wed, 25 May 2016 13:10:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.428
X-Spam-Level:
X-Spam-Status: No, score=-3.428 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_NONE=-0.0001, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=packetizer.com
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 TsoFGl0kYQ4k; Wed, 25 May 2016 13:10:41 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 595B212D10E; Wed, 25 May 2016 13:10:41 -0700 (PDT)
Received: from [156.106.229.0] ([156.106.229.0]) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id u4PKAcXN011656 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 May 2016 16:10:39 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1464207040; bh=EydXop2N/xe/ThI3D7q1DzTQirpbCflqxVNQOzW5/ak=; h=From:To:Subject:Date:In-Reply-To:Reply-To; b=ck9VdWMyzVWAfumEzYP2cwjhkCIbf1G4bimYS55kujVCvzDwvbwXB+d1m+yrt+/PP 8lWfOkMiifu/DcsO8ALzhPKtiMtL7FtGiz33YMuPALYB0FDgnuLL6CkPnR1CiPmd2p WABgPf4dclGGi0EqJRAI5uvsbfhWLsqhTwy3Gmuc=
From: "Paul E. Jones" <paulej@packetizer.com>
To: Ben Campbell <ben@nostrum.com>, draft-ietf-insipid-session-id.all@ietf.org, insipid@ietf.org
Date: Wed, 25 May 2016 20:10:40 +0000
Message-Id: <eme95b0680-96a9-4e4a-9910-a427d2fe4063@helsinki>
In-Reply-To: <DD022B6D-38EC-4ED0-81CD-B737619CF37C@nostrum.com>
User-Agent: eM_Client/6.0.24928.0
Mime-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.16 (dublin.packetizer.com [10.137.60.122]); Wed, 25 May 2016 16:10:40 -0400 (EDT)
Archived-At: <http://mailarchive.ietf.org/arch/msg/insipid/bfScGP3hFkQPmXZk-2G4s2rJYQs>
Subject: Re: [Insipid] AD Evaluation of draft-ietf-insipid-session-id-22
X-BeenThere: insipid@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: "Paul E. Jones" <paulej@packetizer.com>
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: Wed, 25 May 2016 20:10:44 -0000
We've been formulating a reply. Coordination, time, etc. But, a reply is coming very soon. Paul ------ Original Message ------ From: "Ben Campbell" <ben@nostrum.com> To: draft-ietf-insipid-session-id.all@ietf.org; insipid@ietf.org Sent: 5/25/2016 3:57:28 PM Subject: Re: [Insipid] AD Evaluation of draft-ietf-insipid-session-id-22 >Authors, any thoughts on these? > >Thanks! > >Ben. > >On 14 May 2016, at 19:46, Ben Campbell wrote: > >> 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 mailing list >> insipid@ietf.org >> https://www.ietf.org/mailman/listinfo/insipid
- [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)