IPv4 Support for Proxy Mobile IPv6
RFC 5844

Note: This ballot was opened for revision 18 and is now closed.

(Jari Arkko) (was Discuss, Yes) Yes

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Ralph Droms) (was Discuss) No Objection

(Lisa Dusseault) No Objection

(Adrian Farrel) No Objection

Comment (2009-05-20 for -)
No email
send info
I have raised my issues as Comments as they are all editorial. But
the volume of issues brings them very close to being bundled together
as a Discuss.

===

I know that the RFC Editor can sort a lot of this out, and it is no 
criticism of the authors, but the reviews would be smoother and more
likely to focus on technical details if in future you could get 
someone to take a pass on the English of the document preferably 
before WG last call.

Fixing some of the language has the potential to accidentally break
the meaning of the text, and you cannot rely on the RFC Editor to
understand all of the technical details.

===

Section 1
   It is also reasonable to expect the same
   mobility infrastructure in the Proxy Mobile IPv6 domain to provide
   mobility to the mobile nodes operating in IPv4, IPv6 or in dual mode
   and when the network between the local mobility anchor and the mobile
   access gateway is an IPv4 or an IPv6 network.

I can't parse this sentence. I get lost around "and when". Any chance
of a rephrase?

===

Section 1 bullet 1
      The mobile node is not required to be
      allocated or assigned an IPv6 address for enabling IPv4 home
      address support.

I think you mean s/for enabling/to enable/  but this is a subtly
different meaning.

===

Figure 1

This figure is an orphan! I can't find any text that refers to it and
it really needs some explanation. It also uses some acronyms that aren't
explained until quite a bit later.

It *is* good to have a figure early in the I-D, but you can't just plonk
it in.

===

Section 1.1

The section title is clear, and the bullet points appear to match the
title, but the introduction paragraph:
   The following are the configuration requirements from the mobility
   entities in the Proxy Mobile IPv6 domain for supporting the
   extensions defined in this document.
talks of configuration requirements and is only relevant to some of 
the assumptions. Separate assumptions from configuration requirements?

===

Figure 2 also uses some acronyms/identifiers that are not explained.

===

I don't find the use of "IPv4 default-router" and "IPv4 default-router
address" very clear.

In 1.1 there is
      The mobile access gateway is the IPv4 default-router for the
      mobile node on its access link.
which is clear.
But later (3.1.1 etc. and even in 3.3.1)
      The IPv4 default-router address assigned to the mobile node.
Can you make this clear throughout the document (search on default-
router) whether this is an address assigned to the mobile node (i.e.
and address of the mobile node) or the address of the default-router
that has been assigned to the mobile node (i.e. the address of the
default-router).

===

3.3.2

You might consider creating a registry for bits in the DHCP Support
Mode Option.

===

The IANA section seems to be deficient in detail and also missing the
IPv4 DHCP Support Mode Option. But I see that IANA has an open issue
to be addressed by the authors.

===

(Russ Housley) (was Discuss) No Objection

(Tim Polk) No Objection

Comment (2009-06-04 for -)
No email
send info
Paraphrased from Stephen Farrell's secdir review:

3.1.2.7 says: "when there is not a single Home Network Prefix
option with NON_ZERO value present in the request..." That's very
hard to interpret and possibly badly ambiguous. "Not a single" could
mean zero or >1.

Perhaps "when there are no Home Network Prefix options with a
NON_ZERO value present in the request ..." would be clearer.

3.1.3 says that the mobility anchor MUST advertise a connected
route but doesn't say how.  Perhaps a reference is in order here?

section 7: s/news/new/

(Dan Romascanu) No Objection

Comment (2009-06-04 for -)
No email
send info
The OPSA-DIR review included a number of editorial comments. None of them is a show stopper, but incase the document goes though a revision for other reasons I suggest that they are considered.

(Robert Sparks) No Objection

(Magnus Westerlund) No Objection

(Pasi Eronen) (was Discuss) Abstain

Comment (2009-08-27 for -)
No email
send info
The base Proxy Mobile IPv6 spec (RFC 5213) uses IPsec in a very simple
way: it requires no Mobile IP specific changes to IPsec, and it's even
possible to use a "bump-in-the-wire" implementation, such as a
separate IPsec gateway sitting next to the MAG and LMA.

The IPv4 transport support introduced in this document completely
changes the situation by requiring Mobile IP specific changes to
IPsec, and preventing the use of separate gateway/"bump-in-the-wire"
implementation. With these changes, I do not think IPsec is anymore a
reasonable solution for securing PMIP. However, it is not realistic to
ask this draft to fix the situation; thus, I am balloting "abstain".