Real-time Inter-network Defense (RID)
draft-ietf-mile-rfc6045-bis-11

I found the first sentence of the Introduction confusing!              
                                                                          
   This document moves Real-time Inter-network Defense (RID) [RFC6045]
   to Historic status as it provides minor updates.

While I can see that this document moves RFC6045 to Historic, I bet it       
is not your intention to say that RID is Historic.

How about:

   Real-time Inter-network Defense (RID) was previously defined in
   [RFC6045]. This document makes some minor updates to the RID
   specification and moves RID from an informational specification
   onto the standards track. This, this document obsoletes RFC 6045
   and moves it to Historic status.

(Maybe as a standalone paragraph and not running into the the main
text?)

The Introduction would be easier to read if the summary of changes since RFC 6045 were moved to an Appendix.

Please expand "FBI" on first use, preferably via "U.S. Federal Bureau of Investigations (FBI)".

Section 4.1.1 introduces the BOOLEAN data type, which is implemented as the xs:boolean type from W3C XML Schema. It would be helpful to note that there are two lexical representations of boolean in XML schema. I suggest changing the text as follows.

OLD
   The BOOLEAN data type is implemented as "xs:boolean" [XMLschema] in
   the schema.

NEW
   The BOOLEAN data type is implemented as "xs:boolean" [XMLschema] in
   the schema.  Note that there are two lexical representations for
   boolean in [XMLschema]: '1' or 'true' for TRUE and '0' or 'false'
   for FALSE.

In Section 5, why is this document defining a 'lang' attribute when any XML data can include the 'xml:lang' attribute via inheritance from the core XML specificiation?

The class definitions are inconsistent. I see several styles, such as:

   One.
   Zero or one.
   One or more.  REQUIRED.
   REQUIRED.  ENUM.
   One or many.  REQUIRED.
   Zero or One. URL.
   Zero to many.

It would help to make those consistent. 

Section 5.1 states:

   The RIDPolicy Class includes the ability to embed an IODEF or
   other XML schema document in the ReportSchema element.

I don't think you're embedding XML schema documents, I think you're embedding XML documents that conform to schemas other than IODEF.

Section 5.1 states:

   PolicyRegion

      One or more.  REQUIRED.  The values for the attribute "region" ....

Is that supposed to be "PolicyRegion"?

In Section 5.1.1, is "XMLDocumen" a typo?

In Section 5.3, why is the IncidentSource restricted to FQDNs (Nodes)? It seems that the source of an incident might be an IP address, an email address, etc.

This text in Section 5.4 is confusing:

   The RID schema declares a namespace of "iodef-rid-2.0" and registers
   it per [XMLNames].  Each IODEF-RID document MUST use the
   "iodef-rid-2.0" namespace in the top-level element RID-Document.

In fact the namespace is not "iodef-rid-2.0" but "urn:ietf:params:xml:ns:iodef-rid-2.0". In addition, the "Namespaces in XML 1.0" specification says nothing about registration of XML namespaces; perhaps you meant to cite RFC 3688?

In Section 5.5.1, do you really intend to include schemas, or documents defined by other schemes? 

The text in Section 6 is a bit misleading when it says that "The IODEF model MUST be fully implemented to ensure proper parsing of all RID messages." That's true only for RID messages that contain IODEF payloads, not RID messages that contain payloads defined by other schemas.

In Section 8, the XML comment is quite distracting. Why not include this information in the xs:annotation element?

Section 9.1 states:

   o  The originator of a Request MUST use a detached signature to sign
      at least one of the original elements contained in the RecordItem
      class to provide authentication to all upstream participants in
      the trace or those involved in the investigation.

Is this required even in cases where channel encryption (e.g., TLS) is used between the parties to a PeerToPeer exchange that doesn't involve upstream participants? (By the way, it seems that some of the examples in the spec violate the rule from SEction 9.1.)

In Section 9.1, do you mean "MAY" in the text "The IODEF/RID document may be encrypted"? The same question applies to "The action taken in the Result message may be encrypted". The difference between conformance and normal usage is especially confusing in a sentence like this:

   A Request, or any other message type that may be relayed through
   RID systems other than the intended destination as a result of
   trust relationships, may be encrypted for the intended recipient.

I encourage you to check all the text in Section 9.1 (and elsewhere)  to make it clear whether you intend your guidelines to have conformance force.

It's a bit confusing to say in Section 9.1 "See Section 9 for a discussion on public key infrastructure (PKI) and other security requirements." I think you mean Section 9.3. :)

Section 9.2 states:

   The transport specifications are fully defined in a separate document
   [RFC6046-bis].

I think you mean "A transport specification" because it seems that you are leaving the door open to defining other transport bindings in the future.

Section 9.2 states:

   The RID protocol must be able to guarantee delivery and meet the
   necessary security requirements of a state-of-the-art protocol.  In
   order to guarantee delivery, TCP should be considered as the
   underlying protocol within the current network standard practices.

There's a lot more to truly guaranteed delivery at the application layer than simply using TCP as the underlying transport. Do you mean at least once delivery, at most once, or something else? Do messages need to be persisted in case the messaging system crashes? And so on. You might consider dropping this paragraph, or clarifying what you really mean by guaranteed delivery.

I find this a bit confusing:

   Consortiums may vary their selected transport mechanisms and thus
   decide upon a mutual protocol to use for transport when communicating
   with peers in a neighboring consortium using RID.  RID systems MUST
   implement and deploy HTTPS as defined in the transport document
   [RFC6046-bis] and optionally support other protocols such as the
   Blocks Extensible Exchange Protocol (BEEP) [RFC3080].

If consortia are allowed to decide upon their own preferred transport bindings, why is HTTP/TLS a MUST-deploy technology?

As to "optionally support other protocols", clearly someone would need to define bindings for those protocols (BEEP or XMPP or SIP or whatever) before they could be used -- it appears that one can't simply start sending RID documents over those protocols without some definition of the binding (as is already done for things like SOAP). So the current text is a bit misleading.

Section 11 states:

      Registrant Contact: See the "Author's Address" section of this
      document.

However, RFC 3688 states:

   In the case of IETF developed standards, the Registrant will be the IESG.

- Expand CSIRT on first use (and maybe include a reference?)

- The FBI is not a good example and not really needed. Precede it
with United States or something if you keep it.

- What is an "intermediate party" (p32) shouldn't stuff like that
be explained up front? What's the model for multiple hops here -
are requests and responses supposed to be passed on without any
controls on the intermediary or not? If not, then what controls
and how do those impact on the protocol?

- Corner case security consideration - related to figure 8, if I
can monitor the n/w connections of SP3, then when SP3 receives a
message from SP2 and then replies to SP2 *and* SP1 then I get to
know for whom SP2 was forwarding the request. Not sure if that's
significant really but I guess it could alert a bad guy to stop
doing stuff before the final tracing stage happens. I guess the
only mitigation would be traffic padding of some sort if (as I
suspect) traffic volunes here are small. (Does RID support traffic
padding?) If you ever allowed an insecure transport then this
might get worse, if the bad guy could flip a bit in the request
and then see the ack to SP1 connection being attempted, then the
bad guy gets his warning but SP3 hasn't got the message.

- 9.3.2 is oddly titled, seems like you're really talking about
a signature being verifiable at many veryifiers.

- I don't get what "In some situations, all network traffic of a
nation may be granted through a single SP.  " means. (p73)