Hello Ben, Thank you for the feedback. I have addressed your comments and submitted an updated draft. I will outline below how the comments were addressed, please let me know if there are any additional issues.
Thank you, Kathleen -----Original Message----- From: Ben Campbell [mailto:[EMAIL PROTECTED] Sent: Friday, February 22, 2008 5:17 PM To: [email protected] Cc: [EMAIL PROTECTED]; Moriarty, Kathleen; [EMAIL PROTECTED] Subject: Gen-ART review of draft-moriarty-post-inch-rid-soap-03 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. >> I went through and removed redundant text and tried to put the text >> for each of the areas in the correct locations. IDNITS Section 1.1: Why is this a subsection of section 1? 1.1, first paragraph: Please expand CSIRTS and SOAP on first use. >> I expanded CSIRTs, but SOAP is no longer an acronym, so I did not >> expand SOAP. 1.1, last paragraph, last paragraph: Need a normative reference for "Standards exist for the HTTPS or HTTP/ TLS binding for SOAP" >> Re-organized and referenced the necessary documents. "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. >> Agreed, reworded the section. I think it would help to separate the rational for the binding choices from the statement about what standards must be implemented. >> OK. Section 2, paragraph 2: The first sentence is very hard to parse. >> Reworded the sentence to address the issue. Good catch, thank you. Need a normative reference for the RID schema, and possibly for the RIDPolicy class. >> Added reference to the RID schema. 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? >> A previous security AD had asked that all security stay in RID in >> case transport changed down the road. I removed some of this text, >> I hope that addresses the concern. 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. >> I added some guidance, but said it should be configurable for length >> and duration, recommended on week, but based on system resources. 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. >> Removed and re-worded. 5.2, paragraph 1: Is TLS expected to be used for mutual authentication, or just server authentication? >> Mutual authentication, good catch, thank you Section 6: Which port range should the ports be chosen from? >> Addressed Section 7: Is this section needed? It seems redundant with the abstract. >> I typically have summary sections for papers, I thought that was >> standard with these documents as well? 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 > OK > > == There are 1 instance of lines with non-RFC3330-compliant IPv4 > addresses > in the document. If these are example addresses, they should > be changed. > Section number, not an IP > == Unused Reference: 'RFC2119' is defined on line 881, but no > explicit > reference was found in the text > There was a space between RFC and 2119, fixed.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Gen-art mailing list [email protected] http://www.ietf.org/mailman/listinfo/gen-art
