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

From: [email-masked]
Date: Sun, 20 Aug 2017 19:26:02 -0700

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 WG of the IETF.

        Title           : Session Signaling for Controlling Multiple Streams for Telepresence (CLUE)
        Authors         : Paul Kyzivat
                          Lennard Xiao
                          Christian Groves
                          Robert Hansen
	Filename        : draft-ietf-clue-signaling-12.txt
	Pages           : 41
	Date            : 2017-08-20

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 IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-clue-signaling/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-clue-signaling-12
https://datatracker.ietf.org/doc/html/draft-ietf-clue-signaling-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-signaling-12

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/

---

From: "Rob Hansen (rohanse2)" <[email-masked]>
Date: Mon, 21 Aug 2017 02:33:31 +0000

Hi all,

Had planned to have this done several weeks ago but apparently I angered some standards deity somehow as minor emergencies kept cropping up that delayed me (for instance this evening, literally two minutes after I opened the xml file to finish it off, a five-meter length of guttering fell off my house with an almighty crash). Curse or not, my apologies on the delay.

The summary of changes is as follows:

* Title change to expand and elucidate our totally-not-contrived acronym
* Explicit reference to RFC3840 added when first mentioning media feature tags
* Have standardised references to Clue protocol messages to ADVERTISEMENT, CONFIGURE and ACK, in line with section 12.4.1. of the protocol document (though the protocol document also uses ADV and CONF).
* 'MUST' in opening paragraph of 4.2 changed from normative 'MUST' to logical 'must'
*Per his request, removed Cristian's company affiliation and changed his email address
*Other syntactic tweaks based on Paul and Adam's feedback
*Clarified that an implementation that chooses not to send media during the initial negotiation process must still send RTCP as normal
*Rewrote the section on adding/remove clue m-lines after the initial exchange to make clear that this is just standard SDP. For non-clue controlled lines, recommended they are *deactivated by zeroing the port when turning them off after clue is successfully negotiated.
*Added guidance that an initial offer containing clue-controlled m-lines MUST NOT set them bundle-only unless they somehow know the far end actually supports BUNDLE
*Added section saying that CLUE devices that do BUNDLE SHOULD do rtcp-mux, but that the requirement doesn't exist in the other direction (eg, supporting rtcp-mux does not require *or imply the need to implement BUNDLE)
*For clue-controlled m-lines where the sender included more encodings than the recipient wants, have standardised on using "a=inactive" to not receive RTP on them (previously had *a mix of "a=inactive" or port 0, or in some cases did not specify).
*Page breaks added before the big ladder diagram in the example
*Have added a direction attribute to the SDP example in the data channel, and made explicit that Bob is the DTLS client and hence the CLUE Channel Initiator.
*Have removed all language that referenced the possibility of having multiple CLUE groups
*Removed names appearing in the authors list from the acknowledgements
*Changed the contact for the IANA registration to [email-masked]
*Security section updated to clarify that DTLS-SRTP must be supported (as opposed to DTLS) and removed the reference to RFC7202.

There's also a couple of issues identified in Adam's review that need further discussion; I'll send a separate email for those.

Rob

-----Original Message-----
From: clue [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 21 August 2017 03:26
To: [email-masked]
Cc: [email-masked]
Subject: [clue] I-D Action: draft-ietf-clue-signaling-12.txt

Abstract:

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.

_______________________________________________
clue mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/clue