[Gen-art] Telechat review of draft-ietf-dime-erp-16.txt

[Elwyn Davies <[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 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.