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

From: Bo Burman <[email-masked]>
Date: Fri, 10 Feb 2017 11:52:04 +0000

Hi,

I'm wondering if 4566bis has to be a normative reference in this document? While the registrations of the new attributes use the 4566bis template that includes the mux category, I don't think it necessarily motivates having 4566bis as normative reference, but informative should be sufficient. The document also normatively references -mux-attributes for the chosen mux category "SPECIAL", which seems OK to me.

/Bo (as individual)

> -----Original Message-----
> From: mmusic [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: den 21 januari 2017 00:36
> To: [email-masked]
> Subject: Re: [MMUSIC] WG Last Call for draft-ietf-mmusic-data-channel-sdpneg-11
> 
> On 1/20/17 2:16 AM, Christian Groves wrote:
> > Hello Paul,
> >
> > Please see below.
> >
> > Regards, Christian
> >
> > On 17/01/2017 6:56 AM, Paul Kyzivat wrote:
> >> 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.
> >
> > [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.
> 
> 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
> 
> >> 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.
> > [CNG] Yes I agree.
> >> ..snip..
> >
> > _______________________________________________
> > mmusic mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mmusic
> >
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 10 Feb 2017 16:14:12 -0500

> I'm wondering if 4566bis has to be a normative reference in this document? While the registrations of the new attributes use the 4566bis template that includes the mux category, I don't think it ne…

I don't think so.

	Thanks,
	Paul