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

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.

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
>
>