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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]