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

[Stephen Farrell <[e-mail]>]

Ok, mail crossing in the ether:-) I'll put it on
the Dec 1 telechat.

Thanks,
S.

On 11/21/2011 01:01 PM, Stephen Farrell wrote:
>
> 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
>>
> _______________________________________________
> HOKEY mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hokey
>