Re: [HOKEY] Russ Housley's Discuss on draft-ietf-hokey-arch-design-10: (with DISCUSS)

[Tina TSOU <[e-mail]>]

Authors, the gen-art review from Richard Barnes seems reasonable.
You may consider to update a new version.

Tina as document shepherd,
Sent from my iPad

On Dec 29, 2011, at 4:53 AM, "Glen Zorn" <[e-mail]> wrote:

> Sorry for the delayed reply; I have been ill.  In any case, the gen-art
> review is reproduced below, with comments.
> 
> 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 wait for direction from your document shepherd
> or AD before posting a new version of the draft.
> 
>> Document:  draft-ietf-hokey-arch-design-03
>> Reviewer:  Richard Barnes
>> Review Date: 2011-11-23
>> IETF LC End Date:
>> IESG Telechat date: 2011-12-01
>> 
>> Summary:  Largely complete, but hard to use
>> 
>> Major issues:
>> 
>> The document seems to make several architectural assumptions that are
>> not clearly stated.  For example, both this document and the HOKEY
>> problem statement [RFC5169] make reference to "home" and "visited"
>> networks, terms which are defined in neither document.  It would be
>> helpful if this document could clarify some of these issues that are 
>> left vague by the problem statement.
> 
> The terms "home network" and "visited network" have been in common usage
> in the roaming community for at least 10 years.
> 
>> 
>> Likewise, the document states the architecture in terms of several "
>> functions" that are performed by "components".  For a reader
>> unfamiliar with the history of this document, it is not clear how
>> these functions work together to solve the problems laid out in RFC
>> 5169.
> 
> Since this document attempts to describe the entire hokey architecture
> of which re authentication and key management (the subjects of RFC 5169)
> are only portions (the other major component being early authentication,
> discussed in RFC 5836), I don't think that it is particularly surprising
> that there is not a one-to-one mapping.  That said, however, I find this
> comment quite amorphous, bordering upon "I don't understand", and not
> very useful.  Some specific, actionable suggestions would be much
> appreciated; note that 'add an (unspecified) reference" is not part of
> that set.
> 
>> 
>> The components are also given suggestive names, but not defined.  For
>> example, there are components named "serving authenticator" and
>> "candidate authenticator", whose names seem to imply that they play
>> particular roles in the protocol or occupy particular places in the
>> network.  But the document never explains this beyond the names.
> 
> "Candidate Authenticator" is defined in Section 2 of RFC 5836 (see
> below), which is referenced in Section 2 of the document under
> discussion.  I can add the following definition to Section 2 of the
> draft if necessary:
> 
>   Serving Authenticator (SA)
>      The EAP authenticator on the SAP [RFC5826].
> 
> 
> 
> Minor issues:
> 
> 
> Editorial nits:
> 
> Version -10 appears to have introduced the term "DSrRK", which appears
> nowhere else in the document.
> 
> "DSrRK" appears in Tables 4 and 5.