Hi, thanks for the quick response. A few additional comments occurred to me since my original review--I apologize for not getting these in the first round:
1) I am not an expert on the conventions for defining SOAP wrappers-- but should this document include WSDL? (This is more of a question than a request for a change.) 2) It might be helpful to show at least one of the examples in the context of an actual HTTP exchange, i.e. an HTTP POST request and response. 3) You reference RFC 4346 for HTTP/TLS. RFC 4346 is for TLS 1.1 itself, not really HTTP/TLS. That was actually defined in RFC 2818, which is unfortunately only an informational RFC. I'm not sure how this reference should be handled--it's probably worth getting some AD advice. 4) The URLs in your references [3] and [4] do not reference the described documents. More inline (Note the original quoting is reversed for some reason): On Feb 25, 2008, at 1:31 PM, [EMAIL PROTECTED] wrote: [...] > 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. That helps, thanks! [...] >>> Section 1.1: > > Why is this a subsection of section 1? This was not fixed in the new version. To be clear, the "introduction" section is a sub-section of the "terminology" section, which I don't think was the intent. > > > 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. Okay. >>> > > 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. > The reorganization helps, but see my comment about the RFC 4346 reference above. > "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. Thanks >>> > > I think it would help to separate the rational for the binding choices > from the statement about what standards must be implemented. > >>> OK. Thanks >>> > > Section 2, paragraph 2: > > The first sentence is very hard to parse. > >>> Reworded the sentence to address the issue. Good catch, thank you. > It's better, thanks. > > Need a normative reference for the RID schema, and possibly for the > RIDPolicy class. > >>> Added reference to the RID schema. > Thanks. > 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. > It addresses my concern, assuming that the removal of text does not cause issue for someone else. > 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. That addresses my concern, and then some :-) Thanks. >>> > > 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. I don't see the change--the paragraph seems to be the same as before. >>> > > 5.2, paragraph 1: > > Is TLS expected to be used for mutual authentication, or just server > authentication? > >>> Mutual authentication, good catch, thank you Thanks. >>> > > Section 6: > > Which port range should the ports be chosen from? > >>> Addressed Thanks >>> > > 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? > I don't know of any rule against such a section, although drafts and RFCs do have the initial abstract, which seems to me to serve the same purpose. > 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 IDNits no longer complains about this > > >> >> == 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 Okay. > > >> == 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. That warning went away in IDNits, but there are new warnings: > Miscellaneous warnings: > > ---------------------------------------------------------------------------- > > == The copyright year in the IETF Trust Copyright Line does not > match the > current year > > > Checking references for intended status: Proposed Standard > > ---------------------------------------------------------------------------- > > (See RFCs 3967 and 4897 for information about using normative > references > to lower-maturity documents in RFCs) > > ** Downref: Normative reference to an Unknown state RFC: RFC 3080 > > ** Downref: Normative reference to an Unknown state RFC: RFC 3205 > > ** Downref: Normative reference to an Unknown state RFC: RFC 3275 > > ** Downref: Normative reference to an Unknown state RFC: RFC 4227 > > ** Downref: Normative reference to an Unknown state RFC: RFC 4346 > > -- Possible downref: Non-RFC (?) normative reference: ref. 'RFCXXXX' > > == Outdated reference: A later version (-04) exists of > draft-moriarty-post-inch-rid-02 > > -- Possible downref: Non-RFC (?) normative reference: ref. '3' > > -- Possible downref: Non-RFC (?) normative reference: ref. '4' > > -- Possible downref: Non-RFC (?) normative reference: ref. '5' > _______________________________________________ Gen-art mailing list [email protected] http://www.ietf.org/mailman/listinfo/gen-art
