AD review of draft-ietf-mipshop-transient-bce-pmipv6

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 <http://tools.ietf.org/html/rfc4861>,
>               September 2007.
>
> [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
>              Address Autoconfiguration", RFC 4862 <http://tools.ietf.org/html/rfc4862>, 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 <http://tools.ietf.org/html/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