[MMUSIC] Spencer Dawkins' Yes on draft-ietf-mmusic-sdp-mux-attributes-14: (with COMMENT)
"Spencer Dawkins" <spencerdawkins.ietf@gmail.com> Tue, 25 October 2016 20:32 UTC
Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: mmusic@ietf.org
Delivered-To: mmusic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B825212987D; Tue, 25 Oct 2016 13:32:41 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Spencer Dawkins <spencerdawkins.ietf@gmail.com>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.36.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147742756171.8565.11705230224719531567.idtracker@ietfa.amsl.com>
Date: Tue, 25 Oct 2016 13:32:41 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/X2_TEPv9heppLvS34U2MfXSPVA8>
Cc: mmusic-chairs@ietf.org, draft-ietf-mmusic-sdp-mux-attributes@ietf.org, mmusic@ietf.org
Subject: [MMUSIC] Spencer Dawkins' Yes on draft-ietf-mmusic-sdp-mux-attributes-14: (with COMMENT)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Oct 2016 20:32:42 -0000
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.
- [MMUSIC] Spencer Dawkins' Yes on draft-ietf-mmusi… Spencer Dawkins
- Re: [MMUSIC] Spencer Dawkins' Yes on draft-ietf-m… Cullen Jennings
- Re: [MMUSIC] Spencer Dawkins' Yes on draft-ietf-m… Spencer Dawkins at IETF
- Re: [MMUSIC] Spencer Dawkins' Yes on draft-ietf-m… Suhas Nandakumar
- Re: [MMUSIC] Spencer Dawkins' Yes on draft-ietf-m… Ben Campbell