Re: WG Last Call for draft-ietf-mmusic-data-channel-sdpneg-11

On 2/10/17 6:52 AM, Bo Burman wrote:
> 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.

I don't think so.

	Thanks,
	Paul

> /Bo (as individual)
>
>> -----Original Message-----
>> From: mmusic [mailto:[email protected]] On Behalf Of Paul Kyzivat
>> Sent: den 21 januari 2017 00:36
>> To: [email protected]
>> 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 protected]
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>
>> _______________________________________________
>> mmusic mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/mmusic
>
> _______________________________________________
> mmusic mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/mmusic
>