Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS
draft-ietf-mile-rfc6046-bis-09

First, thank you for addressing the comments that Julian Reschke provided on behalf of the Apps Directorate.

Section 3 states:

   RID systems MAY be configurable to listen on
   ports other than the well-known port; this configuration is out of
   band and out of scope for this specification.

and:

   When performing RID callback, a responding system MUST connect to the
   host at the network-layer address from which the original request was
   sent; there is no mechanism in RID for redirected callback.  This
   callback SHOULD use TCP port 4590 unless configured out of band to
   use a different port.

What does it mean to configure a RID system out of band? As far as I can see there is no *in-band* configuration method (i.e., a RID system cannot be configured via RID messages), so the use of "out of band" here is confusing. I suggest removing this terminology in both instances.

The ABNF reference is old; please change [RFC2234] to [RFC5234].

Section 3 states:

   RID systems MUST use TLS version 1.1 [RFC4346] or higher with mutual
   authentication for confidentiality, identification, and
   authentication, as in [RFC2818], when transporting RID messages over
   HTTPS.

The phrase "as in [RFC2818]" makes it sound as if the rules specified in RFC 2818 are the kind of rules that might be used, not that those rules must be followed. If the intent is that the identity-checking rules in RFC 2818 always apply to RID systems, I suggest changing the text to:

   RID systems MUST use TLS version 1.1 [RFC4346] or higher with mutual
   authentication for confidentiality, identification, and authentication when
   transporting RID messages over HTTPS.  RID systems MUST follow the
   rules specified in [RFC2818] regarding verification of endpoint identities.

I wonder how easy it is to find a HTTP client implementation
that won't follow 3xx response codes. I don't know, just wonder:-)