Re: [Insipid] Posted draft-ietf-insipid-session-id-06

James Polk <jmpolk@cisco.com> Thu, 19 June 2014 21:02 UTC

Return-Path: <jmpolk@cisco.com>
X-Original-To: insipid@ietfa.amsl.com
Delivered-To: insipid@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80D1C1A0409 for <insipid@ietfa.amsl.com>; Thu, 19 Jun 2014 14:02:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.152
X-Spam-Level:
X-Spam-Status: No, score=-15.152 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 Uggi9E3sE0OY for <insipid@ietfa.amsl.com>; Thu, 19 Jun 2014 14:02:25 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB1381A031C for <insipid@ietf.org>; Thu, 19 Jun 2014 14:02:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9107; q=dns/txt; s=iport; t=1403211746; x=1404421346; h=message-id:date:to:from:subject:in-reply-to:references: mime-version:content-transfer-encoding; bh=n0U5BJhag5/ykX7xhngBtuqeKUgjFB1XCW3+SxDCRk0=; b=ESkIWR77IxcCTJMBRf3SVlNho84JYdJNiwHbgzSQrLBHi1gZGAyUmihZ 8Lfp43YPMjwQuzpOEglCKA9ZJDwuJmS+/HwQDOP6ipxaYzqTHbeG0wGyc e+vglYnCNckqTbHNiUeGin0kK02UXPDeSRW++UW4v0c5WIhhioABDwTNL o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Al4GABtPo1OtJA2I/2dsb2JhbABZAYMMUqpwAQEBAQEBBQGRaIZsUwGBDxZ1hAMBAQEEAQEBNTAGGwcEEQQBAQEJHgcPCg4fCQgGARIJEognDcxoF4Vig2CEYCE6BoQ9BIoFOqNcg2AfLw
X-IronPort-AV: E=Sophos;i="5.01,509,1400025600"; d="scan'208";a="54509353"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-6.cisco.com with ESMTP; 19 Jun 2014 21:02:25 +0000
Received: from jmpolk-WS.cisco.com (rcdn-vpn-client-10-89-0-230.cisco.com [10.89.0.230]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s5JL2Oi7010523; Thu, 19 Jun 2014 21:02:24 GMT
Message-Id: <201406192102.s5JL2Oi7010523@alln-core-3.cisco.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Thu, 19 Jun 2014 16:02:24 -0500
To: "Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com>, "Paul E. Jones" <paulej@packetizer.com>, "insipid@ietf.org" <insipid@ietf.org>
From: James Polk <jmpolk@cisco.com>
In-Reply-To: <4A4F136CBD0E0D44AE1EDE36C4CD9D99870C73C3@VOEXM31W.internal .vodafone.com>
References: <em6dea9ca0-54dc-4ba2-9109-3ace50e7baca@sydney> <4A4F136CBD0E0D44AE1EDE36C4CD9D99870C73C3@VOEXM31W.internal.vodafone.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/insipid/vZuovG1zSf7HZA7keAt0hYPnBLM
Subject: Re: [Insipid] Posted draft-ietf-insipid-session-id-06
X-BeenThere: insipid@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Thu, 19 Jun 2014 21:02:28 -0000

At 04:05 AM 6/19/2014, Dawes, Peter, Vodafone Group wrote:
>Content-Language: en-US
>Content-Type: multipart/alternative;
> 
>boundary="_000_4A4F136CBD0E0D44AE1EDE36C4CD9D99870C73C3VOEXM31Winterna_"
>
>Hi Paul,
>I have read through the latest session-id 
>solutions draft 
><http://www.ietf.org/id/draft-ietf-insipid-session-id-06.txt>http://www.ietf.org/id/draft-ietf-insipid-session-id-06.txt 
>and I have the comments below, organized by the 
>line number in the draft. I haven’t yet 
>checked the details of all of the signalling 
>scenarios in clause 9 so I might have some more comments later.

Peter

Thanks for doing this review.

Comments are in-line with the questions/comments you have...

>
>Rgds,
>Peter
>
>
>Line
>Draft Text
>Comment or Question
>line 95
>9.5. Single Focus Conferencing using WebEx ....................16
>Is an internet draft allowed to refer to a commercial product, i.e. WebEx?

This is only in the examples section of the 
document. Because it is used so pervasively 
throughout the industry, and has a substantially 
different model to other conferencing systems (it 
uses another protocol - the secure form of HTTP), 
we thought it wise to have in the doc (but only in the example text).

>lines 149 - 152
>This draft presents a new identifier, referred 
>to as the Session Identifier, or "Session ID", 
>and associated syntax intended to overcome the 
>issues that exist with the currently defined call identifiers.
>It would help to describe the scope of this new 
>identifier, e.g. SIP only, SIP and H.323, or something else.

reading the opening paragraphs of the Intro 
section should answer this for anyone

>lines 169 - 171
>The terms "Session Identifier" and "Session ID" 
>refer to the value of the identifier, whereas 
>"Session-ID" refers to the header used to convey the identifier.
>It would be clearer to refer to the value using 
>only "Session Identifier" throughout.

Sometimes we need to talk about the value "of" 
the header, and others we need to talk about the header itself.

>line 170
>"Session-ID" refers to the header
>Change to "Session-ID" refers to the SIP header field

I'm not sure what you are getting at, this is a 
SIP doc (ITU's SG16 just introduced its own 
version of the Session-ID header (under H.460) this week).

>line 187
>[I-D.ietf-insipid-session-id-reqts] .
>Now RFC7206

indeed

>196 - 197
>The version number in the UUID indicates the 
>manner in which the UUID is generated,
>I did not see version number defined in the draft

it's one number always, version 5 -- and the present doc does say that.

>lines 202 - 211
>When generating a version 5 UUID, endpoints or intermediaries MUST
>    utilize the following "name space ID" (see Section 4.3 of [RFC4122]):
>
>        uuid_t NameSpace_SessionID = {
>            /* a58587da-c93d-11e2-ae90-f4ea67801e29 */
>            0xa58587da,
>            0xc93d,
>            0x11e2,
>            0xae, 0x90, 0xf4, 0xea, 0x67, 0x80, 0x1e, 0x29
>        }
>The procedure and syntax being described by the draft are not clear to me.

look to "Section 4.3 of [RFC4122]" for this

>lines 225 - 228
>Note that if an intermediary is stateless and the endpoint on one end
>    of the call is replaced with another endpoint due to some service
>    interaction, the values used to create the UUID might change  and, if
>    so, the intermediary will compute a different UUID.
>a) If an endpoint is replaced then I would 
>expect the UUID to always change but the text says "might"
>b) text says "the values used to create the 
>UUID" but the draft does not describe a UUID creation algorithm
>c) text says that intermediary is stateless but 
>also says that the intermediary will compute  a 
>different UUID. Surely a stateless intermediary does not compute a UUID

hmm, I have the only mention of the word "stateless" on line 215...

a) this is only under the condition of the intermediary being stateless.
b) ? , we state the UUID reference RFC for 
creating it several times in this section (RFC 4122, S3)
c) not "that" but "if" an intermediate is stateless.


>line 327
>null          = 32("0")
>since 32 zeros is a valid UUID, it might be 
>better to use the string "null" for the NULL value.

I'll consult with my co-editor and the WG

>lines 451 - 454
>If an intermediary receives a SIP message without a Session-ID header
>    value , the intermediary MAY assign a "local-uuid" value to represent
>    the sending endpoint and insert that value into all signaling
>    messages on behalf of the sending endpoint.
>a) Does the intermediary receive an empty 
>Session-ID header field, or a message with no Session-ID header field?
>b) messages can be originated in both 
>directions, so is it always local-uuid that is 
>assigned or is it sometimes remote-uuid?
>c) the text "all signalling messages" does not 
>seem specific enough e.g. the sending endpoint 
>might initiate a completely new dialog

a) not empty, "non-existent"
b) always local, except under the conditions of section 10
c) new dialog means new UUIDs in both directions

>lines 471 - 473
>, the intermediary MUST
>    place the one known UUID in the "remote-uuid" field  and set the
>    "local-uuid" field to the null UUID value.
>Might be clearer to say "use the one known UUID 
>as the "remote-uuid" since "remote-uuid" is not 
>a header field or a header field parameter. Likewise for "local-uuid"

"since "remote-uuid" is not a header field or a 
header field parameter". The local-uuid is a 
header-value and the remote-uuid is a header-parameter, always.

>line 493
>MUST construct a Session-ID header value
>MUST use a Session-ID header value

what if there isn't a Session-ID: there in the 
first place? Then "use" (something that's non-existent) isn't right.

>line 511
>MCUs, including cascaded MCUs ,
>Is "cascaded MCU" a well understood term?

I guess the real question is if the implementor 
understands what the word cascade is. S9.6 gives 
good diagrams of the most common use-cases.

>lines 543 - 546
>Intermediary devices, such as proxies  or session border controllers,
>    or network diagnostics equipment might assume that when they see two
>    or more sessions with different Session Identifiers, but with one
>    UUID in common, that the sessions are part of the same conference.
>Maybe proxies should be left off the list of 
>devices that will examine the session identifier

folks look for proxy when talking about SIP, and 
it it's left off some list involving servers, it'll be a distract (best case)

>line 566
>"N" represents a null UUID
>

I'll talk to my co-editor about this

>lines 585 - 586
>UA-Alice populates the "local-uuid" portion of the Session-ID
>         header-value.
>This bullet seems to be redundant and could be deleted

I'm lost here. There are three instances of the 
word "populates", and UA-Alice isn't on page 11 
(line 585-86). There is a "Bob's UUID populates 
the "remote-uuid"... ", which I'd like to keep

>line 554
>9. Various Call Flow Operations Utilizing the Session ID
>I think it would help if at least one of the 
>signalling examples shows SIP (and maybe SDP). 
>For a while, I was confused about whether 
>"local-uuid" and "remote-uuid" were header field 
>parameters and then wondered why the only IANA 
>registration was for a "remote" parameter.

Instead of this, look at the top of page 7 for the Session-ID: example.

>line 1423
>11. Security Considerations
>At the London meeting, security was identified 
>as an open issue that needs to be fully 
>analysed. Does this analysis still need to be done?

We're always open to more comments. The SecAD 
(Sean Turner ?) has been contacted, but hasn't 
gotten back to us or the chairs...

Again, thanks for the thorough review

James

>
>
>
>From: insipid [mailto:insipid-bounces@ietf.org] On Behalf Of Paul E. Jones
>Sent: 10 April 2014 04:53
>To: insipid@ietf.org
>Subject: [Insipid] Posted draft-ietf-insipid-session-id-06
>
>Folks,
>
>I just uploaded a revised version of the Session 
>ID solution draft.  In this draft, we did the following:
>    * Added text to Section 7 (intermediaries) 
> to describe handling of provisional responses
>        * WIth one typo "intermediaries 
> transmits" (will fix that in the next version)
>    * Changed the UUID values used for OOD REFER 
> (Section 9.9) per list discussion
>    * Added one new paragraph on security considerations
>Please have a look at the draft and suggest 
>other things we need to address, including any 
>issues you believe we need to raise in the security considerations.
>
>Thanks,
>Paul
>
>_______________________________________________
>insipid mailing list
>insipid@ietf.org
>https://www.ietf.org/mailman/listinfo/insipid