Re: [HOKEY] draft-ietf-hokey-preauth-ps-08.txt

["Hoeper Katrin-QWKN37" <khoeper at motorola.com>]

Hi,

I have reviewed the new version. The draft significantly improved and
addressed almost all the issues I have raised in my previous review
(http://www.ietf.org/mail-archive/web/hokey/current/msg01590.html).
There are a few issues left that I'd like to discuss. See my general
comments and a short list of nits below.

For future revisions, I would like to ask the editors to describe how
they addressed previously raised issues or why they didn't address some.
Otherwise it's very difficult to keep track of the discussion and new
draft releases.

Best regards,
Katrin

<General comments>

*) In the draft, it seems that EAP server and AAA server are used
interchangeably at times (or all the time?). For instance, in Section 5
<quote> Consider first the case where the authenticators operate in
pass-through mode, so that the EAP server is a AAA server </quote>. This
is not the correct definition of "pass-through mode". In all Figures EAP
Server and AAA Server are treated as the same entities. I think this
needs some further explanation/discussion and should be included in
Section 2, where EAP server and AAA server are defined.

*) I still don't understand what intra-authenticator handovers are!
Please explain and give examples, i.e. when are CAP and SAP the same
entities (Section 5)?

*) I still don't think you should refer to a full EAP authentication as
"normal authentication" because it suggests that the other
authentications, including early ones, are not normal.  Please change
"normal authentication" throughout the document to "full (EAP)
authentication" and add the term to the definition section.

*) In definition section 2, it is assumed that <quote> an attachment
point must also support EAP authenticator functionality </quote>.
However, later in the same section it is distinguished between
"Candidate Attachment Point (CAP)" and "Candidate Authenticator". With
the first definition, such distinction seems redundant, no?

*) The direct pre-authentication model is the only one for which no
assumptions or conditions are listed. I suggest rewording the
description from Section 6.1.2 <quote> This pre-authentication model is
needed if the peer cannot discover the candidate authenticator's
identity or if direct IP communication between the MD and CAP is not
possible due to security or network topology issues. </quote> as
conditions for the direct pre-authentication model.


</General Comments>

<Old&new nits>

*) Section 3.2.1.1: remove round brackets in last sentence
*) Section 3.3.1: add a period after last sentence
*) Section 6.1.1: Figure 2 is not referenced
*) Section 6.1.2: add a period after the first sentence
*) ": remove the space before the period in the last sentence
*) Section 8: change "a early authentication" to "an early
authentication"
*) Section 8: "Early authentication entries", you say the procedure for
changing a peer's state from early to full authentication is not topic
of <quote> this particular subsection </quote>. Where in this document
is this procedure explained? Please reference.
*) Section 8: "Multiple candidate attachment points: add a period after
last sentence.
8) Section 9: change "a early authentication" to "an early
authentication"

</Old&new nits>

<
> -----Original Message-----
> From: hokey-bounces at ietf.org [mailto:hokey-bounces at ietf.org] On Behalf
Of
> Glen Zorn
> Sent: Wednesday, June 24, 2009 7:28 AM
> To: hokey at ietf.org
> Subject: [HOKEY] draft-ietf-hokey-preauth-ps-08.txt
> 
> Please review this
>
(http://www.ietf.org/internet-drafts/draft-ietf-hokey-preauth-ps-08.txt)
> ASAP.  I think that enough has changed to warrant another short review
> period; I _really_ hate multiple WGLCs, though, so let's call it a
"Last
> Look" & set the end for 13:00 GMT on Wednesday, 1 July.
> 
> 
> _______________________________________________
> HOKEY mailing list
> HOKEY at ietf.org
> https://www.ietf.org/mailman/listinfo/hokey