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

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 24 Jan 2015 19:12:42 +0000

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

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 24 Jan 2015 19:19:41 +0000

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" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Sent: 1/24/2015 2:12:42 PM
Subject: [Insipid] draft-ietf-insipid-session-id-13

>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
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sat, 24 Jan 2015 19:20:55 +0000

Apart from this one issue, does this represent closure of all issues that are currently being discussed?

Keith

________________________________
From: insipid [mailto:[email-masked]] On Behalf Of Paul E. Jones
Sent: 24 January 2015 19:20
To: Paul E. Jones; [email-masked]
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" <[email-masked]<mailto:[email-masked]>>
To: "[email-masked]" <[email-masked]<mailto:[email-masked]>>
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

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 24 Jan 2015 19:55:27 +0000

I think so, but I would like to get positive confirmation from others.

Paul

------ Original Message ------
From: "DRAGE, Keith (Keith)" <[email-masked]>
To: "Paul E. Jones" <[email-masked]>; "[email-masked]" 
<[email-masked]>
Sent: 1/24/2015 2:20:55 PM
Subject: Re: [Insipid] draft-ietf-insipid-session-id-13

>>--------------------------------------------------------------------------------
>>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
>>
>>>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
>>>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sun, 25 Jan 2015 21:34:44 +0000

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:[email-masked]]
Sent: 24 January 2015 19:55
To: DRAGE, Keith (Keith); [email-masked]
Subject: Re: [Insipid] draft-ietf-insipid-session-id-13

Paul

------ Original Message ------
From: "DRAGE, Keith (Keith)" <[email-masked]<mailto:[email-masked]>>
To: "Paul E. Jones" <[email-masked]<mailto:[email-masked]>>; "[email-masked]" <[email-masked]<mailto:[email-masked]>>
Sent: 1/24/2015 2:20:55 PM
Subject: Re: [Insipid] draft-ietf-insipid-session-id-13

Keith

________________________________
From: insipid [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Paul E. Jones
Sent: 24 January 2015 19:20
To: Paul E. Jones; [email-masked]<mailto:[email-masked]>
Subject: Re: [Insipid] draft-ietf-insipid-session-id-13

Folks,

Paul

------ Original Message ------
From: "Paul E. Jones" <[email-masked]<mailto:[email-masked]>>
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Sent: 1/24/2015 2:12:42 PM
Subject: [Insipid] draft-ietf-insipid-session-id-13

Folks,

Paul

---

From: <[email-masked]>
Date: Mon, 26 Jan 2015 08:02:18 +0100

Hi Paul,
I have reviewed the changes and I’m happy with the current status.
From my side we can proceed with publication.

Best Regards

Roland

Von: insipid [mailto:[email-masked]] Im Auftrag von Paul E. Jones
Gesendet: Samstag, 24. Januar 2015 20:55
An: DRAGE, Keith (Keith); [email-masked]
Betreff: Re: [Insipid] draft-ietf-insipid-session-id-13

Paul

------ Original Message ------
From: "DRAGE, Keith (Keith)" <[email-masked]<mailto:[email-masked]>>
To: "Paul E. Jones" <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Sent: 1/24/2015 2:20:55 PM
Subject: Re: [Insipid] draft-ietf-insipid-session-id-13

Keith

Paul

------ Original Message ------
From: "Paul E. Jones" <[email-masked]<mailto:[email-masked]>>
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Sent: 1/24/2015 2:12:42 PM
Subject: [Insipid] draft-ietf-insipid-session-id-13

Folks,

Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 27 Jan 2015 17:25:22 -0500

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:[email-masked]]
>     *Sent:* 24 January 2015 19:55
>     *To:* DRAGE, Keith (Keith); [email-masked]
>     *Subject:* Re: [Insipid] draft-ietf-insipid-session-id-13
>
>     To: "Paul E. Jones" <[email-masked]
>     <mailto:[email-masked]>>; "[email-masked]"
>     <[email-masked] <mailto:[email-masked]>>
>>     Apart from this one issue, does this represent closure of all
>>     issues that are currently being discussed?
>>     Keith
>>
>>         ------------------------------------------------------------------------
>>         *From:* insipid [mailto:[email-masked]
>>         <mailto:[email-masked]>] *On Behalf Of *Paul E. Jones
>>         *Sent:* 24 January 2015 19:20
>>         *To:* Paul E. Jones; [email-masked] <mailto:[email-masked]>
>>         *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
>>         To: "[email-masked] <mailto:[email-masked]>"
>>         <[email-masked] <mailto:[email-masked]>>
>>>         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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/insipid
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 30 Jan 2015 07:16:05 +0000

Paul,

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

Appreciate it!

>    character is received in a sess-uuid.

Good.  Changed.

>"The production HEXDIG is defined in [RFC5234]".

HEXDIG is defined only using uppercase characters.  I fear that might 
introduce more confusion.  How about I just write this:

"not produce an error if an uppercase hexadecimal character is received"

And then leave the syntax alone.

>    document.) For example, a Session-ID header might appear like

Everything sounds good, except the change from MUST to SHOULD?  Do we 
really want to do that?

>and a reference to RFC3725.

Sure.  Done.

>draft-ietf-avtext-rtp-grouping-taxonomy, but it focuses on media and 

I don't know where this is defined, either, though there are many 
documents that discuss cascaded MCUs (e.g., ITU-T F.702).  Let me see if 
I can find a definition we can reference.

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

Fixed that.

>leave it alone? Either way I presume Carol sends back {A,C}.)

OK.  Done.

That would be:

                 | (Suppose Alice modifies the session)            |
      {A,B}      |--------------------re-INVITE------------------->|
      {C,A}      |<--------------------200 OK----------------------|
      {A,C}      |-----------------------ACK---------------------->|

The text description to go with that is:

"Since Alice never received Carol’s UUID from the B2BUA, when Alice 
later attempts to modify the session with a re-INVITE, Alice would send 
the “remote-uuid” = “B” toward Carol.  Carol replies with the 
“local-uuid” = “A”, “remote-uuid” = “A” to reflect what was received in 
the INVITE (which Carol already knew from previous exchanges with the 
B2BUA).  Alice then include “remote-uuid” = “C” in the following ACK 
message."

Sound OK?

Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 30 Jan 2015 11:46:58 -0500

On 1/30/15 2:16 AM, Paul E. Jones wrote:
>> 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:
>>
> introduce more confusion.

HEXDIG is defined using quoted uppercase characters. But quoted strings 
are defined in ABNF to be matched in a case insensitive way. So HEXDIG 
matches any of ABCDEFabcdeg.

> How about I just write this:
>

That is confusing because the text is expanding the valid syntax from 
what is written.

> Everything sounds good, except the change from MUST to SHOULD?  Do we

I did that in order to make room for the exceptions. But I guess either 
way works.

>> Section 7:
>>
>> The term "3PCC" is used without definition. Should include a
>> definition and a reference to RFC3725.
>
> Sure.  Done.
>
>
>>
>> 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

You left the B2BUA out of this. IIUC it is still in the signaling path 
between Alice and Carol. So it is important to show what it does in this 
case too.

	Thanks,
	Paul K

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 31 Jan 2015 23:37:47 +0000

Paul

>I can find a definition we can reference.

I did some digging and also enlisted Stephen Botzko to dig around a bit, 
too.  There are many references to cascaded MCUs, with the earlier 
document Steve was able to find being H.140 from 1988.  Figure 1 shows a 
cascaded MCU, but is not called that.  There are also references in 
F.702, H.323, and a few other ITU documents.  It's also mentioned in RFC 
4575, but also not explicitly defined.

Perhaps we just leave it alone.  "Cascade" is defined in the dictionary 
as "Arrange (a number of devices or objects) in a series or sequence".  
And, that's what we're describing.  So perhaps rather than go with 
looking for a technical definition, we just leave it up to Websters?

Paul