Subject: Re: [clue] WGLC of CLUE Framework now started. Ends Wednesday Dec 17. - my review

From: "Roni Even" <[email-masked]>
Date: Sun, 14 Dec 2014 18:20:46 +0200

Hi,
I read the document  (also the 19 version) and have no technical issues.
Some editorial comments

1.  I think it may be good to add a reference in section 3 to the taxonomy
draft mostly since section 4.1 of the taxonomy also discuss the terminology
of CLUE.

2. In section 3 "Global View" the term scene is mentioned, I assume it
should be capture scene or maybe add to capture scene that when scene is
mentioned it refers to capture scene

3. In section 4 bullet (5) "RTP media flows"  and "RTP flows" probably "RTP
streams" according to taxonomy. Also in section 9 "The maximum number of
streams  that can result .." "RTP streams"?

4. In section 4 "While the actual mapping of those RTP flows  to the header
fields of the RTP packets is not subject of
   this specification, the large number of possible permutations of
sensible options a Media Provider can make available to a Media
   Consumer makes a mechanism desirable that allows to narrow down the
number of possible options that a SIP offer-answer exchange has to
   consider."  This all text is not clear to me , why header fields ....

5. SDP is mentioned in section 3 and in other sections without reference
that appears only in section 9.1

6. Section 5 discuss the model and from the following text "First, it MUST
construct and send a CLUE Configure
   message to tell the Provider what the Consumer wishes to receive.
Second, it MAY, but is not necessarily REQUIRED to, use the
   information provided to tailor the SDP  it is going to send during   the
following SIP offer/answer exchange, and its reaction to SDP it
   receives in that step." It may seem that the offer/answer is initiated by
the Consumer after the Advertisement, yet later in the document it says that
the consumer needs the offer in order to have the individual encodes before
sending the Configure. In this section the issue of who will send the first
offer is not mentioned.

7. In section 5 "   A CLUE-implementing device interoperates with a device
that does  not support CLUE, because the non-CLUE device does, by definition
,  not understand the offer of a CLUE channel in the initial  offer/answer
exchange and, therefore, will reject it. This  rejection MUST be used as the
indication to the CLUE-implementing  device that the other side of the
communication is not compliant  with CLUE, and to fall back to behavior that
does not require CLUE ."  What about the feature tag, I thought that this is
how you know if CLUE is supported.

8. In section 7.3.3 you repeat the definition of "global View" from section
3.

9. At the end of section 1 maybe need to reference also the protocol
document.

10. A nit in section 10 "Therefore it can choose to receive a sub-set
ofCaptures indicated by the MCC."  "of Captures"

Thanks
Roni Even
As individual

> -----Original Message-----
> From: clue [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 25 November, 2014 9:22 PM
> To: CLUE
> Subject: [clue] WGLC of CLUE Framework now started. Ends Wednesday Dec
> 17.
> 
> During IETF91 we agreed to start the WGLC of the Framework immediately
> after the meeting. So I am calling the start of that WGLC today. At least
here in
> the US people are pretty distracted around the holidays (starting this
week), so
> we will allow extra calendar time to complete this. The end of this WGLC
will
> be end of the day (wherever you are) on Wednesday December 17. That gives
> three weeks plus roundoff for today.
> 
> 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. So we need careful, thorough reviews of the
full
> document, not just diffs from a prior version.
> 
> To ensure that you are all paying attention, please respond to this
message
> with your indication that you indeed plan to submit a review.
> 
> (To get the ball rolling, *I* plan to do a WGLC reviewe of this draft.)
> 
> 	Thanks,
> 	Paul (for all the chairs)
> 
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: "Duckworth, Mark" <[email-masked]>
Date: Mon, 15 Dec 2014 12:25:56 -0800

Hi Roni,

Thanks for the comments.  My responses below.

Mark

> From: clue [mailto:[email-masked]] On Behalf Of Roni Even
> Sent: Sunday, December 14, 2014 11:21 AM
> To: 'CLUE'
> Subject: Re: [clue] WGLC of CLUE Framework now started. Ends Wednesday
> Dec 17. - my review
> 
> Hi,
[Duckworth, Mark] I thought we already agreed not to.  From the IETF90 minutes:
Action (chairs): Post an email to the list around whether the CLUE WG
          documents should have a dependency (and align with) the AVTEXT taxonomy
          document.  Status: CLOSED.  There were no responses at all to the email:
          http://www.ietf.org/mail-archive/web/clue/current/msg03999.html

> mentioned it refers to capture scene
[Duckworth, Mark] How about add definition for Scene: short for Capture Scene.
Similar to Consumer definition

> streams  that can result .." "RTP streams"?
[Duckworth, Mark] changing flow to stream in section 4 is okay with me.
Section 9 - we already define stream to mean RTP, but adding "RTP" here
is okay with me.
 
>    consider."  This all text is not clear to me , why header fields ....
[Duckworth, Mark] It is referring to the multiplexing as mentioned in previous sentence.

> that appears only in section 9.1
[Duckworth, Mark] SDP offer/answer [RFC3264] is referenced in section 1, which 
is what section 3 is referring to.  Do you think we need to add more references to SDP RFC?

> sending the Configure. In this section the issue of who will send the first
[Duckworth, Mark] An o/a could be initiated by the consumer, but doesn't have to be.
This is really defined in the signaling document.  I think we don't need to get into
any more detail in the framework.
Also I suggest removing "but is not necessarily REQUIRED to" because it is
redundant with the previous MAY.

> how you know if CLUE is supported.
[Duckworth, Mark] Good point.  The signaling document says "Presence of
the data channel in a CLUE group in an SDP offer or answer also serves,
along with the "sip.clue" media feature tag, as an indication that the device
supports CLUE"
I think the text here in the framework is okay, and accurate, because the non-CLUE
device will reject the CLUE channel, right?  Or should the framework be less
specific and just say the CLUE device knows the other device is non-CLUE by the
mechanisms described in the signaling doc?

> 8. In section 7.3.3 you repeat the definition of "global View" from section
[Duckworth, Mark] Yes, is it a problem?  Should we remove some of this text
from section 7.3.3?

> 9. At the end of section 1 maybe need to reference also the protocol
[Duckworth, Mark] I agree.

> ofCaptures indicated by the MCC."  "of Captures"
[Duckworth, Mark] Thanks

---

From: "Roni Even" <[email-masked]>
Date: Tue, 16 Dec 2014 00:13:46 +0200

Hi Mark,
Inline, I removed the comments that I agree with your response
Roni

> > 1.  I think it may be good to add a reference in section 3 to the
> > taxonomy draft mostly since section 4.1 of the taxonomy also discuss
> > the terminology of CLUE.
[Roni Even] The Taxonomy refers to CLUE

> 
> > 3. In section 4 bullet (5) "RTP media flows"  and "RTP flows" probably
> > "RTP streams" according to taxonomy. Also in section 9 "The maximum
> > number of streams  that can result .." "RTP streams"?
> Section 9 - we already define stream to mean RTP, but adding "RTP" here is
> okay with me.
[Roni Even] I think that throughout the document it should be consistent
with the correct term which is RTP stream, not stream or flow.

> > 4. In section 4 "While the actual mapping of those RTP flows  to the
> > header fields of the RTP packets is not subject of
> [Duckworth, Mark] It is referring to the multiplexing as mentioned in
previous
> sentence.

 [Roni Even] I do not understand what  you it means the mapping of RTP flows
to the header fields of the RTP packets and how it relates to multiplexing?.
> 
> > 5. SDP is mentioned in section 3 and in other sections without
> > reference that appears only in section 9.1
> [Duckworth, Mark] SDP offer/answer [RFC3264] is referenced in section 1,
> which is what section 3 is referring to.  Do you think we need to add more
> references to SDP RFC?
[Roni Even] Yes

> > 6. Section 5 discuss the model and from the following text "First, it
> > MUST construct and send a CLUE Configure
> >    receives in that step." It may seem that the offer/answer is
> > initiated by the Consumer after the Advertisement, yet later in the
> > document it says that the consumer needs the offer in order to have
> > the individual encodes before sending the Configure. In this section
> > the issue of who will send the first offer is not mentioned.
> [Duckworth, Mark] An o/a could be initiated by the consumer, but doesn't
have
> to be.
[Roni Even] My understanding from the framework is that the consumer cannot
send a configure without having an offer from the provider since it will not
know the individual encoding to compose the configure, so if the  consumer
wants to send a configure first as stated it will need the offer from the
provider
>From section 10
"In order to meaningfully create and send an initial Configure, the
   Consumer needs to have received at least one Advertisement, and an
   SDP offer defining the Individual Encodings, from the Provider."

> This is really defined in the signaling document.  I think we don't need
to get
> into any more detail in the framework.
> > that does  not support CLUE, because the non-CLUE device does, by
> > definition ,  not understand the offer of a CLUE channel in the
> > initial  offer/answer exchange and, therefore, will reject it. This
> > rejection MUST be used as the indication to the CLUE-implementing
> > device that the other side of the communication is not compliant  with
> > CLUE, and to fall back to behavior that does not require CLUE ."  What
> > about the feature tag, I thought that this is how you know if CLUE is
> > supported.
the
> data channel in a CLUE group in an SDP offer or answer also serves, along
with
> the "sip.clue" media feature tag, as an indication that the device
supports
> CLUE"
> I think the text here in the framework is okay, and accurate, because the
non-
> CLUE device will reject the CLUE channel, right?  Or should the framework
be
> less specific and just say the CLUE device knows the other device is
non-CLUE
> by the mechanisms described in the signaling doc?
[Roni Even] The question is if an endpoint sends an offer with the sip.clue
feature tag but do not offer a data channel currently, what does it mean or
is it require to send both?

> > 8. In section 7.3.3 you repeat the definition of "global View" from
> > section 3.
[Roni Even] Yes

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 15 Dec 2014 17:32:52 -0500

> is it require to send both?

The feature tag indicates a *capability*, but doesn't indicate if the 
endpoint wants to use that capability. The data channel in the o/a 
indicates a desire to use it.

	Thanks,
	Paul

---

From: "Roni Even" <[email-masked]>
Date: Tue, 16 Dec 2014 00:46:10 +0200

Hi Paul,
The text  ia was referring to is 
> about the feature tag, I thought that this is how you know if CLUE is 

So to be more precise, if the answer rejects the data channel, can it still
send the clue feature tag?
In this case is the answerer CLUE compliant?
My understanding is that the other side is CLUE compliant if it sends the
feature tag but do not want to do CLUE now but may do it later

Roni

> Sent: 16 December, 2014 12:33 AM
> To: [email-masked]
> > [Roni Even] The question is if an endpoint sends an offer with the
> > sip.clue feature tag but do not offer a data channel currently, what
> > does it mean or is it require to send both?
> 
endpoint
> wants to use that capability. The data channel in the o/a indicates a
desire to
> use it.

---

From: "Duckworth, Mark" <[email-masked]>
Date: Tue, 16 Dec 2014 04:55:43 -0800

Hi Roni,
I removed some of the comments in the discussion, and have a couple more comments below.
Mark

> From: Roni Even [mailto:[email-masked]]
> Sent: Monday, December 15, 2014 5:14 PM
> To: Duckworth, Mark; 'CLUE'
> Subject: RE: [clue] WGLC of CLUE Framework now started. Ends Wednesday
> Dec 17. - my review
> 
> Hi Mark,
[Duckworth, Mark] If it isn't clear, how about if we just remove it?  I don't think
it adds anything important.  So I suggest removing " While the actual mapping of
those RTP flows  to the header fields of the RTP packets is not subject of
this specification"

>    SDP offer defining the Individual Encodings, from the Provider."
[Duckworth, Mark] I think that really should be "SDP offer or answer".  It 
doesn't matter which one does offer and which one does answer.  Remember,
typically an offer or an answer comes from both a provider and a consumer because they
are colocated.
Maybe the source of confusion is the words "first" and "second" in the framework
text.  I think it should not be specifying an order here.  If reword it to not specify an
order, would that be clear?

> is it require to send both?
[Duckworth, Mark] I suggest the framework doc should be less specific about this,
and refer to the signaling document.  You have a good question that should
be answered in the signaling document.

Mark