Re: [Insipid] draft-ietf-insipid-session-id-13

Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 27 January 2015 22:25 UTC

Return-Path: <prvs=8469c1ee92=pkyzivat@alum.mit.edu>
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 EA7181A9081 for <insipid@ietfa.amsl.com>; Tue, 27 Jan 2015 14:25:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 mMzpcnjnxz9Y for <insipid@ietfa.amsl.com>; Tue, 27 Jan 2015 14:25:25 -0800 (PST)
Received: from alum-mailsec-scanner-7.mit.edu (alum-mailsec-scanner-7.mit.edu [18.7.68.19]) by ietfa.amsl.com (Postfix) with ESMTP id 4D32E1A902E for <insipid@ietf.org>; Tue, 27 Jan 2015 14:25:23 -0800 (PST)
X-AuditID: 12074413-f79f26d0000030e7-5d-54c81052169e
Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id D8.0C.12519.25018C45; Tue, 27 Jan 2015 17:25:22 -0500 (EST)
Received: from Paul-Kyzivats-MacBook-Pro.local (c-50-138-229-151.hsd1.ma.comcast.net [50.138.229.151]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id t0RMPMWo022208 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for <insipid@ietf.org>; Tue, 27 Jan 2015 17:25:22 -0500
Message-ID: <54C81052.2010003@alum.mit.edu>
Date: Tue, 27 Jan 2015 17:25:22 -0500
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: insipid@ietf.org
References: <949EF20990823C4C85C18D59AA11AD8B4A0D55FC@FR711WXCHMBA04.zeu.alcatel-lucent.com> <em45407f81-06bb-4442-871c-707554d1dd23@sydney> <949EF20990823C4C85C18D59AA11AD8B4A0D58C7@FR711WXCHMBA04.zeu.alcatel-lucent.com>
In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B4A0D58C7@FR711WXCHMBA04.zeu.alcatel-lucent.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrIIsWRmVeSWpSXmKPExsUixO6iqBskcCLEYOs+U4v5958xOTB6LFny kymAMYrbJimxpCw4Mz1P3y6BO6N30zqmgmt6FffvtzA2MJ5X7mLk5JAQMJHYenY3K4QtJnHh 3nq2LkYuDiGBy4wSHx++hXL+MUlc3bODsYuRg4NXQFtiTn8GSAOLgKrE1dONbCA2m4CWxJxD /1lAbFGBZIk1Wyexg9i8AoISJ2c+AYuLCIhI/L47BSwuLGAucXfLYmaI+XcZJRZ+nAqW4BSI lTh0qIsdZBezgLXEt91FIGFmAXmJ7W/nME9g5J+FZOwshKpZSKoWMDKvYpRLzCnN1c1NzMwp Tk3WLU5OzMtLLdI118vNLNFLTSndxAgJPuEdjLtOyh1iFOBgVOLhjbh+LESINbGsuDL3EKMk B5OSKK/w/+MhQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4778DyvGmJFZWpRblw6SkOViUxHnV lqj7CQmkJ5akZqemFqQWwWRlODiUJHgL+E6ECAkWpaanVqRl5pQgpJk4OEGGc0mJFKfmpaQW JZaWZMSD4jG+GBiRICkeoL0TQNp5iwsSc4GiEK2nGBWlxHmngyQEQBIZpXlwY2Ep5RWjONCX wrybQap4gOkIrvsV0GAmoMF9K4+ADC5JREhJNTCyLsmbZtrTEGazbiOjPPdZ5Se6peX6bEtF drHPeVwUH3PvoM7KFwuXzrjDvGbj/OZneosahNfPW62hvezT+67FC1ezbahedUMmhsP0JNvM 42vzXj28NF83te3Pzo6TzIElLFryuo3H67jDjF6VnvZ/aJs97evGt9dMDWW0O0R2bNU8se38 kbIwJZbijERDLeai4kQAFta8fQQDAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/insipid/LsRWk9OmAlBBIciFZH1xx8qspZ8>
Subject: Re: [Insipid] draft-ietf-insipid-session-id-13
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: Tue, 27 Jan 2015 22:25:29 -0000

OK. I'm now reviewing -13 somewhat carefully.

Regarding the new text in section 5:

    The Session-ID header-value is technically case-INSENSITIVE, but only
    lowercase characters are allowed in the sess-uuid components.
    Receiving entities MUST treat sess-uuid components as case-
    insensitive and not produce an error if an uppercase character is
    received in a sess-uuid.

That can be interpreted to mean that an error should not be reported if 
the uuid contains a "Z". I suggest a tweak to that:

    Receiving entities MUST treat sess-uuid components as case-
    insensitive and not produce an error if an uppercase HEXDIG
    character is received in a sess-uuid.

Now that the intent has been specified, the actual syntax needs to 
match. It currently doesn't. Currently we have:

      sess-uuid           = 32(DIGIT / %x61-66)  ;32 chars of [0-9a-f]

which isn't consistent with the new statement. Instead, now about:

      sess-uuid           = 32(HEXDIG)

And then replace "The production DIGIT is defined in [RFC5234]" with 
"The production HEXDIG is defined in [RFC5234]".

Also in section 5:

    The "local-uuid" in the Session-ID header represents the UUID value
    of the UA transmitting the message.  If the UA transmitting the
    message previously received a UUID value from its peer endpoint, it
    MUST include that UUID as the "remote" parameter in each message it
    transmits.  For example, a Session-ID header might appear like this:

This doesn't mention the possibility that *different* remote-uuids are 
received over the course of the session. I suggest:

    The "local-uuid" in the Session-ID header represents the UUID value
    of the UA transmitting the message.  If the UA transmitting the
    message previously received one or more UUID values from its peer
    endpoint in a session, it SHOULD include the most recently received
    UUID as the "remote" parameter in each message it transmits within
    that session. (Exceptions are explicitly called out elsewhere in this
    document.)  For  example, a Session-ID header might appear like
    this:

Section 7:

The term "3PCC" is used without definition. Should include a definition 
and a reference to RFC3725.

Section 8:

Here and elsewhere are references to "cascaded MCUs". Neither "MCU" nor 
"cascaded MCU" are defined. I don't know where you go for those 
definitions. (There is a definition of MCU in 
draft-ietf-avtext-rtp-grouping-taxonomy, but it focuses on media and 
isn't sip-specific.)

Also, s/When creating a cascaded conferencing/When creating a cascaded 
conference/

Section 9.3:

It would be very helpful to see subsequent signaling in this case. 
Suppose Alice subsequently sends a reINVITE. What will that look like? 
(Alice will send it with {A,B}. Does the B2BUA change it to {A,C} or 
leave it alone? Either way I presume Carol sends back {A,C}.)

	Thanks,
	Paul

On 1/25/15 4:34 PM, DRAGE, Keith (Keith) wrote:
> So I guess I am looking for responses from Roland J., Paul K, and Brett
> T. as to whether we now have a version to go forward.
> regards
> Keith
>
>     ------------------------------------------------------------------------
>     *From:* Paul E. Jones [mailto:paulej@packetizer.com]
>     *Sent:* 24 January 2015 19:55
>     *To:* DRAGE, Keith (Keith); insipid@ietf.org
>     *Subject:* Re: [Insipid] draft-ietf-insipid-session-id-13
>
>     I think so, but I would like to get positive confirmation from others.
>     Paul
>     ------ Original Message ------
>     From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com
>     <mailto:keith.drage@alcatel-lucent.com>>
>     To: "Paul E. Jones" <paulej@packetizer.com
>     <mailto:paulej@packetizer.com>>; "insipid@ietf.org"
>     <insipid@ietf.org <mailto:insipid@ietf.org>>
>     Sent: 1/24/2015 2:20:55 PM
>     Subject: Re: [Insipid] draft-ietf-insipid-session-id-13
>>     Apart from this one issue, does this represent closure of all
>>     issues that are currently being discussed?
>>     Keith
>>
>>         ------------------------------------------------------------------------
>>         *From:* insipid [mailto:insipid-bounces@ietf.org
>>         <mailto:insipid-bounces@ietf.org>] *On Behalf Of *Paul E. Jones
>>         *Sent:* 24 January 2015 19:20
>>         *To:* Paul E. Jones; insipid@ietf.org <mailto:insipid@ietf.org>
>>         *Subject:* Re: [Insipid] draft-ietf-insipid-session-id-13
>>
>>         Folks,
>>         I just noted an alignment problem in the figure in 9.8.1.
>>         I'll fix that in my local copy, but will hold off publishing
>>         another just for that small issue.
>>         Paul
>>         ------ Original Message ------
>>         From: "Paul E. Jones" <paulej@packetizer.com
>>         <mailto:paulej@packetizer.com>>
>>         To: "insipid@ietf.org <mailto:insipid@ietf.org>"
>>         <insipid@ietf.org <mailto:insipid@ietf.org>>
>>         Sent: 1/24/2015 2:12:42 PM
>>         Subject: [Insipid] draft-ietf-insipid-session-id-13
>>>         Folks,
>>>         I submitted draft -13 that contains all of the text changes
>>>         suggested thus far.  Please let me know if you see any issues
>>>         in that text.
>>>         I believe all (or at least most) of the WGLC comments have
>>>         been addressed.  If that's not the case, we can continue
>>>         discussion on the list of course.
>>>         The chairs have (for a while I might add) expressed a sense
>>>         of urgency to move this along.  So, please let the group (and
>>>         chairs) know if there are other things we need to address or
>>>         whether we can suggest to send this for publication?
>>>         Paul
>>
>
>
> _______________________________________________
> insipid mailing list
> insipid@ietf.org
> https://www.ietf.org/mailman/listinfo/insipid
>