Subject: Re: [clue] Mark's WGLC comments on protocol-10

From: Simon Pietro Romano <[email-masked]>
Date: Mon, 2 Jan 2017 17:21:25 +0100

Dear Mark,

thanks a lot for your review. Please find in-line our answers.

Cheers,

Simon & Roberta

> 4. "three main communication layers" - I agree with Christian these are phases, not layers.

Fixed.

>  5. clueId - it still isn't clear to me what is the use of this element. It seems wasteful to include this element in every message.
> Simon previously said "In my view, it is just a name for the CP". But what is it used for? Can we delete clueId if it has no purpose?
> Or if it has a purpose and is meant to be static, can we make it part of the options message exchange rather than every message? And explain what the purpose is?

If we just look at the CLUE protocol level dialogue, the clueId provides a means for properly identifying the interacting parties. What is wrong with this?

>  "Each CP MUST be able to manage up to three (independent) streams of
> sequence numbers" - sounds to me like it is really six streams of sequence numbers. Because each of the three "streams" described actually has separate independent sequence numbers for each direction.
> - initiation phase send
> - initiation phase receive
> - MP send
> - MP receive
> - MC send
> - MC receive
> It also is misleading because it is not required to be both an MC and an MP, so possibly only one of those applies. So it could be either four streams of sequence numbers, or six streams.

Got it. When we say “manage” we actually mean “being responsible for the creation and the update”. So, we were looking at the three roles mentioned above, but by focusing just on the “sending” perspective. Would you like us to reword that sentence? 

>  5.2 "copied in the the" remove a “the"

Done.

>  5.3 "an MP may send new ADV messages to replace the previously advertised options" - this could be misunderstood as relating to the options messages in the initiation phase. How about "an MP may send new ADV messages to replace the previous advertisement”

Done.

>  Christian wrote: "Cl.6.1&6.2: Do we need to indicate that the timeout and retry relates to the transport (e.g. SCTP) rather than application level timers/counters? I'm a bit confused about the descriptions in the draft as we have a reliable transport"
> I thought the timeout and retry stuff was application level, not to account for transport errors but rather to account for application behavior such as an application not responding for whatever reason. So I think it does need to be clarified if Christian and I interpreted it differently.

This is inline with our interpretation. See also our answer to Christian’s point in the related e-mail.

>  Christian wrote: "Cl.6.2 para 3: "If the ADV elaboration is unsuccessful (bad syntax, missing XML elements, etc.), and the number of times this has happened is under the retry treshold," I don't understand why the retry threshold comes in here? Wouldn't the MC simply send a NACK is there's an error. It wouldn't wait for multiple instances of the erroneous message."
> My understanding is it gives the MP an opportunity to send a different advertisement after it receives a nack. It doesn't have to send another copy of the same advertisement.

Agreed. As per above, see also our answer to Christian’s point in the related e-mail.

> 10.1 simple ADV - I suggest updating this to be consistent with the sample XML file in the data model. We already fixed some problems with that sample XML. I see problems, probably the same ones we already fixed, here in the simple ADV example. For example captureID AC0 is a video capture but the description says "main audio from the room". And on page 36 sceneView SE3 and SE4 are the same, so that is a mistake. I think we've done a good review of the XML in the data model, so let's just use that as much as possible to avoid new mistakes in this document.

Done. Thank you for pointing this out.

>  10.2 - same comment, I suggest using the already reviewed XML from the data model, and show it here in the protocol message envelope.

Done.

>  
> Mark
> _______________________________________________
> clue mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/clue <https://www.ietf.org/mailman/listinfo/clue>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 2 Jan 2017 12:05:41 -0500

Forwarding this to Mark's new email address.

-------- Forwarded Message --------
Subject: 	Re: [clue] Mark's WGLC comments on protocol-10
Date: 	Mon, 2 Jan 2017 17:21:25 +0100
From: 	Simon Pietro Romano <[email-masked]>
To: 	[email-masked]
CC: 	[email-masked]

Dear Mark,

Cheers,

Simon & Roberta

Fixed.

> 5. clueId - it still isn't clear to me what is the use of this
> element. It seems wasteful to include this element in every message.
> Simon previously said "In my view, it is just a name for the CP". But
> what is it used for? Can we delete clueId if it has no purpose?
> Or if it has a purpose and is meant to be static, can we make it part
> of the options message exchange rather than every message? And explain
> what the purpose is?

If we just look at the CLUE protocol level dialogue, the clueId provides 
a means for properly identifying the interacting parties. What is wrong 
with this?

> sequence numbers" - sounds to me like it is really six streams of
> sequence numbers. Because each of the three "streams" described
> actually has separate independent sequence numbers for each direction.
> - initiation phase send
> It also is misleading because it is not required to be both an MC and
> an MP, so possibly only one of those applies. So it could be either
> four streams of sequence numbers, or six streams.

Got it. When we say “manage” we actually mean “being responsible for the 
creation and the update”. So, we were looking at the three roles 
mentioned above, but by focusing just on the “sending” perspective. 
Would you like us to reword that sentence?

Done.

> 5.3 "an MP may send new ADV messages to replace the previously
> advertised options" - this could be misunderstood as relating to the
> options messages in the initiation phase. How about "an MP may send
> new ADV messages to replace the previous advertisement”

Done.

> Christian wrote: "Cl.6.1&6.2: Do we need to indicate that the timeout
> and retry relates to the transport (e.g. SCTP) rather than application
> level timers/counters? I'm a bit confused about the descriptions in
> the draft as we have a reliable transport"
> I thought the timeout and retry stuff was application level, not to
> account for transport errors but rather to account for application
> behavior such as an application not responding for whatever reason. So
> I think it does need to be clarified if Christian and I interpreted it
> differently.

This is inline with our interpretation. See also our answer to 
Christian’s point in the related e-mail.

> Christian wrote: "Cl.6.2 para 3: "If the ADV elaboration is
> unsuccessful (bad syntax, missing XML elements, etc.), and the number
> of times this has happened is under the retry treshold," I don't
> understand why the retry threshold comes in here? Wouldn't the MC
> simply send a NACK is there's an error. It wouldn't wait for multiple
> instances of the erroneous message."
> My understanding is it gives the MP an opportunity to send a different
> advertisement after it receives a nack. It doesn't have to send
> another copy of the same advertisement.

Agreed. As per above, see also our answer to Christian’s point in the 
related e-mail.

> 10.1 simple ADV - I suggest updating this to be consistent with the
> sample XML file in the data model. We already fixed some problems with
> that sample XML. I see problems, probably the same ones we already
> fixed, here in the simple ADV example. For example captureID AC0 is a
> video capture but the description says "main audio from the room". And
> on page 36 sceneView SE3 and SE4 are the same, so that is a mistake. I
> think we've done a good review of the XML in the data model, so let's
> just use that as much as possible to avoid new mistakes in this document.

> 10.2 - same comment, I suggest using the already reviewed XML from the
> data model, and show it here in the protocol message envelope.

Done.

> https://www.ietf.org/mailman/listinfo/clue

---

From: Mark Duckworth <[email-masked]>
Date: Thu, 5 Jan 2017 21:45:29 +0000

Hello Simon and Roberta,

About the clueId element - I guess my main point is I don't understand what this is for or how to use it. As an implementer, I wouldn't know what to do with it. As a sender, can I populate this field with any random string? Can I send a different value for this element for every message? If I send random values, or empty string, will it cause a problem? As a receiver, what should I do with this element? Can I safely ignore it? Should I check it for some type of validity, and possibly send a nack if it is invalid? Is it permissible to display the value to a human user? It seems to me the document isn't clear enough about how to use this element, so my interpretation is that this clueId element is useless because there are absolutely no rules about what to do with it. It says the clueId is "identifier (in the form of a generic string) of the CP within the telepresence system". But what is the "identifier"? I don't think this is defined anywhere.

If it is okay for an implementation to send an empty string for clueId, and to ignore any value it receives, then can we add this clarification to the document? If it is not okay, then can you please add an explanation why, and what the additional rules are?

About "Each CP MUST be able to manage up to three (independent) streams of sequence numbers" - okay, now I understand you are talking about the sending side only. But this statement still isn't strictly correct, because a CP doesn't have to be both a mediaProvider and a mediaConsumer, so it doesn't necessarily have to manage three streams. How about this instead, to replace the current paragraph:

"Each CP is responsible for creating and updating up to three independent streams of sequence numbers in messages it sends: (i) one for the messages sent in the initiation phase, (ii) one for the messages sent as MP (if it is acting as a MP), and (iii) one for the messages sent as MC (if it is acting as a MC)."

Mark

________________________________
From: clue <[email-masked]> on behalf of Simon Pietro Romano <[email-masked]>
Sent: Monday, January 02, 2017 11:21 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [clue] Mark's WGLC comments on protocol-10

Dear Mark,

Cheers,

Simon & Roberta

Fixed.

Done.

Done.

Done.

Mark
_______________________________________________
clue mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/clue

---

From: Simon Pietro Romano <[email-masked]>
Date: Mon, 23 Jan 2017 10:00:00 +0100

Hello Mark,

please find in-line our answers to your comments.

> About the clueId element - I guess my main point is I don't understand what this is for or how to use it. As an implementer, I wouldn't know what to do with it. As a sender, can I populate this field with any random string? Can I send a different value for this element for every message? If I send random values, or empty string, will it cause a problem? As a receiver, what should I do with this element? Can I safely ignore it? Should I check it for some type of validity, and possibly send a nack if it is invalid? Is it permissible to display the value to a human user? It seems to me the document isn't clear enough about how to use this element, so my interpretation is that this clueId element is useless because there are absolutely no rules about what to do with it. It says the clueId is "
> identifier (in the form of a
> 
> generic string) of the CP within the telepresence system". But what is the "identifier"? I don't think this is defined anywhere.
> 

In our view the clueId is similar to the “confUserID” (and related XCON-USERID) parameter we introduced in RFC6503 (CCMP) when standardizing centralised conferencing. In that case, the specification was much more detailed. The identifier was mentioned in the framework (as well as in the protocol) and specified in the data model. In the CLUE case we kept this more loose, since the only identifiers that are mentioned in the framework document are those related to individual encodings. As it is defined now, such an identifier can only have application-specific semantics; yet, we believe it might be useful in a number of different scenarios (we’re clueIds in our prototype telepresence architecture, for example). This said, we do not want this to further delay the standardization process. We see two options here (other than leaving things unchanged):

i) we make the clueId optional (minOccurs=0) and leave the rest of the document unchanged. In this way, those who want to rely on this piece of information for their own implementations are allowed to do that;
ii) we remove the clueId from the specification.

We’d like to gather the feeling of the WG on this and are ready to apply any of the proposed solutions.

> "Each CP is responsible for creating and updating up to three independent streams of sequence numbers in messages it sends: (i) one for the messages sent in the initiation phase, (ii) one for the messages sent as MP (if it is acting as a MP), and (iii) one for the messages sent as MC (if it is acting as a MC).”

Done.

Thanks a lot,

Simon & Roberta

>> [email-masked]

---

From: Christian Groves <[email-masked]>
Date: Tue, 24 Jan 2017 16:35:45 +1100

I'd vote for making it optional and providing some more text on what the 
information could actually be.

Regards, Christian

---

From: Mark Duckworth <[email-masked]>
Date: Tue, 24 Jan 2017 16:36:17 +0000

That's fine with me, too.
Mark

-------- Original message --------
From: Christian Groves <[email-masked]>
Date:01/24/2017 00:35 (GMT-05:00)
To: [email-masked]
Subject: Re: [clue] Mark's WGLC comments on protocol-10

Regards, Christian