Interactions between Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6 (MIPv6): Scenarios and Related Issues
draft-ietf-netlmm-mip-interactions-07

The OPS-DIR review by Jouni Korhonen raised a number of non-blocking issues, most of them of editorial nature, which should be considered if a new revision of the  document is spun out: 

The document mentions that there are system specific issues that need to be taken into account; see Sections 4.2.1 and 4.3. Those are merely bypassed stating being "out of scope". While this is true, from operational and management perspective it would be nice to see even references here for further reading if any of those "out of scope" things have been solved or discussed somewhere. For example Section 4.2.1 depends on LMA discovery to work properly within the same administrative domain. There are solutions for this documented in IETF in PMIPv6 context. Another related nit to point out is that the document could actually mention that the separate HA/LMA functions actually would benefit from a shared subscriber database (e.g. AAA
server) to work properly. The text seems to hint that anyway.


Few editorial comments:

o Section 2 should also say that it uses acronyms from RFC5213 and RFC3775.

o Section 3 add a reference to HMIPv6-MIPv6.

o Sequence number based ordering is possible (optional) for PMIPv6 in
RFC5213 unlike stated in Section 3.2, step 1) first bullet. Not that it would help to solve the issue described here, but using sequence numbers in
PMIPv6 is possible in general as an option.

o Section 3.2 step 4) last bullet I do not understand why it mentions "both host-based and network-based security associations are used to update the same binding cache entry at the HA/LMA" as earlier the scenario has been scoped so that HA & LMA binding caches are separate.

o Section 3.2 -> s/(or binging cache)./(or binding cache).
              -> s/RFC4832, section 2.2/RFC4832, Section 2.2
              -> add a reference to IKEv2 [RFC5996]

o Section 3.3 says the ".. advertising the home link prefix to the MN in a unicast Router Advertisement message." While it makes sense and is typical behavior when a MAG receives a Router Solicitation, it is not necessarily the case always. The MAG can send multicast Router Advertisements when it so decides or send it before receiving a Router Solicitation.

o Section 4.2.1 -> s/MN-HoA.For/MN-HoA. For

o Section 4.2.2 -> s/MAG. the/MAG. The

o Section 4.2.2 could reference to draft-ietf-netlmm-lma-discovery when it discusses about LMA discovery and it not being defined in RFC5213.

o Section 5 reference [pmipv6-draft] should be [RFC5213].

o The document uses both (P)MIPv6 and (Proxy) Mobile IPv6 interchangeably.
It should stick with one style.

o The document uses both BCE and binding cache entry interchangeably. It should stick with one style.

o The document uses both HA and Home Agent interchangeably. It should stick with one style.

o The document uses both HA/LMA and LMA/HA interchangeably. It should stick with one style.

o Most of the acronyms are not expanded on the first use.

  Please consider the comments from the Gen-ART Review by Enrico
  Marocco on 12 May 2010.  The review can be found at:

    http://www.softarmor.com/rai/temp-gen-art/
    draft-ietf-netlmm-mip-interactions-06-marocco.txt

I support Tim's DISCUSS positions.

Some nits:

Section 3, second sentence:
OLD
                                               This document does not
                                                             ^^^^
   only focus on scenarios where the two protocols are used by the same
   mobile node to manage local and global mobility, but it investigates
                                                        ^^
   also more complex scenarios where the protocols are more tightly
   ^^^^
NEW
                                                This document not
   only focuses on scenarios where the two protocols are used by the same
   mobile node to manage local and global mobility, but also investigates
   more complex scenarios where the protocols are more tightly


Section 3, page 9, line 4:
OLD
   depicted in the figure.  However, the LMA and HA can be also
                                                        ^^^^^^^
NEW
   depicted in the figure.  However, the LMA and HA can also be

(1) Section 3.2, list item 4 bullet 3

s/binging/binding/

(2) The final sentence in Section 5 (Security Considerations) is considerably weaker  than the
text in Section 3.2, list item 4 bullet 4.

From section 3.2:
                              Based on this
          consideration, the threat described in [RFC4832] is worse as
          it affects also hosts that are using the LMA/HA as MIPv6 HA
          and are not using PMIPv6.
From section 5:
    Note that the compromised MAG threat described in [RFC4832]
   applies also here.

I suggest that the text in the security considerations be strengthened...