Re: [MMUSIC] Spencer Dawkins' Yes on draft-ietf-mmusic-sdp-mux-attributes-14: (with COMMENT)

On 25 Oct 2016, at 21:11, Suhas Nandakumar wrote:

> Thanks Spencer for the review and Thanks Cullen for the inputs.
>
> Given the discussion above, I can update the security considerations
> section as suggested by Spencer and generate a new version whenever it 
> is
> appropriate and just to double check on the outcome - the category TBD 
> stay
> as it is.
>
> Spencer, please advise if i misunderstood anything
>
> Ben, please let me know procedures on generating the next version.

Given that the telechat is tomorrow, and some other comments have 
already come in: I suggest addressing the comments via email, then 
submitting an update as soon after the telechat as is convenient.

Thanks!

Ben.

>
> Cheers
> Suhas
>
> On Tue, Oct 25, 2016 at 8:15 PM, Spencer Dawkins at IETF <
> spencerdawkins.ietf@gmail.com> wrote:
>
>> Hi, Cullen,
>>
>> On Tue, Oct 25, 2016 at 8:32 PM, Cullen Jennings <fluffy@iii.ca> 
>> wrote:
>>
>>>
>>>> On Oct 25, 2016, at 1:32 PM, Spencer Dawkins <
>>> spencerdawkins.ietf@gmail.com> wrote:
>>>>
>>>> Spencer Dawkins has entered the following ballot position for
>>>> draft-ietf-mmusic-sdp-mux-attributes-14: Yes
>>>>
>>>> When responding, please keep the subject line intact and reply to 
>>>> all
>>>> email addresses included in the To and CC lines. (Feel free to cut 
>>>> this
>>>> introductory paragraph, however.)
>>>>
>>>>
>>>> Please refer to https://www.ietf.org/iesg/stat
>>> ement/discuss-criteria.html
>>>> for more information about IESG DISCUSS and COMMENT positions.
>>>>
>>>>
>>>> The document, along with other ballot positions, can be found here:
>>>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-mux-attributes/
>>>>
>>>>
>>>>
>>>> ----------------------------------------------------------------------
>>>> COMMENT:
>>>> ----------------------------------------------------------------------
>>>>
>>>> This document is a work of art. Thank you folks for accepting the
>>>> challenge, because it's important.
>>>>
>>>> I have a couple of observations, to go along with my Yes ballot. 
>>>> Please
>>>> do the right thing.
>>>>
>>>> I know Mirja also pushed on the TBD category, but I find RFC 2119
>>> "SHOULD
>>>> NOT" to be problematic.
>>>>
>>>>   The attributes in the TBD category have not been analyzed under 
>>>> the
>>>>   proposed multiplexing framework and SHOULD NOT be multiplexed.
>>>>
>>>> The point of SHOULD (NOT) is that you don't do this unless you
>>> understand
>>>> the risks, and in this case, it seems to me that you don't know the
>>>> risks. If you're determined to multiplex the TBD attribute 
>>>> "frommet=",
>>>> won't you have to do your own analysis? Wouldn't that mean you 
>>>> might
>>> make
>>>> assumptions ("it's IDENTICAL") that conflict with the analysis 
>>>> other
>>>> implementers are doing ("it's TRANSPORT")?
>>>>
>>>> I could imagine a couple of approaches that might be helpful here.
>>>>
>>>> Saying "MUST NOT be multiplexed" would avoid implementers doing 
>>>> their
>>> own
>>>> analysis and coming up with conflicting answers. Is it obvious why 
>>>> this
>>>> is "SHOULD NOT" instead of "MUST NOT"? In other words, who needs to
>>>> multiplex TBD attributes, and why?
>>>>
>>>> Saying "cannot be assumed to be safe when multiplexed" probably 
>>>> captures
>>>> what I think you are saying. ''
>>>
>>> Yes, I think your summary is about right here. For better or worse 
>>> the
>>> logic of SHOULD was that a later spec that correctly classified them 
>>> could
>>> put them in the right category. I don't know what would be the best 
>>> (if
>>> any) change to make to the spec but I wanted to agree with your
>>> understanding.
>>
>>
>> "Do the right thing" :-)
>>
>>
>>>>
>>>> Would it be clearer if the category was called UNKNOWN?
>>>
>>> We were trying to capture that it was not that future specs would 
>>> not be
>>> able to figure out what to do with these, but more that this RFC had 
>>> not
>>> classified them.
>>
>>
>> I'm pretty sure I'm stumbling over something that is less clear now 
>> than
>> it will be when the working group is using this framework (so, this 
>> makes
>> sense to me).
>>
>>
>>>>
>>>> In this text,
>>>>
>>>> 16.  Security Considerations
>>>>
>>>>   This document does not add any new security considerations beyond 
>>>> the
>>>>   existing considerations in the RTP RFCs ([RFC3550] and [RFC3711])
>>>>   that are referenced by this specification.
>>>>
>>>> I don't understand how the first paragraph ^^ and the third 
>>>> paragraph of
>>>> the section are compatible, because you're referring to issues 
>>>> described
>>>> in this specification. But if you delete the first paragraph, 
>>>> leaving
>>>> only
>>>>
>>>>   The primary security for RTP including the way it is used here is
>>>>   described in [RFC3550] and [RFC3711].
>>>>
>>>>   When multiplexing SDP attributes with the category "CAUTION", the
>>>>   implementations should be aware of possible issues as described 
>>>> in
>>>>   this specification.
>>>>
>>>> the security considerations would be consistent.
>>>
>>> Works For Me ... i think the text that is there goes back to early 
>>> boiler
>>> plate text we took from somewhere...
>>>
>>
>> Cool - and thanks for considering my comments.
>>
>> Spencer
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>>

> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic