I have been selected as the Applications Area Directorate reviewer for 
this draft (for background on appsdir, please see 
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).

Please resolve these comments along with any other Last Call comments 
you may receive. Please wait for direction from your document shepherd 
or AD before posting a new version of the draft.

Document: draft-ietf-mile-rfc6046-bis-03
Title: Transport of Real-time Inter-network Defense (RID) Messages
Reviewer: Julian Reschke
Review Date: 2011-12-11
IETF Last Call Date: not last-called yet
IESG Telechat Date: -

Summary: This draft is almost ready for publication as as a Proposed 
Standard and should be revised before publication

NOTE: I have *not* reviewed any security-related aspects.


Major Issues:

-

Minor Issues:

As pointed out in Section 3, this protocol really (ab)uses HTTP as a 
simple transport, and uses only a tiny subset of HTTP. This is properly 
explained, and the decision to use a custom port number makes sense.

What I'm missing here are a few things that would probably make it 
easier to understand what's actually required:

1) Does a RID endpoint need to implement all REQUIRED HTTP/1.1 features? 
For instance, does it need to understand Expect: 100-continue, and does 
it have to support GET and HEAD on "/"? Are there requirements for 
request URIs other than "/"?

2) What's the Internet Media Type to be used with RID payloads? Is it 
defined? If no, why not? Is it required to be used?

3) How do retries work when a request fails? Is the use of POST here 
idempotent so that the request can be repeated?

4) How does matching between request and callback work?

5) It might be a good idea to add a complete example of an exchange that 
uses the callback pattern.

Also, in Section 4:

    For transport confidentiality, identification, and authentication,
    TLS with mutual authentication MUST be used to secure the HTTP
    connection as in [RFC2818].  The session MUST use non-NULL
    ciphersuites for authentication, integrity, and confidentiality;
    sessions MAY be renegotiated within these constraints.  Although TLS
    implementations typically support the older SSL protocol, a RID peer
    MUST NOT request, offer, or use any version of SSL, or any version of
    TLS prior to 1.1 [RFC4346], due to known security vulnerabilities in
    prior versions of the protocol; see Appendix E of [RFC5246] for more.

This is a bit confusing because RFC5246 obsoletes RFC4346; there's 
probably a good reason for what it says here, but it might be good to 
explain what it is.

Nits:

    RID systems SHOULD NOT use TCP port 443 (the standard port for HTTP
    over TLS/SSL) for RID messages; this avoids posting RID messages to
    web servers that may not handle RID messages correctly.

Actually, it does not, because a web server may run on the RID port 
(4590) as well. If there's a security concern with the protocol with 
respect to generic web servers, it should be pointed out (and 
potentially fixed).

Abstract:

    (...).  This document updates the previous [RFC6046] to
    change the intended status to Proposed Standard, and to reference the
    updated RID specification.

This is procedural and should be moved to the Introduction (this will 
also fix the issue of having a reference in the Abstract).

    among members in a RID consortium.  This document specifies the
    transport of RID messages within HTTP [RFC2616] Request and Response
    messages transported over TLS [RFC5246] (herein, HTTP/TLS).  Note

Missing "." after [RFC2616].

1.2. Normative and Informative sections

    Section 3, Section 4, and Section 5 of this document are normative;
    the remainder of the document is informative.

I don't think is is needed here.

References:

draft-moriarty-mile-rfc6045-bis-02: [2011-08-27 ID-Exists Replaced] (not 
active)
RFC4346: [PROPOSED STANDARD] obsoleted by RFC5246; maybe this one is 
informative?


Best regards, Julian