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'