I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-rtcweb-security-arch-18 Reviewer: Russ Housley Review Date: 2019-02-07 IETF LC End Date: 2019-02-15 IESG Telechat date: unknown Summary: Almost Ready Major Concerns: Section 4.1 says "... preferably over TLS ...", but it does not tell what the consequences are if TLS is not used. Since this is the security architecture, I would expect these consequences to be described. Section 4.2: Please add a sentence or two that defines Interactive Connectivity Establishment (ICE) data and non-ICE data. Section 6.5 includes a contradiction. One place it says, " MUST NOT negotiate cipher suites with NULL encryption", and another place it says, "if Null ciphers are used ...". Please make these consistent. Section 6.5 requires implementation of certificate fingerprints or a Short Authentication String (SAS). Please add a sentence to tell how they are used to provide out-of-band verification. Without such a sentence, it is easy to imagine an implementation with a UI that is too awkward to actually get the information on the screen while the call is in progress. Section 10: since this is a standards track document, the IESG should be responsible for this new codepoint, not the document author. Minor Concerns: Section 3.1 uses https://www.evil.org/ as an example. However, this is a registered domain. It would be better to follow the IESG statement on examples: https://www6.ietf.org/iesg/statement/examples.html. Section 6.2 uses customerservice@ford.com as an example. Of course, ford.com is a registered domain. It would be better to follow the IESG statement on examples (the URL is above). Section 7 uses Poker Galaxy as an example. Of course, this is a real web site. It would be better to follow the IESG statement on examples (the URL is above). It seems best to use the same names here as are used in Section 7.2. Nits: Section 1 includes: "... SDP-based like SIP." Please add a reference for SDP. Section 4.1: s/ permissions till later/ permissions until later/ Section 4.4: please add a reference for STUN. Section 6.2: s/(though see Section 6.3/(See Section 6.3/ Section 6.4: please do not enclose the note is '[' and ']'. Avoid confusion with reference syntax. One solution is to put the note at the end of the paragraph. Section 6.4: s/non-turn candidates/non-TURN candidates/ Section 6.5: the phrase "Implementations MUST implement" seems awkward. Perhaps "Implementations MUST support". This appears several places. Section 6.5 ought to begin with "All data channels MUST be secured via DTLS." This appears half way through the section, but the material that comes before is really in support of this sentence. Section 8.1 discusses "@", but the discussion of "user" (note the quotes) and the discussion of domain (note the absense of quotes) are using different conventions. Please use quotes in both places or neither place. There are places in this document where "settings" is confusing. It is unclear whether the word is referring to configuration settings or it is referring to an environment or situation. Please look at each use of this word and consider alternatives.