Re: [Insipid] AD Evaluation of draft-ietf-insipid-session-id-22

"Paul Giralt (pgiralt)" <pgiralt@cisco.com> Wed, 25 May 2016 20:28 UTC

Return-Path: <pgiralt@cisco.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 4E2DA12DCFE; Wed, 25 May 2016 13:28:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.947
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 hNMtVes1J_VG; Wed, 25 May 2016 13:28:32 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34C0F12DD19; Wed, 25 May 2016 13:28:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9094; q=dns/txt; s=iport; t=1464208110; x=1465417710; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ek3TvPPjuJLOdanHGLm8uOItZnpq1/Lo7qDwMRkeeUI=; b=K8QJ7YYmL49IGjOr++Vr7EBEunYvLL46Cvc1DS+VNKO6y02fPxy98+dq otfZBCXkfkAAPsskB8T2cUYPQ7p8IhEExKGaNQZipgvH+SU5J4ivakKHB qOwFTddLmpZsam8rfEdFW8MaLAFcl/+7/KRj0jAiuJxXEALcHzLj4eRKT s=;
X-Files: signature.asc : 842
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DfAgAsCkZX/40NJK1cgzdWfQa5cw6Be?= =?us-ascii?q?BcLhSVKAoFEOBQBAQEBAQEBZSeEQwEBAQMBAQEBIEUGCwULAgEIGCoCAicLJQI?= =?us-ascii?q?EDgUOiBkIDrFMkUoBAQEBAQEBAQEBAQEBAQEBAQEBAQEOCQWGJ4F2CIJOhCkCg?= =?us-ascii?q?xUrgi4FiAQKhVeBMokgAYMqgWiJDYFphE+IZIYziRgBHgFDggYcgUtuiEkBBhk?= =?us-ascii?q?ffwEBAQ?=
X-IronPort-AV: E=Sophos;i="5.26,365,1459814400"; d="asc'?scan'208";a="108195672"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 May 2016 20:28:29 +0000
Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u4PKSSAZ032000 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 25 May 2016 20:28:28 GMT
Received: from xch-rtp-018.cisco.com (64.101.220.158) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 25 May 2016 16:28:27 -0400
Received: from xch-rtp-018.cisco.com ([64.101.220.158]) by XCH-RTP-018.cisco.com ([64.101.220.158]) with mapi id 15.00.1104.009; Wed, 25 May 2016 16:28:27 -0400
From: "Paul Giralt (pgiralt)" <pgiralt@cisco.com>
To: Ben Campbell <ben@nostrum.com>
Thread-Topic: [Insipid] AD Evaluation of draft-ietf-insipid-session-id-22
Thread-Index: AQHRtr+vKVjxdiM8PEOFvYIZQTMt2Z/KXYcA
Date: Wed, 25 May 2016 20:28:27 +0000
Message-ID: <8035B1A8-EC0A-4216-9FDE-349F0D56A289@cisco.com>
References: <D126986C-5821-4DD3-AB10-CD54B2387491@nostrum.com> <DD022B6D-38EC-4ED0-81CD-B737619CF37C@nostrum.com>
In-Reply-To: <DD022B6D-38EC-4ED0-81CD-B737619CF37C@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.81.96.60]
Content-Type: multipart/signed; boundary="Apple-Mail=_2341DF57-4473-4597-A2AD-AA9836457803"; protocol="application/pgp-signature"; micalg=pgp-sha512
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/insipid/hI8j-B1FR2A1w7XQEYLNPv5fYus>
Cc: "insipid@ietf.org" <insipid@ietf.org>, "draft-ietf-insipid-session-id.all@ietf.org" <draft-ietf-insipid-session-id.all@ietf.org>
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
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:28:35 -0000

Ben,

Sorry for not replying earlier. I’m almost done with replies to all your questions. Should have a formal reply within a couple of days.

-Paul

> On May 25, 2016, at 3:57 PM, Ben Campbell <ben@nostrum.com> wrote:
> 
> 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 mailing list
> insipid@ietf.org
> https://www.ietf.org/mailman/listinfo/insipid