Skip to main content

Last Call Review of draft-ietf-dime-erp-12

Request Review of draft-ietf-dime-erp
Requested revision No specific revision (document currently at 17)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2012-09-24
Requested 2012-09-14
Authors Julien Bournelle , Lionel Morand , Sebastien Decugis , Qin Wu , Glen Zorn
I-D last updated 2012-12-20
Completed reviews Genart Last Call review of -12 by Elwyn B. Davies (diff)
Genart Telechat review of -16 by Elwyn B. Davies (diff)
Secdir Last Call review of -14 by Vincent Roca (diff)
Secdir Telechat review of -16 by Vincent Roca (diff)
Assignment Reviewer Elwyn B. Davies
State Completed
Request Last Call review on draft-ietf-dime-erp by General Area Review Team (Gen-ART) Assigned
Reviewed revision 12 (document currently at 17)
Result Almost ready
Completed 2012-12-20

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



    Please resolve these comments along with any other Last Call

    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) -


    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:


    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

      > 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/