Title: 

Gen-art LC review of draft-ietf-dime-erp-12





  
  
    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-dime-erp-12.txt


    Reviewer: Elwyn Davies


    Review Date: 24 September 2012


    IETF LC End Date: 24 September 2012


    IESG Telechat date: (if known) -





    Summary:


    Almost ready for the IESG.  There are some minor wording issues to
    sort out in s3, some advice on advertising domain names in s5 and
    possibly some extra words needed in the security considerations.  In
    addition there a few minor nits.


     


    Major issues:


    None.





    Minor issues:


    s3: Both paragraphs use the phrase '...document assumes the
    existence of at most one...'.  Does this really mean 'exactly one'? 
    If not, what happens if there is exactly zero servers for either
    type?  What would the consequences of there being more than one
    logical server?  Is this tied into the statement in s4:




> The ER server is located either
      in the home domain (same as EAP 


      > server) or in the visited domain (same as authenticator, when
      it 


      > differs from the home domain).


    This would seem to imply that the zero case means that it may not be
    essential to have an ER server in a domain.





    S3, para 1:




> If multiple ER servers are
      deployed in the domain, we assume that


      > they can be used interchangeably.


    Are we talking physical servers here?  If not please refer to the
    previous comment.





    s5, para 1: How would the authenticator advertise the domain name in
    this context?





    s13:  Looking at the various security considerations that are
    imported, I wondered if some extra words were needed in respect of a
    couple of the cases:


    - s8.4 of RFC 4072: (does distributing the bootstrapping master key
    make things any worse here?)


    - s8 of RFC 6696 (does the DIME usage preserve the limited key
    scope?; is the domino effect equally well avoided?) 





    Nits/editorial comments:





    s1: 'and re-use the Diameter EAP commands (DER/DEA).' : DER and DEA
    ought to be expanded here. Or it might be less verbose to point at
    s2 where they are currently expanded, thus: 'and re-use the Diameter
    EAP commands listed in Section 2.'





    s2, para 2: Need to expand acronyms rRK and rDSRK.





    s4, para 7: Should explicitly say that the ERP/DEA message is sent
    to the authenticator.





    s8.3.3: s/RGC 6696/RFC 6696/