Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sdp-mux-attributes-12

From: "Ben Campbell" <[email-masked]>
Date: Fri, 17 Jun 2016 17:19:26 -0500

Hi Suhas,

Where did we end up with this? It looks like the zrtp-hash thread has 
resolved. Do you plan an update?

Thanks!

Ben.

On 20 May 2016, at 18:07, Ben Campbell wrote:

>>>
>
>>
>> [Suhas] . I doubt it. Do you recommend as NOT-RECOMMENDED instead.
>
>
> That seems reasonable, unless  you know of good reasons otherwise.
>
>
>
>>>
>>> -15.1:
>>>   - Is there no need for a spec for any newly registered categories?
>>>   - 2nd to last paragraph: "This seems vague for a MUST. Do you 
>>> expect
>>>     the registration of a new category to change the categories
>>>     already assigned to existing SDP parameters? Is it possible
>>>     that a new category only applies to some new SDP parameters?"
>>>
>
>>
>> [Suhas] The following 2 paragraphs are supposed to mean that new
>> multiplexing categories require new registrations via a spec and
>> applicability of the new category to new SDP attributes and possibly
>> existing SDP attributes ( if the new category makes more sense). What 
>> would
>> be a better framing to capture the intent ?
>>
>> "*Further entries can be registered on a first-come first-serve 
>> basis. Each
>> registration needs to indicate the multiplexing category value to be 
>> added
>> to the "Multiplexing Categories" subregistry as defined in this 
>> section.*
>>
>> *Such a registration MUST also indicate the applicability of the 
>> newly
>> defined multiplexing category value to various subregistries defined 
>> at
>> "Session Description Protocol (SDP) Parameters".*
>
>
> That works for me.
>
>
>>
>>
>
>>>   - Last paragraph: 4566 procedures apply to what? The text just 
>>> said
>>>     new categories are first-come-first server. I don’t think
>>>     4566 set policies for how to change mux categories.
>>>
>
>>
>> [Suhas] Agreed. I prefer removing this line altogether. Please let me 
>> know
>>
>
>
> I agree.
>
>
>
>>>
>>> -15.2.1:
>>>   How do you expect the table to look after adding this RFC to the
>>>   references? Will this RFC be added to the entries in the MUX
>>>   column?
>>>
>
>>
>> [Suhas] The plan was to add the reference to this RFC in the 
>> "Reference
>> Column"
>
>
> Okay.
>
> [...]
>
>
>
>>
>
>>>
>>>
>>> # Editorial #
>>>
>
>>
>
>>> - The abstract is more detailed than needed. The point is to 
>>> describe the
>>> purpose of the draft. The second paragraph pretty much accomplishes 
>>> that.
>>>
>>>
>
>> [Suhas] How do this rephrase look
>>
>> “The purpose of this specification is to provide a framework for 
>> analyzing
>> the multiplexing characteristics of SDP attributes when SDP is used 
>> to
>> negotiate the usage of single 5-tuple for sending and receiving media
>> associated with multiple media descriptions,. This specification also
>> categorizes the existing SDP attributes based on the framework 
>> described
>> herein.”
>>
>
>
> That works for me.
>
> [...]
>
>
>>
>>
>
>>>
>>> -5 and subsections: Is there any method to the ordering? They aren't
>>>    in RFC order. It might make sense to group by the nature of the
>>>    attributes, but if that is the case here it's not explained.
>>>
>>>
>
>> [Suhas] These are not ordered as of today. I can order the 5.X 
>> subsections
>> by RFC order, if needed.
>
>
> Unordered is also okay. I was just wondering if there was a logic that 
> should be mentioned.
>
>
> [...]