Home Agent-Assisted Route Optimization between Mobile IPv4 Networks
RFC 6521

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

(Jari Arkko) Yes

(Ron Bonica) No Objection

(Gonzalo Camarillo) No Objection

(Ralph Droms) (was Discuss) No Objection

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

Comment (2011-11-01 for -)
No email
send info
I support Ralph's Discuss although I see that the reasoning is clear
from the charter. It should be simple to construct equivalent text to
go in the document.

---

I searched for a definition of "optimum" or "route optimizaton". I 
found

   This document proposes a method to
   optimize routes between networks behind Mobile Routers, as defined by
   NEMO [RFC5177].

But RFC 5177 says;

   This document
   does not touch on aspects related to route optimization of this
   traffic.

Section 1 does include a number of statements that "route optimization
addresses this issue" for several issues. That is great, but I still 
missed a succinct definition of "route optimization" and some 
understanding of how I would recognize "optimum" if I saw it.

---

Section 3.2.2seems to have "should" and "may" that might benefit from
moving to RFC 2119 usage.

(Stephen Farrell) No Objection

Comment (2011-11-02 for -)
No email
send info
I'm assuming that these questions just reflect my ignorance of nemo, 
and since this is (currently) aimed at experimental, I'll not make them
a discuss. (If it were going for PS, I think these would be discuss-worthy.)

(1) I don't get how Kcr is setup as required in 3.2?  Is Kcr
supposed to be manually installed? Do all MR's need to have a
different Kcr for all other MRs or is Kcr shared between the MR and
HA?

(2) 3.2.1 says an MR MAY generate a new key at any time. How is that
distributed (securely)?

(Russ Housley) (was Discuss) No Objection

Comment (2011-11-03)
No email
send info
The Gen-ART Review by Roni Even on 29-Oct-2011 raises two editorial
  comments.  Please consider them.

  1. Typo in Section 3.1, first paragraph: “alredy”

  2. In Section 3.3.1: “only be when” change to “only when”; and
     “and and whose” delete one of the “and”.

(Pete Resnick) No Objection

Comment (2011-11-02 for -)
No email
send info
I agree with Ralph that more should be said in the document about the nature of the experiment.

(Dan Romascanu) No Objection

(Robert Sparks) No Objection

Comment (2011-11-02 for -)
No email
send info
Related to Russ' discuss (which I support):

IANA has unanswered questions (Authors - you received them directly and can also see them at the
line starting:
2011-10-31 	06 	Amanda Baber 	
IANA has several questions about draft-ietf-mip4-nemo-haaro-06.txt.

at

<https://datatracker.ietf.org/doc/draft-ietf-mip4-nemo-haaro/history/>


(Sean Turner) No Objection

Comment (2011-11-03 for -)
No email
send info
I didn't get all the way through this one, but I did notice the following:

Mention a random # and get a request to add a reference to RFC 4086 ;)  Please add one in s3.2.2.  Should probably also add a pointer in s3.2.1 because the keys generated need to be random too.