Re: [HOKEY] AD review of draft-ietf-hokey-arch-design

[Stephen Farrell <[e-mail]>]

Hi Glen,

Those all look fine and are changes that can IMO be made before
or after IETF LC. (Once we bottom out on handling the comment
from the other mail, then that'll tell me whether this should
go revised ID needed or to IETF LC.)

I'd keep the idnits-robot-annoying reference myself, but
whatever:-)

S.

On 10/29/2011 04:25 PM, Glen Zorn wrote:
> On 10/23/2011 11:52 PM, Stephen Farrell wrote:
>
> (pasted from the attachment)
>
>> not quite nits:
>>
>> - I realise that this document references lots of others that define
>> things, but a bit of ascii art at the start would have been helpful.
>> Its not obvious where e.g. the "ER server" might live from the
>> current text.
>
> Actually I removed the ASCII art that was there because I thought that
> it was way confusing.  I suppose that it can be put back.
>
>> - p16, I don't get 6.4 really - why is inter-technology the same as
>> intra-domain?
>
> I guess that in the case of hokey, it's because we never defined an
> authentication protocol for the inter-domain case (ERP is strictly for
> intra-domain re-authentication). So, for hokey, inter-technology _is_
> intra-domain.
>
>> nits:
>>
>> - p5, "For the purpose of this draft" is wrong. s/draft/memo/?
>
> OK.
>
>> - p5, "All three mechanisms..." This description is a bit confusing,
>> since there are many RFCs referenced.  I think it'd be improved if
>> you listed the three mechanisms as bullets.
>
> How's this:
>
>     All three early authentication mechanisms provide means to securely
>     establish authenticated keying material on a Candidate Access Point
>     (CAP) while still being connected to the Serving Access Point (SAP)
>     but vary in their respective system assumptions and communication
>     paths.
>
>> - p5, ER is used as an acronym - expand on 1st use as well as in
>> section 2 would be better
>
> OK
>
>> - p6, s/can be integrated/whether or not it can be integrated/?
>
> How's this:
>
>     However, it is currently unclear how
>     the necessary handover infrastructure can be deployed and
>     integrated into existing EAP infrastructures.
>
> Although I think that this is really a non-issue, as far as the IETF is
> concerned: every deployment will be different; as long as we don't
> inadvertently (or purposely, for that matter) outlaw a reasonable design
> I think that we're fine.
>
>> - p7 - cute that you reference 2119 anyway:-) I wonder if this is its
>> first informative reference?
>
> Maybe ;-).  I hate to miss a chance to annoy the idnits robot, but maybe
> just lose the reference?
>
>> - p7, What is a re-authenticaiton root key? (3.2) I see its defined
>> in 5296 but wouldn't it be ok to just say "required keys" here - do
>> you *need* to be so precise?
>
> I don't think so.
>
>> If so, then maybe add a ref to 5296 to
>> help point the reader to the right place?
>
>> - p8 - what is a "HOKEY server"?
>
> I think that it is generic term for a server supporting hand-over keying
> -- could be a ER server or an AAK server, for example.
>
>> should that be in the terminology
>> section?
>
> Since it seems to appear only once, maybe we could just try to rephrase
> the sentence?
>
>> - p8, 1st para of 4.1 just confuses me - is it needed really?  Maybe
>> you could lose that and just s/subsystem/subsystem provided by HOKEY/
>> in the next para and that'd be good enough?
>
> Works for me.
>
>> (If you do keep the
>> current text, I also wonder if the "This section" at the start refers
>> to setction 4 generally or 4.1 only? As-is its a little ambiguous
>> looking.)
>
>> - p9, end of page - Got any references to that work in progress?
>
> I think that that is RFC 5296bis, so yes.
>