I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments you may receive. Document: draft-moriarty-post-inch-rid-soap-03 Reviewer: Ben Campbell Review Date: 08-02-22 IETF LC End Date: 08-02-28 IESG Telechat date: (if known) Summary: This document is almost ready for for publication as a proposed standard RFC, but there are some issues and questions that should be addressed first. Comments: General: I think this document would benefit from some reorganization, as there are a lot of redundant statements between sections. For example, the argument about why HTTP is the baseline even though BEEP might be better is restated in several different sections for no apparent reason. Similarly, the reason for using SOAP in the first place is presented multiple times. IDNITS Section 1.1: Why is this a subsection of section 1? 1.1, first paragraph: Please expand CSIRTS and SOAP on first use. 1.1, last paragraph, last paragraph: Need a normative reference for "Standards exist for the HTTPS or HTTP/ TLS binding for SOAP" "Standards MUST be followed..." is too vague for a normative statement. The document needs to specify which standards are required for each binding. I think you mean to say that RFC4346 must be followed, but there is too much digression between the first and last sentence of the paragraph for that to be obvious. I think it would help to separate the rational for the binding choices from the statement about what standards must be implemented. Section 2, paragraph 2: The first sentence is very hard to parse. Need a normative reference for the RID schema, and possibly for the RIDPolicy class. 3.1, paragraph 1, final sentence: "Security is provided through the RID specification and all REQUIRED RID security MUST be implemented." _What_ must implement the security requirements? All RID elements? Intermediaries? 3.2, paragraph 1: How long should a device remember that it's peer doesn't implement BEEP? Surely not forever, or this would prevent anything from every upgrading to BEEP. I'm not looking for a precise state-machine, just some high-level guidance. Section 5, general: The security considerations here are highly dependent on those of the IODEF and RID. I have not studied those documents to see if they provide sufficient security considerations. Hopefully they go into more detail on potential vulnerabilities, the consequence of not using the confidentiality and authentication features, and when said security features need to be used. Section 5, second paragraph: I'm a little concerned about referencing the WS security document in passing like this with no elaboration. 5.2, paragraph 1: Is TLS expected to be used for mutual authentication, or just server authentication? Section 6: Which port range should the ports be chosen from? Section 7: Is this section needed? It seems redundant with the abstract. IDNITS complains about the following: > == The page length should not exceed 58 lines per page, but there > was 1 > longer page, the longest (page 21) being 59 lines > > > == There are 1 instance of lines with non-RFC3330-compliant IPv4 > addresses > in the document. If these are example addresses, they should > be changed. > > == Unused Reference: 'RFC2119' is defined on line 881, but no > explicit > reference was found in the text > _______________________________________________ Gen-art mailing list [email protected] http://www.ietf.org/mailman/listinfo/gen-art
