[Gen-art] Gen-ART last call review of draft-ietf-mile-rfc6046-bis-05

[Alexey Melnikov <[e-mail]>]

I am the assigned Gen-ART reviewer for this draft. For background on 
Gen-ART, please see the FAQ at 
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments 
you may receive.

Document: draft-ietf-mile-rfc6046-bis-05
Reviewer: Alexey Melnikov
Review Date: 2012–01–14
IETF LC End Date: 2012-01-17
IESG Telechat date: 2012-01-19

Summary: This draft is almost ready for publication as a Proposed 
Standard RFC.


Major issues:

In Section 3:

    The RID callback MUST contain a zero-length entity body
    and a 'RID-Callback-Token' entity header

[Minor issue] "header" --> "header field" (header is the collection of 
all header fields).

    , itself containing a unique
    token generated by the receiving RID system.

I am missing ABNF for the new header field.


    RID systems MUST use TLS version 1.1 [RFC4346] or higher with mutual
    authentication for transport confidentiality, identification, and

Do you mean that a RID client must use X.509 certificates?

    authentication, as in [RFC2818].

I find the whole sentence to be confusing. Note that the rules of RFC 
6125 for certificate verification are stricter than in RFC 2818 and this 
sentence can be read as conflicting with the paragraph below which 
requires use of RFC 6125. What are you trying to say here?


    RID systems MUST provide for the verification of the identity of a
    RID system peer presenting a valid and trusted certificate, by
    verifying the fully-qualified domain name and service name from the
    DNS SRV record, if available, against that stored in the certificate,

I am confused: this is the first time DNS SRV records are mentioned
(BTW, they need a Normative Reference). Earlier text seem to suggest 
that DNS SRV are not used to locate protocol endpoints. If RID is using 
DNS SRV, then information about how it is used is missing from the document.

    as in Section 6 of [RFC6125].

RFC 6125 allows for various options and this paragraph doesn't seem to 
cover all of them. I suggest you check Section 13.7.1.2.1 of RFC 6120 
for an example of what should be specified (ignore XmppAddr identifier 
type, as it is very XMPP specific). For X.509 SANs which are disallowed, 
you should say so.


Minor issues: (ones issue listed above)

Nits/editorial comments: None