Fast Handovers for Proxy Mobile IPv6
draft-ietf-mipshop-pfmipv6-14

[Ballot discuss]
This is an updated DISCUSS position.

1) Sec 4: By adding new flags to the HI and Hack messages, aren't you updating RFC 5568 - and by that I mean shouldn't "Updates: 5568 (once approved)" be on the 1st page?

[Ballot comment]
1) Please spell out first instance of MAG.  It is not in the RFC Editor Abbreviations List.

2) Is it really mobility to mobile nodes?  Are mobile nodes already mobile by definition?  Or is this contrasting static nodes in the PMIPv6 domain? Suggest the following changes in abstract and intro: R/mobility for mobile nodes/mobility for nodes

3) Sec 2: r/Proxy Mobile IPv6 [RFC5213]/Proxy Mobile IPv6 (PMIPv6) [RFC5213]

4) Sec 4, 2nd para: Spell out 1st instance of PFMIPv6.

[Ballot discuss]
1) The last paragraph in section 1 says : "[RFC5568] should be" ...  Should the "should" be "SHOULD"? It certainly reads like a requirement.  Actually, why isn't this a MUST?

2) Sec 4: By adding new flags to the HI and Hack messages, aren't you updating RFC 5568 - and by that I mean shouldn't "Updates: 5568 (once approved)" be on the 1st page?

3) Sec 4: Says:

More specifically, the Router Solicitation for Proxy
Advertisement (RtSolPr), the Proxy Router Advertisement (PrRtAdv),
Fast Binding Update (FBU), Fast Binding Acknowledgment (FBack) and
the Unsolicited Neighbor Advertisement (UNA) messages are not
applicable in the PMIPv6 context.

Where is the behavior specified for when one of these is used.  Is there an error, are they discarded, or does a node fall over dead?

4) Sec 4.1: Depending on what the answer is to #1 and #2, (if you say it's not updating 5568) then I think there needs to be a MUST in the following:

It is hence required that all MAGs have the capability
and enough resources to buffer packets for the mobile nodes
accommodated by them.  The buffer size to be prepared and the rate at
which buffered packets are drained are addressed in Section 5.4 of
[RFC5568].

5) Sec 4.1:  Why isn't 2119 language used here (i.e., MUST instead of required)?  It certainly reads like a requirement:

Unlike MIPv6, the mobile node in the PMIPv6 domain is not involved
with IP mobility signaling; therefore, in order for the predictive
fast handover to work effectively, it is required that the mobile
node is capable of reporting lower-layer information to the AN at a
short enough interval, and the AN is capable of sending the Handover
indication to the PMAG at an appropriate timing.

6) Sec 4.1: Why isn't 2119 language used in steps e and f?

MAG may optionally request
packets may be buffered
packets may be forwarded

7) Sec 4.2: (if it's really a 2119 requirement) r/This specification recommends/It is RECOMMENDED that:

8) Sec 4.2: Should these be SHOULDs:

the NMAG
should immediately send them towards the N-AN; otherwise it should
buffer them until the mobile node is ready.

9) Sec 5.2: Should it be 2119 RECOMMENDED:

  Such an RA is recommended, for example,

[Note]: 'On the May 6th agenda to solicit one additional vote (Discusses cleared)
Vijay Devarapalli (vijay@wichorus.com) is the document shepherd.' added by Jari Arkko

[Ballot comment]
I think the document would be cleared if either acronyms or terms for elements like PMAG, NMAG, etc. were used uniformly throughout, rather than a mix of acronyms and terms.

I think there are still a few occurrences of "previous access router" and "new access router".  While there is text that explains PAR == PMAG and NAR == NMAG, the document would be clearer if PMAG and NMAG were used uniformly throughout.

Expand the acronym "CN" and/or define it in the terminology section.

[Ballot comment]
In figure 2, I would suggest adding two additional lines in step l to indicate that UL and DL
data now flow directly between the NMAG and LMA (i.e., that the PMAG is no longer included
the the traffic flow).  This is noted already in the text, but seems conspicuous by omission in
the figure.

[Ballot comment]
In figure 2, I would suggest adding two additional lines in step l to indicate that UL and DL
data now flow directly between the NMAG and LMA (i.e., that the PMAG is no longer included
the the traffic flow)

[Ballot discuss]
I have reviewed draft-ietf-mipshop-pfmipv6-10, and have one concerns
that I'd like to discuss before recommending approval of the document:

Although version -10 is a big improvement over -09, I think the text
about "MN IID" option still needs some clarification.  This option has
a very misleading name, and it's very specific to PPP (and would not
be useful on most link layers that don't use PPP).

A very rough first cut of the thing I think still need clarification:

- The option's name should probably be something like "MN Link-Local
Address IID", since for other addresses (global unicast) the MN might
use other IIDs.

- Section 6.2.3 needs an explanation about this option and its
use. Perhaps something like "In PPP, the interface identifier for the
MN's IPv6 link-local address can be assigned by the AN.  In
deployments that use this configuration, this option is used to
transfer this identifier from P-AN to N-AN."  (And change the
description to "The Interface Identifier used for MN's IPv6 link-local
address in the P-AN".)

- In Section 4.1, step (c) should say something like "With some link
layers, thte MN Link-Local Address IID can also be included (see
Section 6.2.3)".

- In Section 4.1, step (h), suggest rephrasing: "..., the NMAG SHOULD
confirm that the same interface identifier is used for the MN's
link-local address (this is transferred from PMAG using the MN-LLA-IID
option at step (c), and sent to the MN during the
Configure-Request/Ack exchange)"

- In Section 4.1, rephrase the text that talks about neighbor cache
entries (below the itemized list) -- at this point, the MAG can create
a neighbor cache entry for the Link-Local address, and just add
"routes" (or similar) for the whole HNP (since this is a
point-to-point link, and MN owns the whole HNP, it's not necessary to
create individual neighbor cache entries for every address (from HNP)
that the MN uses -- that could be hundreds of entries per MN.

[Ballot comment]
4.  Proxy-based FMIPv6 Protocol Overview

  This flag MUST be set in the entire document.

Do you mean that this flag needs to be set in any message specified in this document?


6.2.7.  IPv4 Address Option

  As described in Section 4.3, if the MN runs in IPv4-only mode or
  dual-stack mode, it requires IPv4 home address (IPv4-MN-HoA).  This
  option is used to transfer the IPv4 home address if assigned on the
  previous link.  The format of this option follows the IPv4 Home
  Address Request Option defined in [IPv4PMIPv6].

Does this need a new allocation from IANA?

[Ballot comment]
The requirements for functions in the MN and the access network to support "predictive handover" should be stated.

How is predictive handover better than reactive handover?  It seems both require traffic buffering, either at the NAR (predictive) or the PAR (reactive).

[Ballot discuss]
Updated for draft-ietf-mipshop-pfmipv6-09.txt; as far as I can tell, few, if any, of my DISCUSS points have been addressed in the -09 rev.

-----

I'm not at all sure I could implement an interoperable protocol from this document.  The only description of message transmission and processing is in Section 4.  There appear to be only general descriptions of message flows and operations in section 4.  Is this document defining extensions to RFC 5568?  If so, there should be an explicit description of what is the same and what is updated.

This document introduces a formal definition for "access network", spec., P-AN and N-AN, that doesn't seem to appear in RFC 5213.  There are references to an "access network" in RFC 5213, but those references seem to imply a passive link; in this document, the P-AN and N-AN include L2 devices that apparently can send and receive messages as shown, e.g., in figure 2.

Is there some other document in which the access nodes are given this more active definition?  Access nodes don't appear in RFC 5568, either.

Related: this sentence seems like a handwave:

  (b)  The previous access network (P-AN), to which the MN is currently
        attached, indicates the handover of the MN to the PAR (PMAG).
        Detailed definition and specification of this message are
        outside the scope of this document.

Why is the AN involved at all?  RFC 5213 assigns all of this detection responsibility directly to the MAG.

=====
How does the PAR know the NAR in predictive handover? (4.1)

  (c)  The PAR sends the HI to the NAR.  The HI message MUST have the P
        flag set and include the MN ID, the HNP, the MN IID and the
        address of the LMA that is currently serving the MN.
=====
In reactive handover, if the MN does nor provide the old AP-ID to the NAR, how does the NAR determine the PAR?

  (a)  The MN undergoes handover from the P-AN to the N-AN.  The AP-ID
        on the old link may be provided by the MN to help identify the
        PMAG on the new link.

BTW, even though PAR/PMAG and NAR/NMAG are interchangeable throughout the doc, it would be good to choose one and stick with.

There seems to be an unstated assumption that AP-IDs can be mapped to access routers.

[Ballot comment]
The requirements for functions in the MN and the access network to support "predictive handover" should be stated.

How is predictive handover better than reactive handover?  It seems both require traffic buffering, either at the NAR (predictive) or the PAR (reactive).

[Ballot discuss]
I'm not at all aure I could implement an interoperable protocol from this document.  The only description of message transmission and processing is in Section 4.  There appear to be only general descriptions of message flows and operations in section 4.  Is this document defining extensions to RFC 5568?  If so, there should be an explicit description of what is the same and what is updated.

This document introduces a formal definition for "access network", spec., P-AN and N-AN, that doesn't seem to appear in RFC 5213.  There are references to an "access network" in RFC 5213, but those references seem to imply a passive link; in this document, the P-AN and N-AN include L2 devices that apparently can send and receive messages as shown, e.g., in figure 2.

Is there some other document in which the access nodes are given this more active definition?  Access nodes don't appear in RFC 5568, either.

Related: this sentence seems like a handwave:

  (b)  The previous access network (P-AN), to which the MN is currently
        attached, indicates the handover of the MN to the PAR (PMAG).
        Detailed definition and specification of this message are
        outside the scope of this document.

Why is the AN involved at all?  RFC 5213 assigns all of this detection responsibility directly to the MAG.

=====
How does the PAR know the NAR in predictive handover? (4.1)

  (c)  The PAR sends the HI to the NAR.  The HI message MUST have the P
        flag set and include the MN ID, the HNP, the MN IID and the
        address of the LMA that is currently serving the MN.
=====
In reactive handover, if the MN does nor provide the old AP-ID to the NAR, how does the NAR determine the PAR?

  (a)  The MN undergoes handover from the P-AN to the N-AN.  The AP-ID
        on the old link may be provided by the MN to help identify the
        PMAG on the new link.

BTW, even though PAR/PMAG and NAR/NMAG are interchangeable throughout the doc, it would be good to choose one and stick with.

There seems to be an unstated assumption that AP-IDs can be mapped to access routers.

[Ballot discuss]
In the Gen-ART Review by Francis Dupont on 2009-09-22, Francis said:

  "incredible painful to read (obviously a candidate for "how an RFC
  should not be" :-)."

  A revised draft was produced in response to this comment; however, it
  has not been posted yet.  What is the plan?

[Ballot discuss]
Section 4.1., paragraph 1:
>    It is hence required that all MAGs have the capability
>    and enough resources to buffer packets for the MNs accommodated by
>    them.

  DISCUSS: How large is this buffer and at what rate is it being drained
  after the tunnel is up? Sending large amounts of data at line-rate
  between the PMAG and NMAG may overload the NMAG.


Section 4.1., paragraph 42:
>    The encapsulation type for these user packets SHOULD follow that used
>    in the tunnel between the LMA and MAG (IPv6-in-IPv6 as specified in
>    [RFC2473], IPv6-in-IPv4, IPv6-in-IPv4-UDP as specified in
>    [IPv4PMIPv6], TLV-header UDP tunneling as specified in [GREKEY] or
>    any new method defined in the future).

  DISCUSS: [IPv4PMIPv6] and [GREKEY] need to be normative references. I
  also don't think that we can simply allow any possible future
  tunneling mechanism here. IMO this should become a "MUST follow either
  X, Y or Z". Finally, since there are multiple options here, how does
  one MAG know which scheme the other one is expecting/using?
  Configuration?

[Ballot discuss]
I have reviewed draft-ietf-mipshop-pfmipv6-09, and have couple of
questions/concerns that I'd like to discuss before recommending
approval of the document:

1) In several places, the document talks of "the interface identifier
of the MN".  Does this refer to the lower 64 bits of some IPv6 address
used by the MN (and if so, which? the MN could be using any number of
addresses from its HNP), or perhaps to the MAG's identifier for the
MN-MAG point-to-point link (if-id; Section 6.1 of RFC 5213)?  (But as
far as I can tell, the latter isn't necessarily 64 bits, and isn't
required to be unique between MAGs; it could be e.g. MIB ifIndex).

2) The document talks about "the HNP" -- but in PMIPv6, a MN can have
several HNPs?

3) The draft has a normative downward reference that wasn't called out
in IETF Last Call. However, to me it looks like RFC4988 could be
moved to an informative reference.

4) The references IPv4PMIPv6 and GREKEY look normative to me.

5) The document should probably say something about how
EnableMAGLocalRouting and the PAR<->NAR tunnel interact.  In
particular, when local routing is not used, does the PAR use the
PAR<->NAR tunnel only for packets received from the LMA? (but
packets received from directly connected CNs are not sent via
this tunnel)

[Ballot comment]
4.  Proxy-based FMIPv6 Protocol Overview

  A new flag 'P' is defined for the HI and
  HAck messages to distinguish from those in [RFC5568].

Does this need registering with IANA?

  This flag MUST be set in the entire document.

Do you mean that this flag needs to be set in any message specified in this document?


6.2.7.  IPv4 Address Option

  As described in Section 4.3, if the MN runs in IPv4-only mode or
  dual-stack mode, it requires IPv4 home address (IPv4-MN-HoA).  This
  option is used to transfer the IPv4 home address if assigned on the
  previous link.  The format of this option follows the IPv4 Home
  Address Request Option defined in [IPv4PMIPv6].

Does this need a new allocation from IANA?

6.1.2.  Handover Acknowledge (HAck)

  Code
              Code values 0 through 4 and 128 through 130 are defined
              in [RFC5568].  In this specification, the meaning of Code
              value 0 is modified, 128 through 130 are reused, and 5,
              6, 131 and 132 are newly defined.

                      0: Handover Accepted or Successful

                      5: Context Transfer Accepted or Successful

                      6: All available Context Transferred

                      128: Handover Not Accepted, reason unspecified

                      129: Administratively prohibited

                      130: Insufficient resources

                      131: Requested Context Not Available

                      132: Forwarding Not Available

It would have been better if this was an IANA registry.


6.2.1.  Context Request Option

  This option is sent in the HI message to request context information
  on the MN.  If a default set of context information is defined and
  always sufficient, this option is not mandatory.

Can you please elaborate on what exactly this means?

  This option is more
  useful to retrieve additional or dynamically selected context
  information.

6.2.1.  Context Request Option

      0                  1                  2                  3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +---------------+---------------+---------------+---------------+
    |  Option-Type  | Option-Length |          Reserved            |
    +---------------+---------------+-------------------------------+
    |  Req-type-1  | Req-length-1  |  Req-type-2  | Req-length-2  |
    +---------------------------------------------------------------+

This doesn't show any optional data following any Req-length-i.
This caused me some confusion during my review.

6.2.8.  Vendor-Specific Mobility Option

  This option is used to transfer any other information defined in this
  document.  The format of this option follows the Vendor-Specific
  Mobility Option defined in [RFC5094].  The exact values in the Vendor
  ID, Sub-Type and Data fields are outside the scope of this document.

I think it would be more correct to say that Vendor IDs are values are as specified in [RFC5094].

[Ballot discuss]
1). 4.3.  IPv4 Support Considerations

  As for IPv4 Home Address Mobility Support, the MN acquires IPv4 Home
  Address (IPv4-MN-HoA) and in the case of handover, the PMAG needs to
  transfer IPv4-MN-HoA to the NMAG, which is the inner destination
  address of the packets forwarded on the downlink.  For this purpose,
  a new option called IPv4 Address Option is defined in this document.

This seems to suggest that the document is registering a new option with IANA, but section 6.2.7 says:

  As described in Section 4.3, if the MN runs in IPv4-only mode or
  dual-stack mode, it requires IPv4 home address (IPv4-MN-HoA).  This
  option is used to transfer the IPv4 home address if assigned on the
  previous link.  The format of this option follows the IPv4 Home
  Address Request Option defined in [IPv4PMIPv6].

So is this a new option, or is this a reuse of existing option?

[Ballot comment]
6.2.1.  Context Request Option

  This option is sent in the HI message to request context information
  on the MN.  If a default set of context information is defined and
  always sufficient, this option is not mandatory.

Can you please elaborate on what exactly this means?

  This option is more
  useful to retrieve additional or dynamically selected context
  information.

[Ballot discuss]
This document introduces a formal definition for "access network", spec., P-AN and N-AN, that doesn't seem to appear in RFC 5213.  There are references to an "access network" in RFC 5213, but those references seem to imply a passive link; in this document, the P-AN and N-AN include L2 devices that apparently can send and receive messages as shown, e.g., in figure 2.

Is there some other document in which the access nodes are given this more active definition?

Related: this sentence seems like a handwave:

  (b)  The previous access network (P-AN), to which the MN is currently
        attached, indicates the handover of the MN to the PAR (PMAG).
        Detailed definition and specification of this message are
        outside the scope of this document.

Why is the AN involved at all?  RFC 5213 assigns all of this detection responsibility directly to the MAG.

=====

requirement is "no changes to MN"; yet a key part of the protocol is:

  (a)  The MN detects that a handover is imminent and reports the
        identifications of itself (MN ID) and the New Access Point
        Identifier (New AP ID) [RFC5568] to which the MN is most likely
        to move.

how does this happen without changes to the MN? (4.1)
=====
How does the PMAG know the NMAG? (4.1)

  (c)  The PAR sends the HI to the NAR.  The HI message MUST have the P
        flag set and include the MN ID, the HNP, the MN IID and the
        address of the LMA that is currently serving the MN.
=====

=====

IANA comments:

QUESTIONS:

- Do you need to register the new 'F' flag?

- Do you want to register the Handover Acknowledge Codes?

Upon approval of this document, IANA will make the following
assignments in the "Mobility Options" registry at
http://www.iana.org/assignments/mobility-parameters/mobility-parameters.xhtml

Value Description Reference
----- ------------------------------------- -------------
TBD1 Context Request Option [RFC-mipshop-pfmipv6-09]
TBD2 Local Mobility Anchor Address Option [RFC-mipshop-pfmipv6-09]
TBD3 Mobile Node Interface Identifier Option [RFC-mipshop-pfmipv6-09]

We understand the above to be the only IANA Action for this document.

I have reviewed this document. It was generally in good shape and easy to read. I did find a number of issues though. Please discuss them with me on this thread and/or revise the draft accordingly.

Technical:

I do not understand the IP host aspects of the handover. For an unmodified host, what kind of interfaces exist on the host, what addresses they have, and at what time are interfaces removed or added? Is this exactly the same as in RFC 5213, or does PFMIPv6 introduce some change here?

I would like to see a new section on manageability considerations. For instance, Section 5 talks about some configuration issues. These should be mentioned, and there should be a description of what the operator needs to configure in order to set up a PFMIPv6 network.

> If the new router's interface is configured to
> respond to queries sent to link-layer addresses than its own (e.g.,
> set to promiscuous mode), then it can respond to the NUD probe,
> providing its link-layer address in the solicited Neighbor
> Advertisement.

Is this according to RFC 5213? I seem to recall that RFC 5213 operated on the same link layer addresses.

> At least one mobility option MUST
> uniquely identify the target MN (e.g., the Mobile Node Identifier
> Option defined in RFC4283) and the transferred context MUST be for
> one MN per message.

I would like the required options to be specified in more detail. Which identity options are sufficient to satisfy the MUST?

> If a default set of context information is defined and
> always sufficient, this option is not mandatory.  This option is more
> useful to retrieve additional or dynamically selected context
> information.
>
> Context Request Option is typically used for the reactive (NAR-
> initiated) fast handover mode to retrieve the context information
> from the PAR.  When this option is included in the HI message, all
> the requested context information SHOULD be included in the HAck
> message in the corresponding mobility option(s) (e.g., HNP, LMAA or
> MN-IID mobility options).

Please specify what the default set of context information is, by listing the required options when the CRO is not present.

Editorial:

>    HO-Initiate:
>        A generic signaling message, sent from the P-AN to the PMAG that
>        indicates a MN handover.  While this signaling is dependent on
>        the access technology, it is assumed that HO-Initiate can carry
>        the information to identify the MN and to assist the PMAG
>        resolve the NMAG and the new access point or the base station to
>        which the MN is moving to.  The details of this message are
>        outside the scope of this document.
>
> 4. Proxy-based FMIPv6 Protocol Overview

Section 4 would probably benefit from an additional paragraph at the beginning to explain what assumptions there exist about lower layer functionality.

> A new flag 'P' is defined for the HI and
> HAck messages to distinguish from those in [RFC5268bis] and thus MUST
> be set in the entire document.

This would be more readable as " ... those in [RFC5268bis]. This flag MUST be ..."

>    and the NAR creates a proxy NCE to receive those packets for the NCoA

The term NCE has not been introduced at this stage yet.

>    address that is used by the MN is MN-HoA.  Hence the PAR forwards

The term MN-HOA has not been introduced before.


>        The access network to which the MN is attached after handover.

New term MN, not introduced before.


> specifies forwarding when the MN uses HoA as its on-link address

New term HoA...

>    as MN's NAI, Home Network Prefix (HNP), IPv4 Home Address, are

New term NAI...

>        flag set and include the MN ID, the MN-HNP, the MN-IID and the

New terms MN-HNP and MN-IID (or at least they do not appear in their MN-XXX form before this point).

>        Inner destination address: HNP or IPv4-MN-HoA

IPv4-MN-HoA not defined earlier...


>    between the PCoA and NCoA to forward packets for the MN to the NAR,
New terms PCoA and NCoA... there's probably more undefined terms in the document, please check!

>    In (i),
In Step (i),

>          |(MN ID, Old AP ID) |    (MN ID, Old AP ID)    |        |

Old AP ID? AN ID? AR ID?

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Vijay Devarapalli is the Document Shepherd for this document. I
have reviewed the document and it is ready for forwarding to the
IESG for publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

This document has had adequate reviews from the members in the MIPSHOP
WG. I have no concerns about the depth or breadth of the reviews that
have been performed.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization, or XML?

None.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

No specific concerns.

(1.e) 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?

There is WG consensus in advancing this document.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/.) Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type, and URI type reviews? If the document
does not already indicate its intended status at the top of
the first page, please indicate the intended status here.

The document seems to be missing the disclaimer for pre-RFC5378 work.
I expect this to be fixed in the next revision. No other nits were
found.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

The document splits the references into normative and informative
references. There is one downward reference to
draft-ietf-mipshop-rfc5268bis-01.txt, but that document is already
with the IESG.

(1.i) Has the Document Shepherd verified that the document's IANA
Considerations section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC2434]. If the
document describes an Expert Review process, has the Document
Shepherd conferred with the Responsible Area Director so that
the IESG can appoint the needed Expert during IESG Evaluation?

The IANA considerations section exists and is consistent with
the body of the document. The document requests reservations in
the appropriate IANA registries. The IANA registries that need to
be modified/created are clearly identified.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

Does not apply.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up. Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.

The document describes a mechanism to provide fast handovers when
Proxy Mobile IPv6 is used as the mobility management protocol. It
also describes a mechanism to transfer context between two MAGs
to assist in the handover. The mobile node is not involved in any
Signaling for the fast handovers to work.

Working Group Summary
Was there anything in the WG process that is worth noting?
For example, was there controversy about particular points
or were there decisions where the consensus was
particularly rough?

None.

Document Quality
Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to
implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If
there was a MIB Doctor, Media Type, or other Expert Review,
what was its course (briefly)? In the case of a Media Type
Review, on what date was the request posted?

There are no known implementations of the specification. It is likely
to be implemented by some vendors, since this document is required for
fast handovers in 3GPP2 eHPRD network.

Personnel
Who is the Document Shepherd for this document? Who is the
Responsible Area Director? If the document requires IANA
experts(s), insert 'The IANA Expert(s) for the registries
in this document are .'

Document shepherd: Vijay Devarapalli
Responsible AD: Jari Arkko/Ralph Droms