FW: request to publish draft-ietf-mobike-protocol-06.txt

FYI

> Russ,
>
> The following I-D has completed WG LC. This is a standards
> track I-D. We would like you to now take it forward.
>
> Title: IKEv2 Mobility and Multihoming Protocol (MOBIKE)
> I-D: draft-ietf-mobike-protocol-06.txt
>
>
> 1) Have the chairs personally reviewed this version of the ID and do
>   they believe this ID is sufficiently baked to forward to the IESG
>   for publication?
> Yes. The I-D is ready for IESG review and publication.
>
>
> 2) Has the document had adequate review from both key WG members and
>   key non-WG members? Do you have any concerns about the depth or
>   breadth of the reviews that have been performed?
>
> The specification and its design choices have been discussed on
> several IETF meetings. The WGLC process resulted in an extensive
> discussion and numerous in-depth reviews. Some of the reviews
> were received from outside the WG, including reviews from designers
> of other multihoming/mobility mechanisms and a review from the
> mobility directorate.
>
>
> 3) Do you have concerns that the document needs more review from a
>   particular (broader) perspective (e.g., security, operational
>   complexity, someone familiar with AAA, etc.)?
> There are no such concerns.
>
>
> 4) Do you have any specific concerns/issues with this document that
>   you believe the ADs and/or IESG should be aware of? For example,
>   perhaps you are uncomfortable with certain parts of the document,
>   or whether there really is a need for it, etc., but at the same
>   time these issues have been discussed in the WG and the WG has
>   indicated it wishes to advance the document anyway.
>
> There are no such concerns.
>
>
> 5) How solid is the WG consensus behind this document?  Does it
>   represent the strong concurrence of a few individuals, with others
>   being silent, or does the WG as a whole understand and agree with
>   it?
>
> The consensus is solid, at least among those people who
> have participated the discussion.
>
> There has been a small number of issues where the consensus was
> not unanimous, but most of the WG supported the chosen approach
> in those cases. These cases were typically related to functionality
> that we chose not to include in the MOBIKE base protocol but
> could potentially do it later as an extension.
>
>
> 6) Has anyone threatened an appeal or otherwise indicated extreme
>   discontent?  If so, please summarize what are they upset about.
>
> No.
>
>  
> 7) Have the chairs verified that the document adheres to _all_ of the
>   ID nits?  (see http://www.ietf.org/ID-nits.html).
>
> Yes.
>
>   8) Does the document a) split references into normative/informative,
>   and b) are there normative references to IDs, where the IDs are not
>   also ready for advancement or are otherwise in an unclear state?
>   (Note: the RFC editor will not publish an RFC with normative
>   references to IDs, it will delay publication until all such IDs are
>   also ready for publication as RFCs.)
>
> The references are formulated correctly. There are two unpublished
> normative references, RFC2401bis and IKEv2, both of which are
> already in the RFC Editor's queue.
>
>
> 9) For Standards Track and BCP documents, the IESG approval
>   announcement includes a writeup section with the following
>   sections:
>
>   - Technical Summary
>
>   This specification describes MOBIKE, a mobility and multihoming
>   extension to Internet Key Exchange (IKEv2). This protocol
>   allows hosts to update the IP addresses associated with IKEv2
>   and tunnel mode IPsec Security Associations.  A mobile VPN client
>   could use MOBIKE to keep the connection with the VPN gateway active
>   while moving from one address to another.  Similarly, a multihomed
>   host could use MOBIKE to move the traffic to a different interface
>   if, for instance, the one currently being used stops working.
>
>   - Working Group Summary
>
>   The document has been presented at several IETF WG meetings and
>   been discussed extensively on the mailing list as well. The
>   document has been reviewed by a number of experts from different
>   areas. The working group last call resulted in a fairly large
>   number of issues, but only few (maybe just one) affects the
>   on-the-wire protocol. All issues have been addressed in
>   the current version of the I-D. There is consensus in the WG
>   to publish this I-D as a proposed standard.
>
>   - Protocol Quality
>
>   The basic MOBIKE idea is very simple. The hardest parts
>   of the protocol involve its co-existence with NAT-Traversal
>   capabilities of IKEv2, and the use of the IKEv2 communication
>   channel for dynamically changing messages and addresses.
>   Additionally, MOBIKE is only a part of a stack which
>   includes reliance also on other parts. For instance,
>   it is the IP layer, not MOBIKE, that detects when this
>   node has a new IP address.
>
>   Contributors and reviewers have included experts
>   in IPsec, mobility, NAT traversal, IKEv2 implementation,
>   and other aspects. The chairs are happy with the level
>   of WG participation and review that the specification has
>   received.
>
>   All issues during design and protocol specification time
>   have been tracked on a tracker at the WG page. This
>   specification was a part of the early RFC Editor copy
>   editing experiment, and has already gone through basic
>   editing phase prior to WGLC. Specification is in XML2RFC
>   format.
>
>   No known implementations exist at this time. MOBIKE
>   is currently being referenced from one other IETF WG and
>   one external SDO.
>
>
>