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

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
> clue@ietf.org <mailto:clue@ietf.org>
> https://www.ietf.org/mailman/listinfo/clue <https://www.ietf.org/mailman/listinfo/clue>