Telechat Review of draft-ietf-dime-erp-16
review-ietf-dime-erp-16-genart-telechat-davies-2013-02-27-00

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.