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

From: [email-masked]
Date: Thu, 21 Jan 2016 08:29:18 -0800

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

        Title           : CLUE Signaling
        Authors         : Paul Kyzivat
                          Lennard Xiao
                          Christian Groves
                          Robert Hansen
	Filename        : draft-ietf-clue-signaling-07.txt
	Pages           : 36
	Date            : 2016-01-21

Abstract:
   This document specifies how CLUE-specific signaling such as the CLUE
   protocol [I-D.ietf-clue-protocol] and the CLUE data channel
   [I-D.ietf-clue-datachannel] are used 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-07

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

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: Robert Hansen <[email-masked]>
Date: Thu, 21 Jan 2016 16:53:31 +0000

Hi all, apologies that this took longer than intended to revise and check.

Thanks to all the reviewers - almost all suggestions were incorporated, 
usually as-is when suggested text was provided.

* Removed the entire 'Media line directionality' section as a discussion 
of the pros/cons of using bidirectional vs unidirectional schemes wasn't 
suitable for a finalised version. The unidirectionality requirement is 
covered normatively in an earlier section.

* BUNDLE no longer includes an address synchronisation step so the 
suggestion to wait until that done has been replaced with some general 
language about following any negotiated extensions.

* Added OPTIONS negotiation to the example flow, and revised the flow to 
ensure it matched protocol document.

* Section on not sending CLUE control media until CLUE  negotiation 
completes narrowed to notify that only RTP should not be sent until 
negotiation completes and add RTCP to the list of things that should be 
sent as normal, in line with a=inactive.

*  Make explicit that m=recvonly lines don't need to have a label, as 
only m=sendonly lines are referenced by CLUE protocol messages.

* Fix formatting of IANA sections.  Improve syntax of feature tag 
section in line with Paul's suggestions.  Definition of feature tag 
narrowed to be multiple media lines 'negotiated via CLUE protocol' 
rather than more generic 'multiple media lines'.

One thing that Paul brought up was that in 5.1 "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" 
- I've checked and to me they seem to be consistent with the state 
machines in the protocol document.

Rob

On 21/01/16 16:29, [email-masked] wrote:
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Christian Groves <[email-masked]>
Date: Fri, 22 Jan 2016 16:07:33 +1100

Hello Rob,

Thanks for the update. A couple of comments:

cl. 4.5.2.2 adds "lines for compatible encodings" - is compatible the 
right term here? Isn't it more "accepted encodings"?

cl. 4.5.4.3: I've made a comment a couple of times now about the need to 
mention SCTP reset for disabling CLUE mid call but it appears to be 
missed. Both draft-ietf-clue-datachannel (cl.3.2.7) and 
draft-ietf-mmusic-data-channel-sdpneg (cl.5.2.4) both mention that an 
SCTP SSN reset has to be performed. 
draft-ietf-mmusic-data-channel-sdpneg (cl.5.2.4) mentions that its 
protocol specific whether this is announced by SDP.

So I would propose to word the first paragraph of cl.4.5.4.3 differently:

"If order to close a CLUE data channel in an ongoing CLUE-enabled call, 
an endpoint shall follow the procedures for closing a data channel 
defined in clause 5.2.4 [draft-ietf-mmusic-data-channel-sdpneg] by 
sending a new SDP offer/answer exchange and subsequent SCTP SSN reset 
for the CLUE channel.

In the event that this occurs, CLUE is no longer enabled and sending of 
all   CLUE-controlled media associated with the corresponding CLUE group 
MUST stop.  If the data channel is still present but not included in the 
CLUE group semantic CLUE protocol messages MUST no longer be sent."

Regards, Christian

On 22/01/2016 3:53 AM, Robert Hansen wrote:
> Thanks to all the reviewers - almost all suggestions were 
> incorporated, usually as-is when suggested text was provided.
>
> * Removed the entire 'Media line directionality' section as a 
> discussion of the pros/cons of using bidirectional vs unidirectional 
> schemes wasn't suitable for a finalised version. The unidirectionality 
> requirement is covered normatively in an earlier section.
>
> * Added OPTIONS negotiation to the example flow, and revised the flow 
> to ensure it matched protocol document.
>
> negotiation completes and add RTCP to the list of things that should 
> be sent as normal, in line with a=inactive.
>
> don't seem to be consistent with the current state machine 
> definitions" - I've checked and to me they seem to be consistent with 
> the state machines in the protocol document.
>
> Rob
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 25 Jan 2016 15:42:44 -0500

> usually as-is when suggested text was provided.

This generally looks good. I found a few nits while reading:

* Section 4.5.3.1:

s/"m=" line to send or receive/"m=" lines to send or receive/

* Section 4.5.4.3:

s/distinct to/distinct from/

(This isn't new, I missed it previously.) As written I think it means 
the opposite of what it intends.

* Section 8:

Did you attempt to address my comments in:

http://mailarchive.ietf.org/arch/msg/clue/gYAy7v42JN8uxFz53qxBVki7OBY

I see a few of the editorial ones addressed, but not the substantial 
ones. For the most part the meaty ones still apply.

	Thanks,
	Paul