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

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 25 Oct 2016 13:32:41 -0700

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/statement/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. 

Would it be clearer if the category was called UNKNOWN?

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.

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 25 Oct 2016 18:32:18 -0700

> On Oct 25, 2016, at 1:32 PM, Spencer Dawkins <[email-masked]> wrote:
> 
> 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. 

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

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

> 
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 25 Oct 2016 22:15:05 -0500

Hi, Cullen,

On Tue, Oct 25, 2016 at 8:32 PM, Cullen Jennings <[email-masked]> wrote:

> 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" :-)

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

> plate text we took from somewhere...

Cool - and thanks for considering my comments.

Spencer

---

From: Suhas Nandakumar <[email-masked]>
Date: Tue, 25 Oct 2016 21:11:13 -0700

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 <
[email-masked]> wrote:

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

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 26 Oct 2016 09:14:58 -0700

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

>>>> won't you have to do your own analysis? Wouldn't that mean you 
>>>> might
>>> make
>>>> Saying "MUST NOT be multiplexed" would avoid implementers doing 
>>>> their
>>> own
>>> Works For Me ... i think the text that is there goes back to early 
>>> boiler
>>> plate text we took from somewhere...
>>>
>>