Subject: [clue] WGLC: draft-ietf-clue-signaling-06 - ends 21 October

From: Daniel Burnett <[email-masked]>
Date: Thu, 8 Oct 2015 06:27:11 -0400

To all CLUE participants,

I am officially starting a WGLC on the CLUE signaling draft.  The end of
this WGLC will be end of the day (wherever you are) on Wednesday October
21. That will leave us a couple of days that week to finalize the Yokohama
agenda.

If all is in order this will be the last review of this document by the WG
before it goes to the ADs and the IESG.  Now is the time for careful,
thorough reviews of the full document.  We would specifically like to ask
Mark, Paul, and Roni to review.

To help in planning, please respond to this message if you plan to submit a
review. Thank you to Paul and Simon for volunteering already.

-- dan
(for all the chairs)

---

From: "Duckworth, Mark" <[email-masked]>
Date: Thu, 8 Oct 2015 11:16:38 -0700

Hi Dan,
Yes, I will review the signaling document.
Mark

From: clue [mailto:[email-masked]] On Behalf Of Daniel Burnett
Sent: Thursday, October 08, 2015 6:27 AM
To: [email-masked]
Subject: [clue] WGLC: draft-ietf-clue-signaling-06 - ends 21 October

I am officially starting a WGLC on the CLUE signaling draft.  The end of this WGLC will be end of the day (wherever you are) on Wednesday October 21. That will leave us a couple of days that week to finalize the Yokohama agenda.

If all is in order this will be the last review of this document by the WG before it goes to the ADs and the IESG.  Now is the time for careful, thorough reviews of the full document.  We would specifically like to ask Mark, Paul, and Roni to review.

To help in planning, please respond to this message if you plan to submit a review. Thank you to Paul and Simon for volunteering already.

-- dan
(for all the chairs)

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 Oct 2015 17:21:15 -0400

I'm in the midst of my detailed review. But I've discovered one thing I 
want to bring up first, because it makes it hard to complete my review.

The example in section 8 has a call flow and a bunch of text explaining 
it. But the included flow doesn't seem to be consistent with the text. 
The flow shows clue message exchanges between offer and answer, which is 
contrary to what is recommended. And the text seems to refer to a 
different flow that doesn't have this problem.

Did the text get updated for an improved flow, while the flow itself 
didn't get updated?

	Thanks,
	Paul

On 10/8/15 6:27 AM, Daniel Burnett wrote:
> 21. That will leave us a couple of days that week to finalize the
> Yokohama agenda.
>
> If all is in order this will be the last review of this document by the
> WG before it goes to the ADs and the IESG.  Now is the time for careful,
> thorough reviews of the full document.  We would specifically like to
> ask Mark, Paul, and Roni to review.
>
> To help in planning, please respond to this message if you plan to
> submit a review. Thank you to Paul and Simon for volunteering already.
>
> -- dan
> (for all the chairs)
>
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

---

From: Robert Hansen <[email-masked]>
Date: Thu, 15 Oct 2015 15:47:43 +0100

Hi Paul,

I agree with you that the flow in Section 8 shouldn't have the 
CONFIGURE/RESPONSE exchange inside the SDP exchange and I should 
definitely rearrange the messages to correct that (I think the contents 
of the messages are all valid though). However, I don't see a mismatch 
between the flow and the explaining text: they seem equally wrong to me 
(and consistent with each other). The first of the two relevant sections 
of the example is:

                       | SIP INVITE 2 (+3 sendonly)       |
                       |--------------------------------->|
                       |                                  |
                       |                                  |
                       |                 CLUE CONFIGURE 1 |
                       |<*********************************|
                       |                                  |
                       |                                  |
                       | CLUE RESPONSE 1                  |
                       |*********************************>|
                       |                                  |
                       |                                  |
                       |       SIP 200 OK 2 (+2 recvonly) |
                       |<---------------------------------|
                       |                                  |

While the opening lines of the corresponding text are:

    Alice now sends INVITE 2...

    Bob now has all the information he needs to decide which streams to
    configure.  As such he now sends CONFIGURE 1...

    Alice receives Bob's message CONFIGURE 1 and sends RESPONSE 1...

    Bob now sends his SDP answer as part of 200 OK 2....

Which seem to match up. Or am I looking at the wrong thing?

Rob

On 14/10/15 22:21, Paul Kyzivat wrote:
> I'm in the midst of my detailed review. But I've discovered one thing 
> I want to bring up first, because it makes it hard to complete my review.
>
> The example in section 8 has a call flow and a bunch of text 
> explaining it. But the included flow doesn't seem to be consistent 
> with the text. The flow shows clue message exchanges between offer and 
> answer, which is contrary to what is recommended. And the text seems 
> to refer to a different flow that doesn't have this problem.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 15 Oct 2015 11:49:37 -0400

Rob,

I'll look at it again, and give a concrete proposals for how to adjust 
to be more reasonable and consistent with the rules. I'll also comment 
about the places where the text seemed to be inconsistent with the flow.

In any case, I already sent my comments on all the *other* sections of 
the doc.

	Thanks,
	Paul

---

From: Robert Hansen <[email-masked]>
Date: Thu, 15 Oct 2015 16:51:06 +0100

Thanks, and yes, thanks very much for the review of the other sections. 
I'm currently planning to go through everyone's comments once the 
deadline comes and adjusting things accordingly.

Rob

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 15 Oct 2015 16:14:28 -0400

OK. Here are my comments on Section 8. (I was mistaken about the text 
being inconsistent with the call flow.)

* Section 8:

In 2nd paragraph, s/snippet/snippets/

About the flow: The call flow shows INVITE 2 followed by a clue 
configure and response followed by 200 ok. This certainly encourages the 
inference that there is a dependency on doing the configure before 
sending the invite response. That is contrary to protocol requirements. 
(And the same holds for INVITE 3.)

Of course this could just be coincidence without coupling. But I think 
it would be better to structure the flow to be more realistic.

Also, there should be responses for the Advertisements.

After the flow:

    In INVITE 1, Alice sends Bob a SIP INVITE including in the SDP body
    the basilar audio and video capabilities ...

Do you really mean "basilar", or did you mean "basic"? (I find that 
basilar is indeed a word, new to me, but is it appropriate here? It 
seems to be strictly a medical term.)

Then:

    ...  Bob wishes to receive
    initial media, and so includes corresponding non-CLUE-controlled
    audio and video lines.  ...

The lines must be included regardless. So, s/includes/accepts the/

Then:

    Alice now sends her CLUE Advertisement (ADVERTISEMENT 1).
    ...
    Bob also sends his CLUE Advertisement (ADVERTISEMENT 2).

This shows Alice's advertisement going first, and Bob's advertisement 
being sent after receiving Alice's. This is of course possible, but it 
may suggest that there is a cause/effect relationship. It would be good 
to at least mention that the decisions are independent. It might make 
sense to show the messages crossing on the wire, making it clear that 
they are independent.

Later: s/Alices receives/Alice receives/

Later: you get to the point where Alice sends INVITE 2. At this point, 
both Alice and Bob need to update the SDP. There is potential for a race 
condition for who goes first. Why is it that Alice goes first, and Bob 
doesn't try before receiving Alice's reINVITE? It would be good to 
explain this. (Or simply state that this just of of several ways this 
might play out depending on timing.)

Then:

    Bob now has all the information he needs to decide which streams to
    configure.  As such he now sends CONFIGURE 1.  ...

I think it would be good to show the 200 for INVITE 2 prior to sending 
the Configure. This will make clear that the sip signaling not be 
delayed. Or just mention that they are both sent nearly concurrently.

Then s/its receptions/its reception/

Then:

    Having received this Alice now has all the information she needs to
    send CONFIGURE 2.  She requests the two static Captures from Bob, to
    be sent on Encodings "foo" and "bar".

Again, I think it would be better to show the 200 for INVITE 3 before 
sending INVITE 3.

Finally, there should probably be another O/A at the end to completely 
disable the non-clue media. (Maybe it would be interesting to show that 
one end keeps the non-clue media until the clue media is flowing, while 
the other end stops receiving the non-clue media as soon as it confirms 
this will be a clue call.)

I've attached an attempt at a revised call flow consistent with my 
comments above. (This can no doubt be improved.)

	Thanks,
	Paul

---

From: Robert Hansen <[email-masked]>
Date: Fri, 16 Oct 2015 11:01:04 +0100

Will fix the call flow issue.

On the subject of using the word 'basilar'... I got it from you :). The 
very first signaling draft to include a call flow example, 
https://tools.ietf.org/html/draft-kyzivat-clue-signaling-01 , uses the 
phrase "the basilar audio and video capabilities", which has continued 
to be used in every subsequent update. Now that I check I can't find a 
sense where it makes sense either, and even if there is somewhere 
obscure definition that allows it the fact that two of the authors of 
the document aren't aware of it means we should change it anyway - I'll 
change it.

Rob

On 15/10/15 21:14, Paul Kyzivat wrote:
> configure and response followed by 200 ok. This certainly encourages 
> the inference that there is a dependency on doing the configure before 
> sending the invite response. That is contrary to protocol 
> requirements. (And the same holds for INVITE 3.)
>
> may suggest that there is a cause/effect relationship. It would be 
> good to at least mention that the decisions are independent. It might 
> make sense to show the messages crossing on the wire, making it clear 
> that they are independent.
>
> both Alice and Bob need to update the SDP. There is potential for a 
> race condition for who goes first. Why is it that Alice goes first, 
> and Bob doesn't try before receiving Alice's reINVITE? It would be 
> good to explain this. (Or simply state that this just of of several 
> ways this might play out depending on timing.)
>
> Then:
>
> disable the non-clue media. (Maybe it would be interesting to show 
> that one end keeps the non-clue media until the clue media is flowing, 
> while the other end stops receiving the non-clue media as soon as it 
> confirms this will be a clue call.)
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 16 Oct 2015 10:40:41 -0400

> On the subject of using the word 'basilar'... I got it from you :). The

!?!

I believe you, but that is odd, because I didn't even know what it meant 
during this review until I looked it up.

Maybe somebody contributed that text to me.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 16 Oct 2015 11:08:42 -0400

> Maybe somebody contributed that text to me.

I just figured it out. It appeared in draft-kyzivat-clue-signaling-01. 
Those changes from -00 were contributed by Roberta and Simon. So it 
comes from Italian-English. :-)

	Thanks,
	Paul

---

From: "Duckworth, Mark" <[email-masked]>
Date: Wed, 21 Oct 2015 19:42:50 -0700

I reviewed the signaling document and have just a few minor comments.  I am an SDP offer/answer novice.  So since I can understand this document, that suggests it is well written and gives a good clear explanation of the important points.

I’m trying to avoid comments already raised by Christian and Paul.

The title says “signaling”, but several places have “signalling”.  I suppose it should always be “signaling”.

Section 5:
     “provides some recommendations on dealing with intermediary stages in non-atomic operations”.
s/intermediary/intermediate/

Section 8:
    “followed by an summary of each message”
s/an/a/

s/Capture Scene entries/Capture Scene Views/ (two places) (we renamed these in the framework)

At beginning of section 8 it says “ACKs are not discussed.”  But then later it says when Bob sends CONFIGURE 1, “This also serves as an ack for Alice’s ADVERTISEMENT 1.”  But since Bob was waiting for SDP before sending the configure, shouldn’t Bob have sent a separate ACK already?

Section 12:
    “CLUE makes use of a number of protocols and mechanism”
s/mechanism/mechanisms/

    “these is not a mandatory requirement”
s/these/this/

Mark

-- dan
(for all the chairs)