Last Call Review of draft-ietf-mile-rfc6046-bis-

Request Review of draft-ietf-mile-rfc6046-bis
Requested rev. no specific revision (document currently at 09)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2012-01-17
Requested 2012-01-06
Authors Brian Trammell
Draft last updated 2012-01-14
Completed reviews Genart Last Call review of -?? by Alexey Melnikov
Secdir Last Call review of -?? by Leif Johansson
Tsvdir Last Call review of -?? by Mark Allman
Assignment Reviewer Alexey Melnikov
State Completed
Review review-ietf-mile-rfc6046-bis-genart-lc-melnikov-2012-01-14
Review completed: 2012-01-14


I am the assigned Gen-ART reviewer for this draft. For background on 

Gen-ART, please see the FAQ at 


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 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