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 mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
