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

From: [email-masked]
Date: Mon, 13 Mar 2017 08:08:17 -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 of the IETF.

        Title           : CLUE Signaling
        Authors         : Paul Kyzivat
                          Lennard Xiao
                          Christian Groves
                          Robert Hansen
	Filename        : draft-ietf-clue-signaling-11.txt
	Pages           : 38
	Date            : 2017-03-13

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's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-clue-signaling-11

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

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, 13 Mar 2017 15:11:46 +0000

Minor tweaks based on Roni's suggestions and idnits:

*  Some informative references added for SIP and SDP.
*  'a=mid' lines added to example m-lines with port 0, per RFC5888 section 6.
*  Instace of 'must' changed to normative 'MUST', along with various minor clarifications and corrections.
*  Abstract made standalone without citations, per RFC7322 section 4.3.
*  RFC editor note added to remove this section. 

Enjoy Chicago, all,

Rob

-----Original Message-----
From: clue [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 13 March 2017 15:08
To: [email-masked]
Cc: [email-masked]
Subject: [clue] I-D Action: draft-ietf-clue-signaling-11.txt

        Title           : CLUE Signaling
        Authors         : Paul Kyzivat
                          Lennard Xiao
                          Christian Groves
                          Robert Hansen

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 13 Mar 2017 17:22:18 -0400

> *  RFC editor note added to remove this section.

IMO the new MUST in 4.2 isn't right. This isn't a normative statement. 
Instead it is simply a statement of logical necessity: since the channel 
conveys the protocol messages, it is a prerequisite for exchanging 
protocol messages.

But this isn't a big deal. I don't mind if it gets published this way.

In the same section, regarding the introduction of "offer" into the 
following:

    The data channel is negotiated over SDP as described in
    [I-D.ietf-mmusic-data-channel-sdpneg].  A CLUE-capable device wishing
    to negotiate CLUE MUST also include a CLUE group in the SDP offer and
    include the "mid" of the "m=" line for the data channel in that
    group.  A CLUE group MUST include the "mid" of the "m=" line for one
    (and only one) data channel.

ISTM that both offerer and answerer are involved in this negotiation, 
and this statement applies to both. So I think it was more correct 
before "offer" was added. This could be changed to "... offer or answer 
...".

But again I'm not sure if this is worth changing. What do others think?

	Thanks,
	Paul