Skip to main content

Transient Binding for Proxy Mobile IPv6
draft-ietf-mipshop-transient-bce-pmipv6-07

Revision differences

Document history

Date Rev. By Action
2012-08-22
07 (System) post-migration administrative database adjustment to the No Objection position for Sean Turner
2012-08-22
07 (System) post-migration administrative database adjustment to the No Objection position for Adrian Farrel
2011-02-25
07 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2011-02-24
07 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2011-02-24
07 (System) IANA Action state changed to In Progress from RFC-Ed-Ack
2011-02-23
07 Cindy Morgan State changed to RFC Ed Queue from Approved-announcement sent.
2011-02-22
07 Amy Vezza IESG state changed to Approved-announcement sent
2011-02-22
07 Amy Vezza IESG has approved the document
2011-02-22
07 Amy Vezza Closed "Approve" ballot
2011-02-17
07 Cindy Morgan Removed from agenda for telechat
2011-02-17
07 Cindy Morgan State changed to Approved-announcement to be sent from IESG Evaluation.
2011-02-17
07 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded
2011-02-17
07 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded
2011-02-16
07 Peter Saint-Andre [Ballot Position Update] New position, No Objection, has been recorded
2011-02-15
07 Russ Housley [Ballot comment]
Do either of the IPR statements related to this document cause pause?
2011-02-15
07 Russ Housley Created "Approve" ballot
2011-02-08
07 Jari Arkko State changed to IESG Evaluation from Waiting for AD Go-Ahead.
2011-02-08
07 Jari Arkko Placed on agenda for telechat - 2011-02-17
2011-01-24
07 (System) State changed to Waiting for AD Go-Ahead from In Last Call.
2011-01-10
07 Amy Vezza Last call sent
2011-01-10
07 Amy Vezza
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: …
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Transient Binding for Proxy Mobile IPv6) to Experimental RFC


The IESG has received a request from the Mobility for IP: Performance,
Signaling and Handoff Optimization WG (mipshop) to consider the following
document:
- 'Transient Binding for Proxy Mobile IPv6'
  as an Experimental 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
ietf@ietf.org mailing lists by 2011-01-24. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

This draft is being re-last called due to new IPR information. Information
about the IPR can be found from:
https://datatracker.ietf.org/ipr/search/?option=document_search&id_document_tag=17935

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mipshop-transient-bce-pmipv6/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mipshop-transient-bce-pmipv6/
2011-01-10
07 Amy Vezza Last Call text changed
2011-01-09
07 Jari Arkko Last Call was requested
2011-01-09
07 Jari Arkko State changed to Last Call Requested from AD Evaluation.
2011-01-09
07 Jari Arkko Last Call text changed
2011-01-09
07 Jari Arkko Last Call text changed
2011-01-09
07 Jari Arkko State changed to AD Evaluation from RFC Ed Queue.
Have to go back to WGLC because a new IPR disclosure was filed.
2010-11-23
(System) Posted related IPR disclosure: Qualcomm Incorporated's Statement about IPR related to draft-ietf-mipshop-transient-bce-pmipv6-07
2010-09-13
07 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2010-09-13
07 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2010-09-13
07 (System) IANA Action state changed to In Progress from Waiting on Authors
2010-09-13
07 (System) IANA Action state changed to Waiting on Authors from In Progress
2010-09-13
07 Amy Vezza State changed to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2010-09-13
07 (System) IANA Action state changed to In Progress
2010-09-13
07 Amy Vezza IESG state changed to Approved-announcement sent
2010-09-13
07 Amy Vezza IESG has approved the document
2010-09-13
07 Amy Vezza Closed "Approve" ballot
2010-09-08
07 (System) New version available: draft-ietf-mipshop-transient-bce-pmipv6-07.txt
2010-09-08
07 Jari Arkko State Changes to Approved-announcement to be sent from IESG Evaluation::External Party by Jari Arkko
2010-09-08
07 Sean Turner [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss by Sean Turner
2010-09-07
07 Jari Arkko State Changes to IESG Evaluation::External Party from IESG Evaluation::AD Followup by Jari Arkko
2010-09-07
07 Jari Arkko
RFC Editor note updated.

Waiting for Sean to clear his discuss and the authors to tell me if
there is something else that they want …
RFC Editor note updated.

Waiting for Sean to clear his discuss and the authors to tell me if
there is something else that they want to change before the document
is approved.
2010-09-01
07 Cindy Morgan State changed to IESG Evaluation::AD Followup from Waiting for AD Go-Ahead::AD Followup by Cindy Morgan
2010-08-26
07 Cindy Morgan State changed to Waiting for AD Go-Ahead::AD Followup from Waiting for AD Go-Ahead by Cindy Morgan
2010-08-26
07 Tim Polk [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk
2010-08-26
07 Sean Turner [Ballot discuss]
The security considerations section needs to indicate whether there are any new security considerations introduced in addition to those in RFC 5213.
2010-08-26
07 Sean Turner [Ballot Position Update] New position, Discuss, has been recorded by Sean Turner
2010-08-26
07 Adrian Farrel [Ballot Position Update] Position for Adrian Farrel has been changed to No Objection from Discuss by Adrian Farrel
2010-08-26
07 Adrian Farrel [Ballot comment]
Clearing my Discuss on the basis of Jari's answer:
"That's a good question to ask. The answer is yes."
2010-08-26
07 Adrian Farrel
[Ballot discuss]
This is a Discuss-Discuss (i.e., no action is required by the authors). It is a point I want to make sure the IESG …
[Ballot discuss]
This is a Discuss-Discuss (i.e., no action is required by the authors). It is a point I want to make sure the IESG is aware of for discussion on the telechat if necessary.

This I-D is Experimental. It requests IANA to allocate some code points from registries that are marked as "Standards Action or IESG Approval"

Obviously, "Standards Action" does not apply to this Experimental I-D.

RFC 5226 is quite wordy wrt to "IESG Approval" saying:

      IESG Approval - New assignments may be approved by the IESG.
            Although there is no requirement that the request be
            documented in an RFC, the IESG has discretion to request
            documents or other supporting materials on a case-by-case
            basis.

            IESG Approval is not intended to be used often or as a
            "common case"; indeed, it has seldom been used in practice
            during the period RFC 2434 was in effect.  Rather, it is
            intended to be available in conjunction with other policies
            as a fall-back mechanism in the case where one of the other
            allowable approval mechanisms cannot be employed in a timely
            fashion or for some other compelling reason.  IESG Approval
            is not intended to circumvent the public review processes
            implied by other policies that could have been employed for
            a particular assignment.  IESG Approval would be
            appropriate, however, in cases where expediency is desired
            and there is strong consensus for making the assignment
            (e.g., WG consensus).

            The following guidelines are suggested for any evaluation
            under IESG Approval:

            - The IESG can (and should) reject a request if another path
              for registration is available that is more appropriate and
              there is no compelling reason to use that path.

            - Before approving a request, the community should be
              consulted, via a "call for comments" that provides as much
              information as is reasonably possible about the request.

            Examples: IPv4 Multicast address assignments [RFC3171], IPv4
            IGMP Type and Code values [RFC3228], Mobile IPv6 Mobility
            Header Type and Option values [RFC3775].

I wanted to check with the responsible AD that this I-D falls into this category.
2010-08-26
07 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2010-08-26
07 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded by Robert Sparks
2010-08-26
07 Alexey Melnikov
[Ballot comment]
6.  IANA Considerations

  This specification also adds one status code value to the Proxy
  Binding Acknowledge message, the
  PBU_ACCEPTED_TB_IGNORED_SETTINGSMISMATCH status …
[Ballot comment]
6.  IANA Considerations

  This specification also adds one status code value to the Proxy
  Binding Acknowledge message, the
  PBU_ACCEPTED_TB_IGNORED_SETTINGSMISMATCH status code.  The
  PBU_ACCEPTED_TB_IGNORED_SETTINGSMISMATCH status code is described in
  Section 4.7.  Its value must be assigned from the same number space
  used for the Mobile IPv6 Binding Acknowledgement status values, as
  defined in [RFC3775], and must be smaller 128.

I am looking at  and I am not finding "Binding Acknowledgement status" sub-registry. Am I looking in a wrong place, or is it named differently?
2010-08-26
07 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded by Alexey Melnikov
2010-08-26
07 Adrian Farrel
[Ballot discuss]
This is a Discuss-Discuss (i.e., no action is required by the authors). It is a point I want to make sure the IESG …
[Ballot discuss]
This is a Discuss-Discuss (i.e., no action is required by the authors). It is a point I want to make sure the IESG is aware of for discussion on the telechat if necessary.

This I-D is Experimental. It requests IANA to allocate some code points from registries that are marked as "Standards Action or IESG Approval"

Obviously, "Standards Action" does not apply to this Experimental I-D.

RFC 5226 is quite wordy wrt to "IESG Approval" saying:

      IESG Approval - New assignments may be approved by the IESG.
            Although there is no requirement that the request be
            documented in an RFC, the IESG has discretion to request
            documents or other supporting materials on a case-by-case
            basis.

            IESG Approval is not intended to be used often or as a
            "common case"; indeed, it has seldom been used in practice
            during the period RFC 2434 was in effect.  Rather, it is
            intended to be available in conjunction with other policies
            as a fall-back mechanism in the case where one of the other
            allowable approval mechanisms cannot be employed in a timely
            fashion or for some other compelling reason.  IESG Approval
            is not intended to circumvent the public review processes
            implied by other policies that could have been employed for
            a particular assignment.  IESG Approval would be
            appropriate, however, in cases where expediency is desired
            and there is strong consensus for making the assignment
            (e.g., WG consensus).

            The following guidelines are suggested for any evaluation
            under IESG Approval:

            - The IESG can (and should) reject a request if another path
              for registration is available that is more appropriate and
              there is no compelling reason to use that path.

            - Before approving a request, the community should be
              consulted, via a "call for comments" that provides as much
              information as is reasonably possible about the request.

            Examples: IPv4 Multicast address assignments [RFC3171], IPv4
            IGMP Type and Code values [RFC3228], Mobile IPv6 Mobility
            Header Type and Option values [RFC3775].

I wanted to check with the responsible AD that this I-D falls into this category.
2010-08-26
07 Adrian Farrel
[Ballot discuss]
This is a Discuss-Discuss (i.e., no action is required by the authors). It is a point I want to make sure the IESG …
[Ballot discuss]
This is a Discuss-Discuss (i.e., no action is required by the authors). It is a point I want to make sure the IESG is aware of for discussion on the telechat if necessary.

This I-D is Experimental. It requests IANA to allocate some code points from registries that are marked as "Standards Action or IESG Approval"

Obviously, "Standards Action" does not apply to this Experimental I-D.

RFC 5226 is quite wordy wrt to "IESG Approval" saying:

      IESG Approval - New assignments may be approved by the IESG.
            Although there is no requirement that the request be
            documented in an RFC, the IESG has discretion to request
            documents or other supporting materials on a case-by-case
            basis.

            IESG Approval is not intended to be used often or as a
            "common case"; indeed, it has seldom been used in practice
            during the period RFC 2434 was in effect.  Rather, it is
            intended to be available in conjunction with other policies
            as a fall-back mechanism in the case where one of the other
            allowable approval mechanisms cannot be employed in a timely
            fashion or for some other compelling reason.  IESG Approval
            is not intended to circumvent the public review processes
            implied by other policies that could have been employed for
            a particular assignment.  IESG Approval would be
            appropriate, however, in cases where expediency is desired
            and there is strong consensus for making the assignment
            (e.g., WG consensus).

I wanted to check with the responsible AD that this I-D falls into this category.
2010-08-26
07 Russ Housley [Ballot comment]
Please consider the editorial comments in the Gen-ART Review from
  Spencer dawkins on 25-Aug-2010.
2010-08-26
07 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley
2010-08-26
07 Adrian Farrel [Ballot Position Update] New position, Discuss, has been recorded by Adrian Farrel
2010-08-25
07 Ralph Droms [Ballot Position Update] New position, No Objection, has been recorded by Ralph Droms
2010-08-25
07 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu
2010-08-24
07 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded by Stewart Bryant
2010-08-23
07 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2010-08-16
07 Amanda Baber
IANA understands that, upon approval of this document, there are two
actions that it needs to complete.

First, in the Mobility Options subregistry of the …
IANA understands that, upon approval of this document, there are two
actions that it needs to complete.

First, in the Mobility Options subregistry of the Mobile IPv6 parameters
registry located at

http://www.iana.org/assignments/mobility-parameters/mobility-parameters.xhtml

a single value is to be added.

Value Description Reference
-------- -------------------------------------- ---------------
TBD Transient Binding

Second, in the Status Codes subregistry of the Mobile IPv6 parameters
registry at

http://www.iana.org/assignments/mobility-parameters/mobility-parameters.xhtml

a single value is to be added.

Value Description Reference
-------- -------------------------------------- ---------------
TBD PBU_ACCEPTED_TB_IGNORED_SETTINGSMISMATCH

IANA understands that these are the only actions that need to be
completed upon approval of the document.
2010-08-16
07 Sam Weiler Request for Last Call review by SECDIR is assigned to Stefan Santesson
2010-08-16
07 Sam Weiler Request for Last Call review by SECDIR is assigned to Stefan Santesson
2010-08-09
07 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2010-08-09
07 Jari Arkko Placed on agenda for telechat - 2010-08-26 by Jari Arkko
2010-08-09
07 Jari Arkko State Changes to Last Call Requested from AD Evaluation::AD Followup by Jari Arkko
2010-08-09
07 Jari Arkko Last Call was requested by Jari Arkko
2010-08-09
07 Jari Arkko [Ballot Position Update] New position, Yes, has been recorded for Jari Arkko
2010-08-09
07 Jari Arkko Ballot has been issued by Jari Arkko
2010-08-09
07 Jari Arkko Created "Approve" ballot
2010-08-09
07 (System) Ballot writeup text was added
2010-08-09
07 (System) Last call text was added
2010-08-09
07 (System) Ballot approval text was added
2010-08-09
07 Jari Arkko
I talked to Marco at the IETF and we came up with a way forward. The new text is in the I-D that is in …
I talked to Marco at the IETF and we came up with a way forward. The new text is in the I-D that is in the directories, here are the changes:

http://tools.ietf.org/rfcdiff?url2=draft-ietf-mipshop-transient-bce-pmipv6-06.txt

This satisfies, in principle, my earlier complaints. I would ask though the following text to be changed:

OLD:
Where no support from the link layer exists and no such indication can be provided to the nMAG by the network, the host and the network may need to inform each other about the intended movement. The method by which this is accomplished is outside the scope of this specification.
NEW:
Where no support from the link layer exists and no such indication can be provided to the nMAG by the network, the nMAG MUST assume that the host is incapable of this mode of operation, and employ standard behaviour as specified in RFC 5213. In other words, provide a new attachment rather than move an existing attachment to a new point or interface.

I have asked for IETF last call to be initiated.
2010-07-26
07 (System) Sub state has been changed to AD Follow up from New Id Needed
2010-07-26
06 (System) New version available: draft-ietf-mipshop-transient-bce-pmipv6-06.txt
2010-04-26
07 Jari Arkko State Changes to AD Evaluation::Revised ID Needed from AD Evaluation::External Party by Jari Arkko
2010-04-26
07 Jari Arkko I think the host issue requires at least a document change (if not
something more drastic)
2010-04-21
07 Jari Arkko State Changes to AD Evaluation::External Party from AD Evaluation::AD Followup by Jari Arkko
2010-04-21
07 Jari Arkko Still waiting on authors/WG to discuss the host modification issue.
2010-01-26
07 (System) Sub state has been changed to AD Follow up from New Id Needed
2010-01-26
05 (System) New version available: draft-ietf-mipshop-transient-bce-pmipv6-05.txt
2009-12-15
(System) Posted related IPR disclosure: NEC Europe Ltd.'s Statement about IPR related to draft-ietf-mipshop-transient-bce-pmipv6-04
2009-12-08
07 Jari Arkko
I have reviewed this draft. The draft is generally well written and easy to read. With the exception of two major issues and a number …
I have reviewed this draft. The draft is generally well written and easy to read. With the exception of two major issues and a number of smaller issues its in very good shape. I need to hear your explanation first for the two major issues before I can say anything about how we should move forward. Hopefully the fix, if needed, is small.

Please respond to the issues below and revise the document accordingly.

Technical:

*Host effect*:

I failed to understand what the effect to hosts is, and what is expected from the host implementation when two interfaces are active at the same time. Or do you assume this can happen? Are the requirements the same as those in RFC 5213 or do they go beyond it? For instance, presumably the host could be switching interface 1 to interface 2 in an atomic fashion, but some packets could still be in flight from the first MAG to the LMA, so the ability to accept those packets is important. But it would be a very different situation if you assumed the host should be able to keep alive two different interfaces, using the same IP address on both, and be able to accept traffic to them and/or send traffic to the right outgoing interface.

Please explain this to me first and then we can see if the document needs changes because of this.

*Corner cases*:

The specification needs to include a description of what happens in cases where you move on from the nMAG to a (n+1)MAG while in the transient states. There may be other corner cases as well; the loss of PBUs is well handled already, but I'm concerned about other sequences of events that the orderly movement from one place to another. You move from A to B and while that movement is still in progress, you move back to A. And so on.

*Single HNP*:
> The aforementioned problem is illustrated in Figure 1, which assumes
>    that the HNP will be assigned under control of the LMA.
Please go through the specification and ensure that it does not assume there's a single HNP -- RFC 5213 assumes a set.

*Inconsistency*:
> 4.6.2. Activation of a transient BCE
>
>
>    When the LMA receives a PBU from an MN's nMAG which has no Transient
>    Binding option included, the LMA should check whether the MN's BCE is
>    in any of the specified transient states.  If the MN's BCE is not
>    transient, the LMA processes the PBU and updates the MN's BCE
>    according to the PMIPv6 protocol [RFC5213].

Isn't this in conflict with Figure 4, which allowed the LMA to decide that it wants to set up a transient BCE even if no transient option was included?

*Alignment*:
>    The format of the Transient Binding option is as follows.

Please specify alignment rules, too.

*References*:

> [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
>              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
>              September 2007.
>
> [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
>              Address Autoconfiguration", RFC 4862, September 2007.
In my opinion, these references do not need to be normative. They form a part of the rationale and explanation of the environment, but they are not required reading for implementing this in proxy MIP nodes.

*Editorial*:

> In order to eliminate the risk of lost packets, this
> document specifies an extension to PMIPv6 that utilizes a new
> mobility option in the Proxy Binding Update (PBU) and the Proxy
> Binding Acknowledgement (PBA) between nMAG and LMA.
You need to expand references to nMAG and LMA on first use. Please go over the other abbreviations from the document as well.

>
> The aforementioned problem is illustrated in Figure 1, which assumes
> that the HNP will be assigned under control of the LMA.
>
I don't think HNP term has appeared before in the document.

> the
> forwarding entry of the pMAG is removed from the MN's BCE, the
> Transient-L state is left and the BCE state changes to active.

Maybe ".... MN's BCE, the BCE state changes to active."

> nMAG enters the MN's data, such as the assigned HNP, into its BUL and

BUL term has not appeared before

>    experienced by MNs, which have multiple network interfaces

MN term has not appeared before

>    AAA messages.  This document specifies advanced binding cache control

AAA term has not appeared before

>    the PBA, such as the MN's HNP and the link local address to be used

HNP term has not appeared before

> Thus it is not possible that due to the loss of
>      signaling or due to a failure of the nMAG to initiate turning a
>      transient BCE into an active BCE the transient state may not get
>      terminated, i.e. stable operation of the PMIPv6 protocol [RFC5213]
>      has reliably recovered.
Lengthy sentence. Please see if you can make it clearer.

>      TIMEOUT_1 expires. .  After TIMEOUT_1 seconds, the protocol

Two dots.

Jari
2009-12-08
07 Jari Arkko State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Jari Arkko
2009-10-30
07 Jari Arkko State Changes to AD Evaluation from Publication Requested by Jari Arkko
2009-10-08
07 Cindy Morgan
Document shepherd writeup revised to address IPR disclosure #973 (https://datatracker.ietf.org/ipr/973/), which may apply to this document.

-------------------------------------------------------------------

  (1.a)  Who is the Document …
Document shepherd writeup revised to address IPR disclosure #973 (https://datatracker.ietf.org/ipr/973/), which may apply to this document.

-------------------------------------------------------------------

  (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.

There was extensive discussions on whether the problem can be met with just implementation techniques on the LMA. But that issue has been addressed. Appendix B describes the limitations of such implementation techniques. IPR disclosure #973 (https://datatracker.ietf.org/ipr/973/) may apply to this draft since some of the content in draft-liebsch-netlmm-intertech-proxymip6ho-01 has been adopted in draft-ietf-mipshop-transient-bce-pmipv6. I have aksed the NEC folks to update their disclosure if their IPR is also applicable to draft-ietf-mipshop-transient-bce-pmipv6.

  (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.

No ID nits were found. The document meets all the requirements.

  (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 are no downward references.

  (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.

This document specifies a mechanism which enhances Proxy Mobile IPv6 to support the creation of a transient binding cache entry during a handover. This mechanism is applicable to the mobile node's inter-MAG handover while using a single interface or different interfaces.  It ensures optimized forwarding of downlink as well as uplink packets between mobile nodes and the network infrastructure and avoids superfluous packet forwarding delay or even packet loss.

          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 or vendor plans to implement the specification. However a mechanism similar to this is already used in 3GPP when PMIPv6 is use for handovers between two different access
technologies.

          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
2009-10-01
07 Cindy Morgan [Note]: 'Vijay Devarapalli (vijay@wichorus.com) is the Document Shepherd' added by Cindy Morgan
2009-10-01
07 Cindy Morgan
  (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the …
  (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.

There was extensive discussions on whether the problem can be met with 
just implementation techniques on the LMA. But that issue has been 
addressed. Appendix B describes the limitations of such implementation 
techniques. No other 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.

No ID nits were found. The document meets all the requirements.

  (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 are no downward references.

  (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.

This document specifies a mechanism which enhances Proxy Mobile IPv6 
to support the creation of a transient binding cache entry during a 
handover. This mechanism is applicable to the mobile node's inter-MAG 
handover while using a single interface or different interfaces.  It 
ensures optimized forwarding of downlink as well as uplink packets 
between mobile nodes and the network infrastructure and avoids 
superfluous packet forwarding delay or even packet loss.

          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 or vendor plans to implement the 
specification. However a mechanism similar to this is already used in 
3GPP when PMIPv6 is use for handovers between two different access 
technologies.

          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
2009-10-01
07 Cindy Morgan Draft Added by Cindy Morgan in state Publication Requested
2009-09-21
04 (System) New version available: draft-ietf-mipshop-transient-bce-pmipv6-04.txt
2009-06-08
03 (System) New version available: draft-ietf-mipshop-transient-bce-pmipv6-03.txt
2009-03-09
02 (System) New version available: draft-ietf-mipshop-transient-bce-pmipv6-02.txt
2009-02-11
01 (System) New version available: draft-ietf-mipshop-transient-bce-pmipv6-01.txt
2008-10-27
00 (System) New version available: draft-ietf-mipshop-transient-bce-pmipv6-00.txt