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

[Simon Pietro Romano <[e-mail]>]

Hello Mark,

> That's fine with me, too.

The clueId is now optional.

Cheers,

Simon

                     				            _\\|//_
                           				   ( O-O )
      ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    				Simon Pietro Romano
             				 Universita' di Napoli Federico II
                		     Computer Engineering Department 
	             Phone: [phone] -- Fax: [phone]
                                           e-mail: [e-mail] <mailto:[e-mail]>

		    <<Molti mi dicono che lo scoraggiamento è l'alibi degli 
		    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
               			                     oooO
       ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
					                 \ (            (   )
			                                  \_)          ) /
                                                                       (_/



> On 24 Jan 2017, at 17:36, Mark Duckworth <[e-mail]> wrote:
> 
> That's fine with me, too.
> Mark
> 
> 
> -------- Original message --------
> From: Christian Groves <[e-mail] <mailto:[e-mail]>> 
> Date:01/24/2017 00:35 (GMT-05:00) 
> To: [e-mail] <mailto:[e-mail]> 
> Subject: Re: [clue] Mark's WGLC comments on protocol-10 
> 
> I'd vote for making it optional and providing some more text on what the
> information could actually be.
> 
> Regards, Christian
> 
> 
> On 23/01/2017 8:00 PM, Simon Pietro Romano wrote:
> > 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.
> >>
> >> 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?
> > 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.
> >
> >
> >> 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).”
> > Done.
> >
> > Thanks a lot,
> >
> > Simon & Roberta
> >
> >> Mark
> >> From: clue <[e-mail] <mailto:[e-mail]>> on behalf of Simon Pietro Romano <[e-mail] <mailto:[e-mail]>>
> >> Sent: Monday, January 02, 2017 11:21 AM
> >> To: [e-mail] <mailto:[e-mail]>
> >> Cc: [e-mail] <mailto:[e-mail]>
> >> Subject: 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
> >>> [e-mail] <mailto:[e-mail]>
> >>> https://www.ietf.org/mailman/listinfo/clue <https://www.ietf.org/mailman/listinfo/clue>
> > _______________________________________________
> > clue mailing list
> > [e-mail] <mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/clue <https://www.ietf.org/mailman/listinfo/clue>
> >
> 
> _______________________________________________
> clue mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/clue <https://www.ietf.org/mailman/listinfo/clue>
> _______________________________________________
> clue mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/clue <https://www.ietf.org/mailman/listinfo/clue>