Subject: Re: [clue] I-D Action: draft-ietf-clue-signaling-04.txt

From: "Xiaojing (Lennard)" <[email-masked]>
Date: Tue, 2 Dec 2014 10:49:14 +0000

Hi Rob,

I've got a few comments on the signaling draft:
1. Section 4.2, last sentence of paragraph 2, "and the "mid" of the "m" line of a data channel "mid" MUST NOT be included in more than one CLUE group", the "mid" before MUST NOT seems like a replication.
2. Section 4.3, second paragraph, "If negotiation of the data channel in SDP failed due to lack of CLUE support by the remote device or for any other reason the other "m" lines in the group are still considered CLUE-controlled and under all the restrictions of CLUE-controlled media specified in this document." 
I think some clarification is needed here.IMHO, if CLUE is not supported by A, there isn't any media from A that is CLUE-controlled.
I also have confusion when I read the last paragraph of section 4.3. I don't quite understand a media is CLUE-controlled from the sender and at the same time not CLUE-controlled from the reciever.
3. Section 4.5.2.1 talks about "negotiation use of CLUE and CLUE data channel". But the last sentence of this section suggest "A CLUE-capable recipient that receives an "m" line for a data channel but no corresponding CLUE group containing the "mid" of that "m" line SHOULD include a corresponding data channel "m" line if there are any other non-CLUE protocols it can convey over that channel, otherwise it SHOULD NOT negotiate the data channel." 
IMHO, to focus on CLUE, it would be more specific to say that the data channel cannot be used for CLUE, but can be used for other protocols.
4. Section 4.5.4.2, "one or both sides of the call add the CLUE data channel "m" line to their SDP and places the "mid" for that channel in corresponding CLUE groups then the call is now CLUE-enabled". My confusion here is, how can a call be CLUE-enabled if only one side is CLUE-enabled and he did what is described in the above while the other is not or didn't do. And from my understanding, a call is CLUE-enabled after successfull negotiation for the CLUE data channel, not after indication of CLUE support.
5. Section 4.5.4.3, "If the SCTP channel is still present but not included in the CLUE group semantic the CLUE protocol MUST be closed." By SCTP channel, do you mean data channel? And "CLUE protocol be closed" looks a little bit odd. CLUE message transport be stopped? CLUE protocol disabled?
6. Section 7.2.2, the first sentence, just a little strange to read "may be mandated".
7. Page 20 last paragraph, a minor editorial: "maximum three encodings" means a maximum of three encodings or three encodings of maximum capability or else? 

Best regards,
Lennard

> -----Original Message-----
> From: clue [mailto:[email-masked]] On Behalf Of internet-
> [email-masked]
> Sent: Tuesday, October 28, 2014 4:20 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [clue] I-D Action: draft-ietf-clue-signaling-04.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>  This draft is a work item of the ControLling mUltiple streams for
> tElepresence Working Group of the IETF.
> 
>         Title           : CLUE Signaling
>         Authors         : Paul Kyzivat
>                           Lennard Xiao
>                           Christian Groves
>                           Robert Hansen
> 	Filename        : draft-ietf-clue-signaling-04.txt
> 	Pages           : 34
> 	Date            : 2014-10-27
> 
> Abstract:
>    This document specifies how CLUE-specific signaling such as the CLUE
>    protocol [I-D.ietf-clue-protocol] and the CLUE data channel
>    [I-D.ietf-clue-datachannel] are used with each other and with
>    existing signaling mechanisms such as SIP and SDP to produce a
>    telepresence call.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-clue-signaling/
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-clue-signaling-04
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-signaling-04
> 
> 
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue