Subject: [MMUSIC] WG Last Call for draft-ietf-mmusic-data-channel-sdpneg-11

From: Bo Burman <[email-masked]>
Date: Mon, 16 Jan 2017 11:45:21 +0000

MMUSIC,

This email starts a one week WG last call on version -11 of this draft that ends on January 23, 2017.
There was a previous WG last call on version -09 that resulted in some minor document updates.

The intended status of this document is standards track (Proposed Standard).

Please review and provide any comments you may have on the document. Comments should be sent to the document authors and the MMUSIC WG list. If you review the document but do not have any comments, please send a note to that effect as well.

Please also forward this WGLC to any other interested parties who may be able to review the draft, asking them to also direct their comments to the authors and the list as above.

The document can be retrieved here:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-data-channel-sdpneg/

Thank you!

        Bo Burman (MMUSIC co-chair)

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 16 Jan 2017 14:56:02 -0500

I've followed this document closely throughout its development.
In preparation for this message I reviewed the document again. I found 
some things that need to be addressed:

1) MAJOR: Section 5.1.1.3 and various other places:

I can find nothing here or elsewhere in the document that says whether 
the the stream id in an offer is the id on which the offerer will 
receive, or the ID on which it will send. Of course this is irrelevant 
if both ends agree to use the same id, but that isn't required.

For this to interact properly with attributes for individual streams (in 
dcsa) I think it will be necessary for this to be consistent with the 
say SDP negotiates media sections - namely that the SDP in an offer 
identifies where the offerer wants to *receive* the media.

It will probably require changes in a variety of places to get this 
sorted out.

2) MINOR: Section 5.1.1 says:

    The intention in exchanging these attributes is to create, on two
    peers, without use of DCEP [I-D.ietf-rtcweb-data-protocol], matched
    pairs of oppositely directed data channels having the same set of
    attributes.  It is assumed that the data channel properties
    (reliable/partially reliable, ordered/unordered) are suitable per the
    subprotocol transport requirements.

In this, "matched pairs of oppositely directed data channels" is 
improper terminology. Each channel *is* a matched pair, of oppositely 
directed SCTP streams.

3) MINOR: Section 5.1.2 says:

    In the SDP, each data channel declaration MAY also be followed by
    other media level SDP attributes, ...

I'm concerned with "followed", because that imposes an ordering 
requirement on attributes. Generally there is no ordering requirement on 
SDP attributes other than that they up front if they are session level 
or follow a particular m= line if they are media-level.

Certainly it will be more readable to group these things in a logical 
way, but I don't think it should be required. So I suggest changing 
"followed" to "accompanied".

4) NIT: IdNits reports 1 error and 8 warnings. These need to be addressed.

	Thanks,
	Paul

On 1/16/17 6:45 AM, Bo Burman wrote:
> Please review and provide any comments you may have on the document.
> Comments should be sent to the document authors and the MMUSIC WG list.
> If you review the document but do not have any comments, please send a
> note to that effect as well.
>
>
>
> Please also forward this WGLC to any other interested parties who may be
> able to review the draft, asking them to also direct their comments to
> the authors and the list as above.
>
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Christian Groves <[email-masked]>
Date: Fri, 20 Jan 2017 18:16:49 +1100

Hello Paul,

Please see below.

Regards, Christian

On 17/01/2017 6:56 AM, Paul Kyzivat wrote:
> For this to interact properly with attributes for individual streams 
> (in dcsa) I think it will be necessary for this to be consistent with 
> the say SDP negotiates media sections - namely that the SDP in an 
> offer identifies where the offerer wants to *receive* the media.
>

[CNG] There is some guidance in clause 5.2.1 around managing stream 
identifiers. Utilising the same Stream ID is required when supporting 
WebRTC datachannel (see clause 6.4/draft-ietf-rtcweb-data-channel-13). 
Clause 5.1.1 / ietf-mmusic-data-channel-sdpneg vaguely mentions that the 
opposite datachannels have the same set of attributes. SCTP stream 
identifier being one of those.

> improper terminology. Each channel *is* a matched pair, of oppositely 
[CNG] Yes I agree.
> ..snip..

---

From: Christian Groves <[email-masked]>
Date: Fri, 20 Jan 2017 18:48:17 +1100

Hello,

I've reviewed it and I think its ready to progress.

A minor NIT on the example in Appendix A. It should contain an 
"a=dtls-id:....." attribute as per other examples in the draft.

Regards, Christian

On 16/01/2017 10:45 PM, Bo Burman wrote:
> Comments should be sent to the document authors and the MMUSIC WG 
> list. If you review the document but do not have any comments, please 
> send a note to that effect as well.
>
> Please also forward this WGLC to any other interested parties who may 
> be able to review the draft, asking them to also direct their comments 
> to the authors and the list as above.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 20 Jan 2017 18:35:42 -0500

> identifier being one of those.

I was taking that into account, and yet found it incomplete.

However, upon rereading, I did find some language in section 5.2.3 that 
helps clarify this:

    The peer receiving such an SDP offer performs the following:
    ...
    o  For accepted data channels, it creates peer instances for the data
       channels with the agent using the channel parameters described in
       the SDP offer.  Note that the agent is asked to create data
       channels with SCTP stream identifiers contained in the SDP offer
       if the SDP offer is accepted.

The "Note" is what resolves any ambiguity. But it is written as if it 
was an implication that is simply being noted, rather than being a 
normative statement.

So I propose that it be revised as follows:

    o  For accepted data channels, the agent MUST create peer instances
       for the data channels using the SCTP stream identifiers and
       channel parameters contained in the SDP offer.

	Thanks,
	Paul