Session Signaling for Controlling Multiple Streams for Telepresence (CLUE)
draft-ietf-clue-signaling-15

Notification list changed to "Daniel C. Burnett" <danielcburnett@gmail.com>, Roni Even <roni.even@huawei.com> from "Daniel C. Burnett" <danielcburnett@gmail.com>, "Roni Even" <roni.even@mail01.huawei.com>, Roni Even <roni.even@huawei.com>

The document needs to be updated to reflect IESG feedback, as well as adding information to the SDP registration section indicating the proper MUX category IANA needs to include in its registration.

[Ballot comment]
I skimmed the document and I trust Ben and Adam to catch various SIP/RTP related issues, if any.

I agree that draft-ietf-rtcweb-data-channel should be a normative reference.

[Ballot comment]
I agree with Benjamin Kaduk's comment about considering whether draft-ietf-rtcweb-data-channel should be a normative reference for at least clue-signaling, but it's worth noting that draft-ietf-rtcweb-data-channel is a C238 draft in Missref at the RFC Editor, and was approved about the same time that DTLS 1.2 was published. I'm hoping that there's no reason to look at C238 drafts when we're doing IESG Evaluation for drafts that refer to them (directly or indirectly), but thought I should ask before CLUE comes out as RFCs.

Notification list changed to "Daniel C. Burnett" <danielcburnett@gmail.com>, "Roni Even" <roni.even@mail01.huawei.com>, Roni Even <roni.even@huawei.com> from "Daniel C. Burnett" <danielcburnett@gmail.com>, "Roni Even" <roni.even@mail01.huawei.com>

[Ballot comment]
Thanks for the work on this. I have some substantive and editorial comments:

*** Substantive Comments ***

§2: Is there a reason not to use the new (preferred) boilerplate from RFC 8174? There are a lot of lower case instances of "must" and "should". These are ambiguous under the old boilerplate.

§4.4.1.1: "Each  (in encodingIDList) in a CLUE ADVERTISEMENT message
SHOULD represent an Encoding defined in SDP..."

I started out asking why this was not a MUST. But after reading the discussion in §5.1 and elsewhere, I think the issue is too nuanced to be conveyed by a single normative keyword. Perhaps this should say something to the effect of "SHOULD converge to representing...". Or even "will eventually represent...but may not match for short time after encoding changes..."  (The same applies to the SHOULD in the following paragraph.)

§4.5.1:

- What sort of user experience is expected when a CLUE device talks to a non-CLUE device? Is this a realistic use case? (I'm not saying it's not; I'm just asking.)

- "If the device has evidence that the receiver is also CLUE-capable,
for instance due to receiving an initial INVITE with no SDP but
including a "sip.clue" media feature tag,"

Is it reasonable to remember CLUE support from previous sessions? I suspect the answer is  "no", due to SIP forking issues, but I think it's worth guidance one way or the other.)

§5.1: "A device with the CLUE Participant state machine in the ACTIVE state
MAY choose not to move from ESTABLISHED to ADV (Media Provider state
machine) or from ESTABLISHED to WAIT FOR CONF RESPONSE (Media
Consumer state machine) based on the SDP state."

I'm not sure what that means. Is the specific SDP state a reason for skipping the state transition specified in due-protocol? or is it saying that an endpoint can choose not to let SDP state trigger a CLUE state change when it normally would?


*** Editorial Comments ***

- General: This document does not follow the protocol draft's convention for naming message types. For example, this draft refers to ADVERTISEMENT while the protocol draft says  'advertisement'  (in single quotes). I don't have strong feelings which to use, but the two should be consistent.

§5: Is "CLUE channel" the same as the datachannel that carries the CLUE protocol?

§5.1: "Because of the constraints of SDP offer/answer and because new SDP
negotiations are generally more ’costly’ than sending a new CLUE
message..."
Why the 'scare quotes' around "costly"?

[Ballot comment]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D4099



COMMENTS
S 12.
>      via DTLS-SRTP [RFC5763] on CLUE-controlled RTP "m=" lines.  All CLUE-
>      controlled RTP "m" lines must be secured and implemented using
>      mechanisms such as SRTP [RFC3711].  CLUE implementations MAY choose
>      not to require the use of SRTP to secure legacy (non-CLUE-controlled)
>      media for backwards compatibility with older SIP clients that are
>      incapable of supporting it.

It seems like you need more than support, you also need to require the
use of DTLS-SRTP, no?

[Ballot discuss]
Section 11.2 of the IANA considerations lists an actual OID value to use
for the "sip.clue" media feature tag, but the IANA last call review
indicates that the decimal value for sip.clue will be assigned at
registration, so it is incorrect to claim that it will be 1.3.6.1.8.4.29.
Squatting on the next available codepoint like this is quite risky and I
really want to discourage this practice.  We had a lot of trouble in TLS
recently with *three* different extensions attempting to use the same
codepoint, which was not fun to resolve.

[Ballot comment]
Please consider using the RFC 8174 version of the BCP 14 boilerplate.

Section 3

  The "sip.clue" media feature tag SIP [RFC3840] indicates support for
  CLUE in SIP [RFC3261] calls.

nit: I think there's a missing word or three here; maybe "for SIP"?

Section 4.3

  The restrictions on CLUE-controlled media always apply to "m=" lines
  in an SDP offer or answer, even if negotiation of the data channel in
  [...]

I'm not entirely sure I understand what "the restrictions" are, here.
Unless this is supposed to just be the general requirements for how they
are (not) sent?

Section 4.4.1.1

  Each  (in encodingIDList) in a CLUE ADVERTISEMENT message
  SHOULD represent an Encoding defined in SDP; the specific Encoding
  referenced is a CLUE-controlled "m=" line in the most recent SDP sent
                                                    ^^^^^^^^^^^^^^^
  by the sender of the ADVERTISEMENT message with a label value
  corresponding to the text content of the .

Is this "most recent SDP Offer/Answer"?
(Similarly in the following paragraph.)
I'm also not sure why these are SHOULD- instead of MUST-level requirements,
modulo the non-atomicity mentioned in the final paragraph of the section.

Section 4.5.1

[I will leave it to Adam to check that the "initial offer" terminology is
being used in the consensus manner, since I haven't been tracking what
manner that is.]

Section 4.5.2.2

(Also in 4.4.1.1) Am I reading this correctly that with the initial offer,
we are talking about negotiating media lines with labels that correspond to
CLUE Encoding names that have not yet been present in any CLUE messages
(that is, we're doing it "blind")?

Section 4.5.4.2

  group then the call is now CLUE-enabled; negotiation of the data
  channel and subsequently the CLUE protocol begin.

nit: begins

Section 4.5.4.4

  o  The CLUE protocol enters an unrecoverable error state as defined
      in Section 6. of [I-D.ietf-clue-protocol], either the 'MP-
      TERMINATED' state for the Media Provider or 'MC-TERMINATED' for
      the Media Consumer.

The MP-TERMINATED and MC-TERMINATED states do not seem to exist in the -17
of the protocol document.  (I'm assuming this is essentially editorial
in nature and doesn't need to be part of the DISCUSS section.)

Section 5.1

  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 [...]

presumably this is "SDP Offer/Answer" as well?

  A device with the CLUE Participant state machine in the ACTIVE state
  MAY choose not to move from ESTABLISHED to ADV (Media Provider state
  machine) or from ESTABLISHED to WAIT FOR CONF RESPONSE (Media
  Consumer state machine) based on the SDP state.  [...]

Is this "choose not to move", "choose to not move", or "chose whether or
not to move"?

Section 5.2

                    : an implementation MUST NOT send a specific CLUE
  Capture Encoding unless its most recent SDP exchange contains an
  active media channel for that Encoding AND the far end has sent a
  CLUE CONFIGURE message specifying a valid Capture for that Encoding.

nit: "far end" is perhaps a bit informal; "peer" or "MC" might be
alternatives.
I guess technically this also doesn't require that he CONFIGURE parsed
correctly and was accepted, which is arguably a bug.

Section 8

  With the successful initial SDP Offer/Answer exchange complete Alice
  and Bob are also free to negotiate the CLUE data channel.  This is
  illustrated as CLUE DATA CHANNEL ESTABLISHED.

  Once the data channel is established CLUE protocol negotiation
  begins.  In this case Bob chose to be the DTLS client (sending
  a=active in his SDP answer) and hence is the CLUE Channel Initiator
  and sends a CLUE OPTIONS message describing his version support.  On
  receiving that message Alice sends her corresponding CLUE OPTIONS
  RESPONSE.

My understanding was that the DTLS connection was a prerequisite for
setting up the CLUE data channel (so I would have been less confused if the
note about DTLS client was in the first paragraph).

There are some instances of "CLUE channel" in this section that might be
better as "CLUE data channel".

Is it normal for the mid of the CLUE data channel to be changing around in
the various SDP snippets shown in these examples?

Section 12

  This attack can be prevented by ensuring that the media recipient
  intends to receive the media packets.  As such all CLUE-capable
  devices MUST support key negotiation and receiver intent assurance
  via DTLS-SRTP [RFC5763] on CLUE-controlled RTP "m=" lines.  All CLUE-
  controlled RTP "m" lines must be secured and implemented using
  mechanisms such as SRTP [RFC3711].  CLUE implementations MAY choose
  not to require the use of SRTP to secure legacy (non-CLUE-controlled)
  media for backwards compatibility with older SIP clients that are
  incapable of supporting it.

Should these normative requirements be placed somewhere in the main body of
this (or some other) document in addition to their necessity being
described in the security considerations here?

Section 14.2

Should-ietf-rtcweb-data-channel be a normative reference?  (It seems like
it should be so at least in draft-ietf-clue-datachannel, which is not on
this week's telechat.)  I think that RFC 3840 should be normative here,
though, since you have to use it to enable CLUE.  There's probably others,
though I'd be inclined to consider at least the core SIP and SDP specs as
"basic specifications" (per
https://www.ietf.org/blog/iesg-statement-normative-and-informative-references/)
that do not need to be normative.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-clue-signaling-13. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the Semantics for the "group" SDP Attribute registry on the Session Description Protocol (SDP) Parameters registry page located at:

https://www.iana.org/assignments/sdp-parameters/

a single, new registration will be made as follows:

Semantics: CLUE-controlled m-line
Token: CLUE
Mux Category:
Reference: [ RFC-to-be ]

IANA Question --> What should the entry for Mux Category be for this new registration?

Second, in the iso.org.dod.internet.features.sip-tree (1.3.6.1.8.4) registry located on the Media Feature Tags - iso.org.dod.internet.features (1.3.6.1.8) registry page located at:

https://www.iana.org/assignments/media-feature-tags/

a single, new registration will be made as follows:

Decimal: [ TBD-at-Registration ]
Name: sip.clue
Description: This feature tag indicates that the device supports CLUE-controlled media.
Reference: [ RFC-to-be ]

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-10-17):

From: The IESG
To: IETF-Announce
CC: adam@nostrum.com, "Daniel C. Burnett" , clue@ietf.org, roni.even@mail01.huawei.com, Roni Even , clue-chairs@ietf.org, draft-ietf-clue-signaling@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Session Signaling for Controlling Multiple Streams for Telepresence (CLUE)) to Proposed Standard


The IESG has received a request from the ControLling mUltiple streams for
tElepresence WG (clue) to consider the following document: - 'Session
Signaling for Controlling Multiple Streams for Telepresence
  (CLUE)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-10-17. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document specifies how CLUE-specific signaling such as the CLUE
  protocol and the CLUE data channel are used in conjunction with each
  other and with existing signaling mechanisms such as SIP and SDP to
  produce a telepresence call.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-clue-signaling/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-clue-signaling/ballot/

The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/2960/
  https://datatracker.ietf.org/ipr/2272/
  https://datatracker.ietf.org/ipr/2271/
  https://datatracker.ietf.org/ipr/2959/



The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc7322: RFC Style Guide (Informational - IAB stream)
    rfc7202: Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution (Informational - IETF stream)
    draft-presta-clue-protocol: CLUE protocol (None - )

For tracking purposes: this document is ready for IETF Last Call as soon as the issues identified in the AD evaluation for draft-ietf-clue-protocol-14 are addressed. They will be progressed at the same time.

AD Review sent to WG, chairs, and authors:

I have completed my AD review for the CLUE signaling document. The document is generally in good shape, but I think we'll need another revision before putting it in front of the IETF for last call (especially due to the apparent incomplete removal of support for specifying multiple CLUE groups per session).

Most of my comments below are feedback that the document authors should treat as normal last call comments. The feedback that I consider to block progressing the document, in my role as AD, is explicitly marked with the prefix "BLOCKER", and these will need to be resolved in a new version of the document before progressing it further. Note that it is entirely possible that something I have marked "BLOCKER" may stem from an error on my part; so recognize that these are not demands for change, as much as a need to have things either fixed in the document or explained to me.

Title: The rule of thumb is that all but a small handful of well-known acronyms need to be expanded in titles and abstracts. I recognize that "CLUE" is a bit tortured, as acronyms go, but the title of this document is, broadly speaking, opaque. Please change it to something meaningful, such as "Session Signaling for Controlling Multiple Streams for Telepresence (CLUE)"

BLOCKER: General: It is clear from reading this version of the document that earlier versions contained the notion of multiple "a=group:CLUE" lines in a single SDP description. This version appears to have tried to remove all related text, but there are still enough mentions that talk about CLUE groups in a way that implies that there can be multiples so as to cause confusion. These need to be cleaned up. I call the specific instances out on a section-by-section basis below. I'm mentioning it up here since it's really only one blocker issue with a bunch of instances.

General: The _protocol_ document has a host of different terms for each kind of CLUE message (e.g., "ADVERTISEMENT," "ADV," and "advertisement" for the same operation). This document exacerbates the situation by introducing yet more variations, such as "Advertisement" and "Configure". Please coordinate with draft-ietf-clue-protocol to use a consistent set of names for these operations between the two documents.

Introduction: The convention I see in this document is to write defined terms with initial caps; please replace "encoding group" with "Encoding Group."

Section 3: Please add a reference to RFC3840 (e.g.: 'The "sip.clue" media feature tag [RFC3840] indicates...")

Section 4.2: "Presence of the data channel in a CLUE group..." implies there can be more than one group. Replace "a" with "the."

Section 4.3: ...its "mid" value MUST be included in a CLUE group' implies there can be more than one group. Replace "a" with "the."

Section 4.4.1: "...in a CLUE group as defined above." implies there can be more than one group. Replace "a" with "the."

Section 4.4.1: '..."m=" lines in the same CLUE group in the SDP message...' very strongly implies there can be more than one group. Rephrase, perhaps along the lines of "...CLUE-controlled "m=" lines in the SDP message..."

4.4.2: 'These "m=" lines are CLUE-controlled and hence MUST include their "mid" in the CLUE group corresponding to the CLUE group of the Encoding they wish to receive.' is getting pretty explicit about the presence of multiple CLUE groups. Fix.

4.5.2.1, first sentence: Replace "If the recipient is a CLUE-capable..." with "If the recipient of an offer is a CLUE-capable..."

BLOCKER: Section 4.5.2.2: For avoidance of doubt, this section should clearly indicate what the answer should do with CLUE-controlled lines that it has no intention of receiving (for sendonly) or sending (for recvonly). I believe the expectation here is to set the port to zero (rather than, e.g., setting the direction to inactive). The document should explicitly state this behavior: if implementations make different choices between port-zero and inactive and don't expect the other behavior, you can end up with incompatibilities.

Section 4.5.3.1, paragraph 2: My recollection is that telling implementors not to send media is frequently misinterpreted to mean that they don't have to send/receive RTCP either. This causes all kinds of grief. It will probably head off issues if this section is phrased more like "...MAY choose not to send RTP on the non-CLUE-controlled channels (although RTCP is still sent and received as normal) during the period..."

Section 4.5.4.1: 'Subsequent offer/answer exchanges MAY add additional "m=" lines...' -- this should probably also mention "and activate inactive ones."

Section 4.5.4.1: 'Subsequent offer/answer exchanges MAY also deactivate "m=" lines for CLUE-controlled media.' -- again, the interpretation of "deactivate" may be different between implementors. Please be clear about whether this means "a=inactive", port=0, or both.

Section 4.5.4.1: The final paragraph talks about "deactivating" non-CLUE media. Again, this should be explicit about what is meant.

Section 4.5.4.2: 'If, in an ongoing non-CLUE call, an SDP offer/answer exchange completes with both sides having included a data channel "m=" line in their SDP and with the "mid" for that channel in corresponding CLUE groups..." implies that there can be more than one CLUE group. Fix.

Section 4.5.4.3: "...include the data channel in a matching CLUE group..." implies there can be more than one group. Replace "a matching" with "the."

Section 4.5.4.3: "Any active "m=" lines still included in a CLUE group..." implies there can be more than one group. Replace "a" with "the."

Section 4.5.4.3: "Note that this is distinct from cases where the CLUE protocol negotiation fails, or an error occurs in the CLUE protocol; see [I-D.ietf-clue-protocol] for details of media and state preservation in this circumstance." -- I carefully scrubbed the CLUE protocol document to try to determine what this is referring to. Please change it to "see [I-D.ietf-clue-protocol] section X.Y.Z", but replacing "X.Y.Z" with the section that provides the details you allude to.


BLOCKER: Compare the normative statements in paragraph 2 of Section 5.3:

  Generally, implementations that receive messages for which they have
  incomplete information SHOULD wait until they have the corresponding
  information they lack before sending messages to make changes related
  to that information.  For example, an answerer 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
  and if a new Advertisement arrives with Captures relevant to those
  Encodings.

With the normative statements in 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 for accepted Encodings
  ...
  If the initial offer contained "a=sendonly" CLUE-controlled media
  lines the recipient MAY include corresponding "a=recvonly" CLUE-
  controlled media lines

5.3 says "SHOULD set a=inactive" in the exact same circumstances 4.5.2.2 says "SHOULD set a=sendonly". Please pick one expected behavior and make sure both sections agree. Ideally, you would refactor this so that the normative statement is made in only one location.


Section 7 appears to be oddly silent on the use of RTCP MUX. I suspect that the intention is that CLUE will generally multiplex RTCP when using BUNDLE? I would expect this to be called out.

Section 7 offers that the use of BUNDLE has the advantage of reducing the number of ICE candidates that need to be collected. This is true only in the case that some m= section are marked as bundle-only; this, in turn, implies that a bundled offer is going to contain one or more m= sections that will fail if the remote endpoint does not implement BUNDLE. This interacts particularly badly with the text in section 4.5.1 that allows, under certain circumstances, that 'the initial offer MAY contain "m=" lines for CLUE-controlled media.', since you can end up with the whole CLUE session falling apart if the bundle-only lines are not chosen carefully. This is a relatively complicated issue that I wouldn't expect impementors to get correct without some guidance on the use of bundle-only, and in particular its interaction with CLUE-controlled lines. Please add text to Section 7 that discusses these issues.

Section 8: Please insert a page break before the ladder diagram so that the entity names don't appear on a page by themselves.

Section 8: "In this case Bob is the Channel Initiator..." this isn't clear (and, in fact, it's counterintuitive to me) -- perhaps there should be some text indicating *why* Bob is the Channel Initiator.

General, but surfaced in section 8: The procedures described in this document virtually guarantee that every CLUE call that is established will result in glare (response code 491) behavior. This might cause the operations folks some heartburn, as it means that their error counts will spike once CLUE is deployed. Further, without fairly advanced analysis of the callflow, this will make it impossible to distinguish "expected" CLUE-induced 491s from the oddball actual glare conditions usually signaled by 491. Has any consideration been given to avoiding this situation (e.g., by having the called party wait on the order of one second before attempting to negotiate its encodings)?


Section 8 contains the following text:

  Bob also sends his SDP answer as part of SIP 200 OK 2.  Alongside his
  original audio, video and CLUE "m=" lines he includes two active
  recvonly "m= "lines and a zeroed "m=" line for the third.

This should probably be qualified to indicate that these are the same m-sections as were present in the offer (as opposed to creating new sections).


Section 8: Replace "Having received this Alice..." with "Having received this offer, Alice..."

Section 9: "From the lack of the data channel and grouping framework..." -- it should be noted that implementations that end up in communication with normal non-CLUE WebRTC implementations might get a datachannel but no CLUE group. The quoted text implies that the presence or absence of a datachannel can be used to determine CLUE support, which might cause implementors to rely on that exclusively. Please change the text to indicate that the CLUE group should be used as the sole determinant of CLUE support (at least, as far as SDP signaling is concerned).

Section 10: It is rather unusual to include authors in the acknowledgements section. For each of Rob Hansen, Paul Kyzivat, and Christian Groves, I suggest removing the individual's name from either the Acknowledgements section or from the authors list.

Section 11.2: "This specification registers a new media feature tag in the SIP [RFC3264] tree..." This should cite RFC3261 for SIP rather than RFC3264.

Section 11.2: Please indicate "iesg@ietf.org" as the contact for this registration.


BLOCKING: Section 12 indicates that no security mechanisms are mandatory to use "due to the issues addressed in [RFC7202]." This vastly misconstrues the intent and text of RFC7202, which (roughly speaking) says "we don't mandate security for RTP in general because it is used in a vast and varied array of applications." CLUE is a very specific, very narrow application of RTP that does not suffer from the generality that makes a one-size-fits-all solution for RTP infeasible. In fact, RFC7202 is quite clear that its guidance applies exclusively to RTP, and not to protocols that *use* RTP: "Documents that define an interoperable class of applications using RTP are subject to [RFC3365], and thus need to specify MTI security mechanisms." If there are specific arguments put forth in RFC7202 that the working group believes also apply to this document, please reiterate them here. The current citation to RFC7202 is problematic, though, since it says the opposite of what this security section implies.

If I understand it correctly, though, the argument to put forth here is that implementations MAY choose not to secure legacy (non-CLUE-controlled) media lines because SIP was specified prior to RFC3365, and was therefore not bound by its requirements; and, as a consequence, many existing SIP endpoints are incapable of using DTLS-SRTP. This rationale is orthogonal to the guidance in RFC7202, and should not cite it.

The use of "DTLS" to refer to "DTLS-SRTP" is also confusing, as they are different things.

I propose changing the paragraph as follows:

  This attack can be prevented by ensuring that the media recipient intends
  to receive the media packets.  As such, all CLUE-capable devices MUST
  support key negotiation and receiver intent assurance via DTLS-SRTP
  [RFC5763] on CLUE-controlled RTP "m=" lines.  As specified in
  [I-D.ietf-clue-framework], all CLUE-controlled RTP streams must be
  secured and implemented using mechanisms such as SRTP [RFC3711].  CLUE
  implementations MAY choose not to require the use of SRTP to secure legacy
  (non-CLUE-controlled) media for backwards compatibility with older
  SIP clients that are incapable of supporting SRTP.

Section 12: "To prevent this, SIP signaling SHOULD always be encrypted using TLS..." While I agree with the statement, I think it's a bit outside the purview of this document to specify this. Suggest: "...SIP signaling used to set up CLUE sessions SHOULD..."

What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?
This document will be a standard track RFC. The document specifies how CLUE specific signaling are used to create Tele-Presence calls.
The type is indicated on the title page

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:
Technical Summary:
This document specifies how CLUE-specific signaling such as the CLUE  protocol and the CLUE data channel are used with each other and with existing signaling mechanisms such as SIP and SDP to produce a  telepresence call.


Working Group Summary:
Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?
The document was discussed in the meetings,  and on the mailing list. The open issues were addressed and there are no open issues, there was consensus on the content of the document.

Document Quality:
Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?
There is an existing implementation of the signaling. The whole CLUE work was initiated by video conferencing  Tele-Presence equipment manufacturers wanting interoperability.

Personnel:
Who is the Document Shepherd? Who is the Responsible Area Director?
Roni Even is the Document Shepherd.
The responsible AD is Alissa Cooper.
(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.
The document shepherd reviewed the document in previous and current versions and found it ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
The document had reviews before and during the WGLC.  The comments during the WGLC were addressed.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
None.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
None
(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed.  If not, explain why?
Yes. The authors confirmed.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
There are IPR statements from Polyocm https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-clue-signaling
It was mentioned and there were no objections to publish the document with this IPR.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?
The WG understand the document and agree with it.


(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
No

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

No issues
(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.
No need

(13) Have all references within this document been identified as either normative or informative?
Yes.
(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?
There are a couple of documents. All the referenced documents are in publication or with the RFC editor. There are two mmusic documents one in WGLC and the other in publication.
(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
There are none
(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.
No
(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).
IANA section is OK

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.
No  new IANA registries.
(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.
None were needed