[bfcpbis] Ben Campbell's Yes on draft-ietf-bfcpbis-rfc4583bis-27: (with COMMENT)
Ben Campbell <ben@nostrum.com> Fri, 21 December 2018 20:53 UTC
Return-Path: <ben@nostrum.com>
X-Original-To: bfcpbis@ietf.org
Delivered-To: bfcpbis@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F382C130E1D; Fri, 21 Dec 2018 12:53:51 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Ben Campbell <ben@nostrum.com>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-bfcpbis-rfc4583bis@ietf.org, bfcpbis-chairs@ietf.org, mary.ietf.barnes@gmail.com, bfcpbis@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.89.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154542563195.20386.6505566242563710608.idtracker@ietfa.amsl.com>
Date: Fri, 21 Dec 2018 12:53:51 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/bfcpbis/urBnqgNnoZ-TbeTyxIq6gN1CpsU>
Subject: [bfcpbis] Ben Campbell's Yes on draft-ietf-bfcpbis-rfc4583bis-27: (with COMMENT)
X-BeenThere: bfcpbis@ietf.org
X-Mailman-Version: 2.1.29
List-Id: BFCPBIS working group discussion list <bfcpbis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bfcpbis/>
List-Post: <mailto:bfcpbis@ietf.org>
List-Help: <mailto:bfcpbis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Dec 2018 20:53:52 -0000
Ben Campbell has entered the following ballot position for draft-ietf-bfcpbis-rfc4583bis-27: 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-bfcpbis-rfc4583bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Update: The RFC Editor is updating the mux-attribute draft to match the mux-categories described in this draft. Therefore I have cleared my DISCUSS position. Thanks to all involved! I have left my previous non-blocking comments below for reference purposes. --------------------------- The following point was part of my DISCUSS position. Since the problem seems broader than for just this draft, I won't hold the draft hostage to it's solution. But I hope we can find a cleaner approach in general: <old-discuss-point> This document lists all the SDP attributes as having an a Mux Category of "TBD". draft-ietf-mmusic-sdp-mux-attributes did indeed assign a category of "TBD" to all the attributes, save for bfcpver, which didn't exist at the time. But the point of "TBD" was to say that draft-ietf-mmusic-sdp-mux-attributes did not actually analyze the attributes to determine a "real" mux category. It's not intended as free pass to let other attribute definitions skip that analysis. Ideally, I think that this draft should assign a "real" mux category for each attribute in it. Failing that, it at least needs to do so for "bfcpver". I'm guessing that should be "caution" or "special". (Perhaps unfortunately, draft-ietf-mmusic-sdp-mux-attributes did not define a category of "nope" :-) ) Update: After a bit of discussion and a re-read of draft-ietf-mmusic-sdp-mux-attributes, I see that, while the use of "TBD" does not seem consistent with the definition of TBD, it does seem consistent with the practice in mux-attributes of assigning a category of TBD to attributes associated with non-muxable protocols. I've sent an email to the MMUSIC WG for guidance on the intended use. </old-discuss-point> *** Substantive Comments *** §4: "The fmt (format) list is not applicable to BFCP. The fmt list of ’m’ lines in the case of any proto field value related to BFCP MUST contain a single "*" character. If the the fmt list contains any other value it is ignored." It seems like the last sentence should use a MUST to match the one in the previous sentence. *** Editorial Comments *** §3: "Typically, a client that establishes a BFCP stream with a conference server will act as a floor control client, while the conference server will act as a floor control server." The use of "typically" seems odd without a discussion of when it might not. Perhaps a forward reference to section 7 would help? §6: "[I-D.ietf-mmusic-sdp-mux-attributes] defines the mux categories for the SDP attributes defined in this specification. Table 2 defines the mux category for the ’bfcpver’ attribute:" I assume the first sentence should say "... except for bfcpver."? §10, 3rd paragraph: Incorrect comma use in "... SDP), in ..." §10.1, last paragraph: "... value, in the offer, ...": The first comma is incorrect. §10.3: First paragraph: "When the offerer receives an answer, which contains an ’m’ line..." s/ ", which" / "that" §16.2: It seems like [I-D.ietf-mmusic-sdp-mux-attributes] should be a normative reference.
- [bfcpbis] Ben Campbell's Yes on draft-ietf-bfcpbi… Ben Campbell