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

Elwyn Davies <elwynd@dial.pipex.com> Mon, 24 September 2012 22:03 UTC

Message-ID: <5060D8AB.8010807@dial.pipex.com>
Date: Mon, 24 Sep 2012 23:03:23 +0100
From: Elwyn Davies <elwynd@dial.pipex.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: General Area Review Team <gen-art@ietf.org>
Content-Type: multipart/alternative; boundary="------------040503010107030401050602"
Cc: draft-ietf-dime-erp.all@tools.ietf.org
Subject: [Gen-art] Gen-art LC review of draft-ietf-dime-erp-12
Precedence: list

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/

[Gen-art] Gen-art LC review of draft-ietf-dime-er… Elwyn Davies
Re: [Gen-art] Gen-art LC review of draft-ietf-dim… Glen Zorn