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

From: "Duckworth, Mark" <[email-masked]>
Date: Fri, 11 Nov 2016 23:11:00 +0000

The document is in good shape. I have some minor and editorial comments.

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

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?

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

5.2 "copied in the the" remove a "the"

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"

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.

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.

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.

Mark