Skip to main content

A Framework for Session Description Protocol (SDP) Attributes When Multiplexing
draft-ietf-mmusic-sdp-mux-attributes-19

Yes


No Objection

(Alexey Melnikov)
(Alia Atlas)
(Alvaro Retana)
(Benoît Claise)
(Deborah Brungard)
(Jari Arkko)
(Joel Jaeggli)
(Suresh Krishnan)

Note: This ballot was opened for revision 14 and is now closed.

Alissa Cooper Former IESG member
Yes
Yes (2016-10-25 for -14) Unknown
Thank you for all the work on this.
Ben Campbell Former IESG member
Yes
Yes (2016-10-25 for -14) Unknown
Update: The reference to the obsolete RFC 4901 is to cover a deprecated attribute that is defined in that doc.

Is the reference to 4901 (obsoleted by 5245) intentional?
Spencer Dawkins Former IESG member
Yes
Yes (2016-10-25 for -14) Unknown
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.
Alexey Melnikov Former IESG member
No Objection
No Objection (for -14) Unknown

                            
Alia Atlas Former IESG member
No Objection
No Objection (for -14) Unknown

                            
Alvaro Retana Former IESG member
No Objection
No Objection (for -14) Unknown

                            
Benoît Claise Former IESG member
No Objection
No Objection (for -14) Unknown

                            
Deborah Brungard Former IESG member
No Objection
No Objection (for -14) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -14) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (for -14) Unknown

                            
Kathleen Moriarty Former IESG member
No Objection
No Objection (2016-10-23 for -14) Unknown
Thank you for addressing the SecDir review:
https://www.ietf.org/mail-archive/web/secdir/current/msg06749.html
Mirja Kühlewind Former IESG member
No Objection
No Objection (2016-10-25 for -14) Unknown
Two comments:

1) The category TDB is not fully clear to me. It says: "The attributes in the TBD category have not been analyzed", but why? Can you further explain?

2) Is the new registry for the Mux Category really needed? Is it expected to (much) more categories in future?
Stephen Farrell Former IESG member
No Objection
No Objection (2016-10-26 for -14) Unknown
- 4.5 and 5.7: What if the different a=crypto lines
specify different strength ciphersuites? Wouldn't it be
better to pick the strongest or to say they MUST be the
same (as is done in 5.35)? If picking the first is the
right answer then maybe warn folks to not put a stronger
ciphersuite anywhere else?

- 5.36 vs. 5.39: It wasn't clear to me why these have
different rules - can you explain?
Suresh Krishnan Former IESG member
No Objection
No Objection (for -14) Unknown