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

[Benoit Claise <[e-mail]>]

draft-ietf-dime-erp authors,

Please address this feedback, ideally before the IESG telechat this 
Thursday.

Regards, Benoit
> 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.
>
>