Controlling Multiple Streams for Telepresence (CLUE) Protocol Data Channel
Note: This ballot was opened for revision 15 and is now closed.
(Alissa Cooper) Yes
(Adam Roach) Yes
Comment (2019-03-07 for -15)
This document completed IETF last call in 2016, and was held by my predecessor AD "to await progress on the RTCWEB security document, which is referenced." Now that the RTCWEB security documents have completed their IESG evaulation, this document is ready for evaluation. Please note that the document internally says it is standards-track, while the datatracker has it marked as experimental. The datatracker is correct. See https://mailarchive.ietf.org/arch/msg/clue/1o3-x4T_J9lZGp50Z4rOIpmsE60 and https://mailarchive.ietf.org/arch/msg/clue/lqCLQNlb0XWWJ9GAseVGJU4yP6E for context.
(Ignas Bagdonas) No Objection
(Deborah Brungard) No Objection
Roman Danyliw No Objection
Comment (2019-04-10 for -15)
A few nits: (1) Section 1. Typo (missing space). s/[I-D.ietf-clue-protocol]messages/ [I-D.ietf-clue-protocol] messages/ (2) Section 1. Editorial Nit. s/data channel Establishment Protocol/ Data Channel Establishment Protocol/ (3) Section 3.2.1, Typo s/(e.g. regarding ordered delivery )/ (e.g., regarding ordered delivery)/ (4) Section 3.2.1. Typo. s/signalled/signaled/ (5) Section 3.2.3, Per “[I-D.ietf-rtcweb-data-channel] also mandates support of the limited retransmission policy defined in [RFC7496].”, I was expecting to read something about how this extension is also not needed by CLUE like the previous part of the paragraph. Right now the text only states something about rtcweb but not CLUE.
Benjamin Kaduk No Objection
Comment (2019-04-10 for -15)
Section 1 This includes SCTP considerations specific to a CLUE data channel, the SDP Media Description (m- line) values, and usage of SDP attributes specific to a CLUE data channel. nit: "m= line" Section 2 Please use the RFC 8174 boilerplate. Section 3.1 the WebRTC data channel mechanism. This includes a set of SCTP characteristics specific to a CLUE data channel, the values of the m- line describing the SCTPoDTLS association associated with the WebRTC nit: "m= line"? Section 3.2.7 As described in [I-D.ietf-rtcweb-data-protocol], in order to close a data channel, an entity sends an SCTP reset message [RFC6525] on its This reference would normally make draft-ietf-rtcweb-data-protocol a normative reference, but I think that perhaps the intended reference is actually draft-ietf-rtcweb-data-channel (which is already a normative reference). In particular, Section 6.7 of the latter document is about "Closing a Data Channel" and mentions resetting the streams. Section 3.3.2 The values of the SDP dcmap attribute [I-D.ietf-mmusic-data-channel-sdpneg], associated with the m- line nit: "m= line"? Section 5.1 I note that the WebSocket Subprotocol Name Registry has the "first come, first served" registration policy, which makes a declarative statement like this ("this document adds") a bit risky -- what if someone else swoops in to register this name?
(Suresh Krishnan) No Objection
(Mirja Kühlewind) No Objection
Comment (2019-04-08 for -15)
Please have a look at the comments from the TSV-ART review (and thanks to Jörg for the review)!
(Barry Leiba) No Objection
(Alexey Melnikov) No Objection
Éric Vyncke No Objection
Comment (2019-04-04 for -15)
While the I-D was waiting for missing references, RFC 2119 has been obsoleted by RFC 8174 => please update section 2. It is unclear for me in section 3.2.7 whether the 'stream reset' actually refers to RFC 6525 "SSN reset". Looking forward to being enlighten on this point. *Nits* Section 3.2.2, I wonder whether the note is really required as it restates parts of another documents (even if it gives some more context as in other subsections of section 3.2). Section 3.2.7 s/Close CLUE data channel/Closing the CLUE data channel/