[rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-security-arch-18: (with COMMENT)
Ben Campbell <firstname.lastname@example.org> Tue, 05 March 2019 03:49 UTC
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 21211130EFF; Mon, 4 Mar 2019 19:49:27 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
From: Ben Campbell <email@example.com>
To: "The IESG" <firstname.lastname@example.org>
Cc: email@example.com, Sean Turner <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, email@example.com
Date: Mon, 04 Mar 2019 19:49:27 -0800
Subject: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-security-arch-18: (with COMMENT)
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:email@example.com?subject=subscribe>
X-List-Received-Date: Tue, 05 Mar 2019 03:49:27 -0000
Ben Campbell has entered the following ballot position for draft-ietf-rtcweb-security-arch-18: 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-rtcweb-security-arch/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm balloting "yes", but have a few minor comments and editorial comments: §1: - (nit) The first sentence will not age well; I gather RTCWEB will close before long. (also The WG acronym is RTCWEB, not WebRTC. Or are you talking about the W3C?) - (nit) Figure 2: It seems a bit weird to have XMPP here, but never mentioned in the text. At least, please expand the abbreviation somwhere. (It also shows up in figure 4.) (nit) §3.1, first bullet: While I don't normally object (beyond nose holding, anyway) to the use of first person in RFCs, it seems an odd choice for this sentence. I assume "we" in this sentence does not refer to the the author or the WG. §4.1: (nit) - '... button next to Bob’s name which says "Call".': s/which/that - "The calling site will also provide some user interface element (e.g., a button) to allow Bob to answer the call, though this is most likely not part of the trusted UI." This is the first mention of "trusted UI". It would be helpful to elaborate on that prior to this mention. §5.1.4: - "In this case, the established identity SHOULD be applied to existing DTLS connections as well as new connections established using one of those fingerprints." Applied by the recipient? (consider active voice). Also, why not MUST? Don't unexpected things happen if the recipient doesn't do this? §6.2: - "Because HTTP origins cannot be securely established against network attackers, implementations MUST NOT allow the setting of permanent access permissions for HTTP origins. Implementations MUST refuse all permissions grants for HTTP origins." (nit-ish) - The MUST NOT seems non-constraining considering the last sentence. Or am I reading that sentence wrong? (nit) - .E.g., "Call firstname.lastname@example.org"' : sentence fragment. (nit) - ".. unlikely that browsers would have an X.509 certificate..." : Plural disagreement (assuming the browsers do not share 1 cert). (maybe nit) - "Clients MAY permit the formation of data channels without any direct user approval." Is the switch from talking about "the browser" to "Clients" intentional? §6.4: (nit) - "Note that these requirements are NOT intended..." "NOT" in all caps is likely to be confused with 2119/8174 language. §6.5: (nit) - "Implementations MUST implement SRTP [RFC3711]. Implementations MUST implement DTLS [RFC6347] and DTLS-SRTP [RFC5763][RFC5764] for SRTP keying. Implementations MUST implement [RFC8261]." Thank you for using the citation style that doesn't assume everyone has memorized the RFC numbers. But why not do the same for 8261? §7.2: (nit) - First paragraph: Can there be a citation for the W3C API spec? §7.1.4, SDP example: We just had a report against draft-ietf-mmusic-sdp-simulcast claiming that putting "t=" after "c=" is not legal. 4566 and 4566bis seem to support that. (I realize that, if that's in fact an error, we've got it all over the place.) (nit) §11: The first sentence is a fragment. §13.1 (normative references) (nit) - There's a reference to RFC 5234, but it is not cited in the text. - Is there a reason to reference 5246 rather than 8446, which obsoleted it? §13.2: - seems like the jsep reference should be normative.
- [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-… Ben Campbell