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-02.txt Reviewer: Brian Carpenter Review Date: 2008-02-07 IETF LC End Date: 2008-02-27 IESG Telechat date: (if known) Summary: Queries about normative dependencies Comments: Disclaimer: This draft is long, the topic is new to me, and I haven't checked the XML syntax. Also, I don't know enough of the history of the INCH WG to grock why that group closed with this document and its companions adrift. My comments are mainly concerned with references and what is or isn't normative. 4. Communication Between Network Providers Note: The introduction and sub-sections 4.1 and 4.2 are informative. Sub-sections 4.3, 4.4, 4.5 are normative. ... Transport for RID messages is specified in the IODEF/RID over SOAP [RFCYYYY] document. That sounds like a normative statement to me, and [RFCYYYY] is not cited elsewhere. Also, shouldn't SOAP be a normative reference too? It is a normative reference in [RFCYYYY]. 4.3 Message Formats The following section describes the six RID message types which are based on the IODEF model. There is a reference for IODEF ([RFCXXXX]) which I think needs to be cited here. 4.3.3 IODEF-RID Schema ... RIDPolicy Zero or One. The RIDPolicy class is used by all message types to facilitate policy agreements between peers, consortiums or federations as well as to properly route messages. RequestStatus Zero or One. This is used only in Request Authorization messages to report back to the originating RID system if the trace will be continued by each RID system that received a TraceRequest in the path to the source of the traffic. IncidentSource Zero or One. The IncidentSource class is used in the Result message only. The IncidentSource provides the information on the identified source host or network of an attack trace or investigation. None of these seems to explain the semantics. What does zero or one *mean* in each case? I think this problem arises elsewhere too. 6. Message Transport The transport specifications is fully defined in a separate document. That needs a (normative?) reference (and s/is/are/). 6.1 Message Delivery Protocol - Integrity and Authentication ... RID systems MUST support HTTPS and optionally support other protocols such as BEEP. This is about the only normative statement in this normative section. Does it mean MUST implement or MUST deploy? 6.3 Authentication of RID Protocol In order to ensure the authenticity of the RID messages, a message authentication scheme using is used to secure the protocol. SOAP tied together with TLS used with BEEP or HTTP(S) using WS-Security requires a trust center such as a PKI for the distribution of credentials to provide the necessary level of security for this protocol. Is this intended as a normative requirement of WS-Security? If so, a MUST and a normative reference are both missing. In general there's a need to check the status of all the normative references; idnits is unhappy (see below). Nits: Why are sections 10.1-10.3 sub-sections of section 10? idnits said: Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFC 3967 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2119' is defined on line 3067, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 3128, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'RFCXXXX' -- Possible downref: Non-RFC (?) normative reference: ref. 'RFCYYYY' -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- 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
