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