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 wait for direction from your document shepherd or AD before posting a new version of the draft. Document: 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 wait for direction from your document shepherd or AD before posting a new version of the draft. Document: 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 wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-dime-erp-16.txt Reviewer: Elwyn Davies Review Date: 20 Jan 2013 IETF LC End Date: IESG Telechat date: 24 jan 2013 Summary: Not ready assuming I have correctly identified that the requirements specified in RFC 5295 below are not met by this usage of the DSRK. Generally the use of the term 'domain' in this draft is rather cavalier, as it fails to explicitly tie it back to the restricted meaning of RFC 5295 and does not clarify how nodes find out what domain name they should be using. Major issues: s5, para 1: Para 1 states: To achieve this, it must learn the domain name of the ER server. How this information is acquired is outside the scope of this specification, but the authenticator might be configured to advertize this domain name, especially in the case of re-authentication after a handover. It appears that declaring learning the domain name out of scope for this specification is in conflict with RFC 5295, para 4 (top of page 12): Usages that make use of the DSRK must define how the peer learns the domain label to use in a particular derivation. This matter escaped me on the previous pass, when I just asked whether there was any suggestions of how the advertisement might be done. Minor issues: s3: In my Last call review of this document (version 12) I queried the use of the phrase 'the existence of at most one (logical) ER server entity' in two places in s3. I received an answer from one of the the authors that suggested that the phrase was self-explanatory. At the time I did not push back on this and no change has been made. On re-reading the latest version of the draft and the author's reply, I (still) feel that it would help to explain: (1) Why having more than one ER server in a domain is a mistake - apparently because this will result in EAP 'failing inappropriately' in some cases which would seem to be a reason to specifically deprecate having more then one, and explaining just what the inappropriate consequences would be. (2) The consequences of having zero ER servers in a domain. The reply to my comments seem to imply that this would just result in the 'protocol failing gracefully'. However, reading RFC 6695, para 2 of s5.1 seems to imply that having zero ER servers in the local (visited) domain may not be fatal if there is an ER server in the home domain (see also s4 of this draft). If I have interpreted this correctly, then there is a distinction between the cases (home vs arbitrary visited domain) that could usefully be brought out here rather than leaving the reader to work it out from later reading. s3, last sentence of para 1: ''we assume only one ER server that is *near* the peer involved in ERP": How are we to interpret 'near' here? Topologically or physically? How would the peer know a server was 'near' it or nearer than some other server? Nits/editorial comments: s2/s3: I assume that the term 'domain' is intended to be interpreted as in RFC 5295, i.e. as a shorthand for Key Management Domain. This needs to be spelt out here. Similarly 'home domain', 'local domain' and 'visited domain' should be explicitly mentioned as (presumably) having the same meanings as in RFC 6696.