On 09/25/2012 05:03 AM, Elwyn Davies wrote:
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'?
Oddly enough, it means just what it says.
If not, what happens if there is exactly zero servers for either
> type?
Both protocols will fail gracefully.
What would the consequences of there being more than one
> logical server?
If the message is directed to a logical server not in possession of the
rRK or rDSRK (depending upon where the server is located), ERP will fail
inappropriately.
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).
I don't think so.
This would seem to imply that the zero case means that it may not be
> essential to have an ER server in a domain.
It's not.
> 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?
Yes.
If not please refer to the
> previous comment.
>
> s5, para 1: How would the authenticator advertise the domain name in
> this context?
That is outside the scope of this draft.
> 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?) -
I don't think so.
s8 of RFC
> 6696 (does the DIME usage preserve the limited key scope?; is the
> domino effect equally well avoided?)
Yes and yes.
> 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.'
These are both defined in RFC 4072.
> s2, para 2: Need to expand acronyms rRK and rDSRK.
rRK is defined in RFC 6696.
> s4, para 7: Should explicitly say that the ERP/DEA message is sent to
> the authenticator.
It's not: the authenticator is an EAP protocol entity. The message is
sent to the Diameter peer, like all Diameter answer messages.
> s8.3.3: s/RGC 6696/RFC 6696/
>
>
Fixed, thanks.