Re: [MMUSIC] Spencer Dawkins' Yes on draft-ietf-mmusic-sdp-mux-attributes-14: (with COMMENT)
Cullen Jennings <fluffy@iii.ca> Wed, 26 October 2016 01:32 UTC
Return-Path: <fluffy@iii.ca>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4F601299DA for <mmusic@ietfa.amsl.com>; Tue, 25 Oct 2016 18:32:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYBdiHE-_Dqy for <mmusic@ietfa.amsl.com>; Tue, 25 Oct 2016 18:32:25 -0700 (PDT)
Received: from smtp74.iad3a.emailsrvr.com (smtp74.iad3a.emailsrvr.com [173.203.187.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DB561294DA for <mmusic@ietf.org>; Tue, 25 Oct 2016 18:32:25 -0700 (PDT)
Received: from smtp26.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp26.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 637BAC01A2; Tue, 25 Oct 2016 21:32:19 -0400 (EDT)
X-Auth-ID: fluffy@iii.ca
Received: by smtp26.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id C9D75C017A; Tue, 25 Oct 2016 21:32:18 -0400 (EDT)
X-Sender-Id: fluffy@iii.ca
Received: from [10.24.10.185] ([UNAVAILABLE]. [128.107.241.180]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.7.7); Tue, 25 Oct 2016 21:32:19 -0400
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Cullen Jennings <fluffy@iii.ca>
In-Reply-To: <147742756171.8565.11705230224719531567.idtracker@ietfa.amsl.com>
Date: Tue, 25 Oct 2016 18:32:18 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <5A934910-073D-46A9-866C-EFA63956F3F3@iii.ca>
References: <147742756171.8565.11705230224719531567.idtracker@ietfa.amsl.com>
To: Spencer Dawkins <spencerdawkins.ietf@gmail.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/KpPTeUAFtsrJUPGZWf-N6Di3Smg>
Cc: mmusic-chairs@ietf.org, draft-ietf-mmusic-sdp-mux-attributes@ietf.org, The IESG <iesg@ietf.org>, mmusic@ietf.org
Subject: Re: [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
Precedence: list
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: Wed, 26 Oct 2016 01:32:27 -0000
> 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/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. '' 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. > > 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... > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic
- [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