XXXX = 5070

Abstract doesn't talk about "this document" which is a little unusal and
means that care has to be taken to understand the purpose of the I-D.
This could be fixed pretty easily.

---

It is usual for the first section (and therefor the first text) in the
body of the I-D to tbe Introduction

---

Section 1

    Note: The documented procedures represent the consensus of another
    group and are included to further describe environments where this
    schema can be used.  The documented procedures are not required for
    conformance to this specification.

This is a little mysterious. You have to get to Section 4 to find out 
what "other group" is meant.

Note that it might be helpful to clarify that the "procedures" you 
refer to are not protocol procedures (which is the type of procedure
we are used to seeing in IETF documents), but "incident handling 
procedures."

It would be nice if Section 4 included references to other documents,
not just to the groups.

  From Ben Campbell's Gen-ART Review of
  draft-moriarty-post-inch-rid-soap-05.txt:

  Since this document specifies SOAP over HTTP, I would like to see  
  at least one of the examples show the SOAP exchange in the context of  
  actual HTTP messages.

  I am still not sure the reference for HTTP/TLS in section 1 is  
  correct. The original draft referenced RFC 4346 for HTTP/TLS, and I  
  commented that 4346 defines TLS, but not HTTP/TLS. The author changed  
  the wording to "HTTP over TLS V1.1 [RFC4346]", which technically  
  solves the problem, but we are then left with no normative reference  
  for HTTP/TLS at all. It may be that this is the best we can do, as the  
  only reference I could dig up for this is 2818, which is  
  informational--but it seems unsatisfying to not be able to come up  
  with _some_ normative reference for HTTP/TLS.

In Section 2, last paragraph:

Informative references for SNMP and NetConf are missing.

Informative references for HTTPS and BEEP are missing elsewhere.

1. Section 1 

    Note: The documented procedures represent the consensus of another
    group and are included to further describe environments where this
    schema can be used.  The documented procedures are not required for
    conformance to this specification.

The document refers to ‘another group’ – which other group? as this is an individual submission

2. Section 2: 

    NPs typically manage and monitor their networks through a
    centralized network management system (NMS).  The acronym NMS will
    be used to generically represent management servers on a network
    used for the management of network resources.

The term ‘management server’ does not really mean anything. Many of the management applications are clients, or a combination of clients and servers using various protocols and interconnecting with various entities. Better use ‘management stations’ or ‘management systems’.

1. In Section 5, the XML schema has an incorrect schemaLocation:

<xs:import namespace="urn:ietf:params:xml:ns:iodef-1.0"
 schemaLocation="urn:ietf:params:xml:ns:iodef-1.0"/>

I think that should be:

<xs:import namespace="urn:ietf:params:xml:ns:iodef-1.0"
 schemaLocation="http://iana.org/iodef/ietf-inch-rid-1.0.xsd"/>

2. Section 6 states:

    The specified transport protocols must use
    encryption to provide an additional level of security, integrity,
    and authentication through bi-directional certificate usage.

Do you mean "MUST" here?

Does "bi-directional certificate usage" mean mutual authentication? If so, let's state that.

3. In Section 3.2, should the "must" be "MUST" here?

    Trust relationships may also be defined through a bridged or
    hierarchical PKI in which both peers belong.

and here?

    Systems used to send authenticated RID messages between networks
    MUST use a secured system and interface to connect to a border
    Network's RID systems.  Each connection to a RID system must meet
    the security requirements agreed upon through the consortium
    regulations, peering, or SLAs.  The RID system must only listen for
    and send RID messages on the designated port, which also must be
    over an encrypted tunnel meeting the minimum requirement of
    algorithms and key lengths established by the consortium, peering,
    or SLA.  The selected cryptographic algorithms for symmetric
    encryption, digital signatures, and hash functions must meet
    minimum security levels of the times.  The encryption strength must
    adhere to import and export regulations of the involved countries
    for data exchange.

(There are similar issues in Section 6.3 regarding "may" and "must", and really throughout the document -- please check your usage of RFC 2119 terms for accuracy and consistency.)

4. In Section 7, we find:

      It should be noted, there are cases for
      transport where the RIDPolicy class MUST be presented in clear
      text as detailed in the transport document [RFCYYYY].

Here I think you want to replace "MUST" with "needs to" or somesuch.

#1) Header: r/Intended-status: Informational/Intended status: Informational

#2) As per IDNits: Update reference to 3281 with 5755 and 3330 with 5735.

#3) Sec 4.3.3.1: r/[RFC 5070]/[RFC5070]

#4) Sec 4.3.3.1: r/One.  Boolean./One.  BOOLEAN.

#5) Sec 4.3.3.2 & .3: r/IODEF 3.16/IODEF [RFC5070] section 3.16.

#6) Sec 4.3.3.3: r/See RFC5070]/See [RFC5070]

#7) Sec 6.3: r/Certificate Authority (CA)/Certification Authority (CA)