Subject: [clue] WGLC comments on signaling draft

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 Oct 2015 18:25:06 -0400

I went through the draft carefully today. In general it looks good and 
reads well. The comments I have are mostly editorial. I've skipped 
section 8 here, and will do it later.

* General

This document uses '"m" line'. RFC3264 and the bundle draft use '"m=" 
line'. We might want to align with that usage.

* Section 1

    CLUE involves two principal
    and inter-related protocol negotiations.

I suggest s/involves/employs/.
It just seems to be a more suitable word here.

    along with which Captures the far end provides a device wishes to
    receive.

I think "provides a" is spurious and should be removed.

    Backwards-compatibility is an important consideration of the
    document:

I think it would be more correct to use "protocol" rather than 
"document" here.

* Section 4.1:

I think there should be a reference to RFC5888 (the group attribute).

* Section 4.2:

    The CLUE data channel [I-D.ietf-clue-datachannel] is a bidirectional
    SCTP over DTLS channel used for the transport of CLUE messages.  This
    channel must be established before CLUE protocol messages can be
    exchanged and CLUE-controlled media can be sent.

This isn't entirely accurate in its use of terminology. I suggest the 
following:

    The CLUE data channel [I-D.ietf-clue-datachannel] is a bidirectional
    data channel [I-D.ietf-rtcweb-data-channel] used for the transport
    of CLUE messages, conveyed within an SCTP over DTLS connection.  This
    channel must be established before CLUE protocol messages can be
    exchanged and CLUE-controlled media can be sent.

(And the reference added.) Or, could simply reduce what is said to:

    The CLUE data channel [I-D.ietf-clue-datachannel] is a bidirectional
    channel used for the transport of CLUE messages. This channel must
    be established before CLUE protocol messages can be exchanged and
    CLUE-controlled media can be sent.

* Section 4.4.1:

    This means that media packets MUST NOT be sent until configuration is
    complete, while non-media packets such as STUN and DTLS MUST be sent
    as normal if negotiated.

I think something should also be said about RTCP. Perhaps add another 
sentence:

    "RTCP MAY be sent as appropriate."

Also, in

    FEC stream), in which case it MUST have the same label value as the
    "m" line on which it is dependent.

I suggest s/is dependent/depends/

* Section 4.4.1.2

    Presently, this specification mandates that CLUE-controlled "m" lines
    must be unidirectional.  This is because setting "m" lines to

ISTM that "Presently," doesn't help here. (*This* specification will 
never say otherwise.) So I suggest removing it.

    It is possible that in future versions of this draft or its successor
    this restriction will be relaxed.

For the same reason, I suggest replacing this with:

    It is possible that in a revision of this document this restriction
    will be relaxed.

Also, change the following:

    However, at present the need to express encode limitations and the
    wish to simplify the offer/answer procedure means that for the time
    being only unidirectional media lines are allowed for CLUE-controlled
    media.

to:

    However, the need to express encode limitations and the
    wish to simplify the offer/answer procedure means that this
    specification requires unidirectional media lines fo CLUE-controlled
    media.

* Section 4.4.2:

There is no mention of what to do about label attributes for recvonly 
m-lines. I think the implication is that there is no use for a label 
here. (The Configure message references the label from the SDP of the 
advertiser.) It might be good to say something about this.

* Section 4.5.2.2:

    If the initial offer contained "a=recvonly" CLUE-controlled media
    lines the recipient SHOULD include corresponding "a=sendonly" CLUE-
    controlled media lines, up to the maximum number of Encodings it
    wishes to advertise.

This doesn't quite work if the recvonly media is incompatible with the 
media the answerer is prepared to provide. So I suggest rewording this as:

    If the initial offer contained "a=recvonly" CLUE-controlled media
    lines the recipient SHOULD include corresponding "a=sendonly" CLUE-
    controlled media lines for compatible encodings, up to the maximum
    number of Encodings it wishes to advertise.

* Section 4.5.3.1:

This references "BAS offer" in the bundle draft. But that concept has 
been removed from that draft. So this reference should be removed.

* Section 4.5.4.1:

    Subsequent offer/answer exchanges MAY also deactive "m" lines for
    CLUE-controlled media.

* Section 4.5.4.3:

    If, in an ongoing CLUE-enabled call, an SDP offer-answer negotiation
    completes in a fashion in which either the CLUE data channel was not
    successfully negotiated or one side did not include the data channel
    in a matching CLUE group then CLUE for this channel is disabled.

s/CLUE for this channel/CLUE for this call/

s/deactive/deactivate/

* Section 5.1:

    The primary implication of this is that a device may receive an SDP
    with a CLUE Encoding it does not yet have capture information for, or
    receive a CLUE Configure message specifying a Capture Encoding for
    which the far end has not negotiated a media stream in SDP.

The language seems a bit awkward. I suggest:

    The primary implication of this is that a device may receive an SDP
    with a CLUE Encoding for which it does not yet have capture
    information, or receive a CLUE Configure message specifying a
    Capture Encoding for which the far end has not negotiated a media
    stream in SDP.

Later, s/specifcs/specifics/

Later there are references to named states and transitions in the clue 
protocol. These don't seem to be consistent with the current state 
machine definitions.

* Section 5.3:

The following is a bit awkward:

    ... For instance, an implementation that receives a
    new SDP offer with three new "a=sendonly" CLUE "m" lines that has not
    received the corresponding CLUE Advertisement providing the capture
    information for those streams SHOULD NOT include corresponding
    "a=recvonly" lines in its answer, but instead should make a new SDP
    offer when ...

I suggest:

    ... For instance, an implementation that receives a
    new SDP offer with three new "a=sendonly" CLUE "m" lines for which
    it has received no CLUE Advertisement providing the corresponding
    capture information SHOULD include corresponding "a=inactive"
    lines in its answer, and should make a new SDP offer with
    "a=recvonly" when ...

* Section 6:

I think the following:

    The Captures that constitute these MCCs may or may not be defined in
    the Advertisement message.

would be clearer if you replace "constitute" with "contribute to".

* Section 7.2:

    ... there are several steps an implementation may wish to
    ameliorate the cost ...

Above is missing some words: s/ameliorate/take to ameliorate/

* Section 7.2.2:

Again, the reference to BAS is no longer valid.

* Section 8:

I'm deferring my review of this section. I sent a separate query about 
it, because the text seems inconsistent with the call flow. Until I have 
a call flow that is consistent with the text I can't do a meaningful review.

* Section 11.1:

The formatting of the table entry has been mangled. (It needs to go into 
an <artwork> element.)

Also, should probably have a reference to RFC5888 for specification of 
the registration template.

* Section 11.2:

Again, the formatting of the data has been mangled.

Also, ASN.1 Identifier 1.3.6.1.8.4.26 is now taken. The next one 
available is now 29. (I suspect the assignment of the precise value 
ought to be left to IANA to avoid races like this. But I don't know if 
they consider than their responsibility.)

* Section 14.2

I am no longer affiliated with Huawei. Please remove the affiliation 
from my info.

	Thanks,
	Paul