Re: [HOKEY] Last Call: <draft-ietf-hokey-arch-design-08.txt> (Handover Keying (HOKEY) Architecture Design) to Informational RFC

[Stephen Farrell <[e-mail]>]

ping: I'm waiting on a confirmation from you...

If you get that to me before tomorrow I can put
it on the Dec 1 telechat. Or it can go on the
Dec 15 one if not.

S.

On 11/17/2011 12:01 AM, Stephen Farrell wrote:
>
> Folks,
>
> IETF last call on this is done. Were there any changes
> resulting? I didn't see any.
>
> Are there any further changes to be made? I can't
> recall any but this was a last-minute-before-the-
> cutoff submission so there might be.
>
> There was also a secdir review [1] with a nit. Fix that
> or not as you choose.
>
> Once you confirm no more changes are needed to me I'll
> put it on a telechat agenda,
>
> Thanks,
> S.
>
> [1] http://www.ietf.org/mail-archive/web/secdir/current/msg02976.html
>
> On 11/02/2011 03:56 PM, The IESG wrote:
>>
>> The IESG has received a request from the Handover Keying WG (hokey) to
>> consider the following document:
>> - 'Handover Keying (HOKEY) Architecture Design'
>> <draft-ietf-hokey-arch-design-08.txt> as an Informational RFC
>>
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final comments on this action. Please send substantive comments to the
>> [e-mail] mailing lists by 2011-11-16. Exceptionally, comments may be
>> sent to [e-mail] instead. In either case, please retain the
>> beginning of the Subject line to allow automated sorting.
>>
>> Abstract
>>
>>
>> The Handover Keying (HOKEY) Working Group seeks to minimize handover
>> delay due to authentication when a peer moves from one point of
>> attachment to another. Work has progressed on two different
>> approaches to reduce handover delay: early authentication (so that
>> authentication does not need to be performed during handover), and
>> reuse of cryptographic material generated during an initial
>> authentication to save time during re-authentication. A basic
>> assumption is that the mobile host or "peer" is initially
>> authenticated using the Extensible Authentication Protocol (EAP),
>> executed between the peer and an EAP server as defined in RFC 3748.
>>
>> This document defines the HOKEY architecture. Specifically, it
>> describes design objectives, the functional environment within which
>> handover keying operates, the functions to be performed by the HOKEY
>> architecture itself, and the assignment of those functions to
>> architectural components. It goes on to illustrate the operation of
>> the architecture within various deployment scenarios that are
>> described more fully in other documents produced by the HOKEY Working
>> Group.
>>
>>
>>
>>
>> The file can be obtained via
>> http://datatracker.ietf.org/doc/draft-ietf-hokey-arch-design/
>>
>> IESG discussion can be tracked via
>> http://datatracker.ietf.org/doc/draft-ietf-hokey-arch-design/
>>
>>
>> No IPR declarations have been submitted directly on this I-D.
>>
>>
>> _______________________________________________
>> HOKEY mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/hokey
>>
> _______________________________________________
> HOKEY mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hokey
>