Ed Remmell writes: Middle of section 8.2, minor typo: "Route
optimization introduces a small amount of additional state for the
peers, some additional messaging, and upto". Here "upto" should be "up
to"

section 9.3.1, missing "if": "Mobile nodes are expected to include a
Home Address destination option in a packet they believe the
correspondent node has a Binding Cache entry for the home address of a
mobile node" Here "they" should be "if they"

Bryan Wang writes: "9.4.3 Sending Home Test Messages .... Note that
the Home Test message is always sent to the home address of the mobile
node , even when there is an existing binding for the mobile node. "
Shouldn't this be a hard requirement? instead of a "note". Page 26,
line 15: "the mobile can ...", should be "the mobile node can ...".
Page 27, line 18: "The care-of init cookie from the from Care-of Test
Init message ...", there is a extra "from".

Greg O'Shea writes: "The Binding Update List records information for
each Binding Update sent by this mobile node, for which the lifetime
of the binding not yet expired." [11.1] Maybe "... of the binding has
not yet..."

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

Thanks. Will be corrected in the next revision.

Regarding the HOT message: Well, Section 5 talks about sending this
message via the home agent so that might be sufficient. But I can
change the above to a "MUST be sent" so its 100% clear.

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

Vijay Devarapalli responds to Ed Remmell: Here we go again.... we are
describing basic protocol behavior.  When sending HoT, existing
binding cache entries should be ignored. MUST and MUST NOT should not
be used for describing protocol behavior.

How about "The CN ignores existing binding cache entry for the home
address when sending a Home Test message"

Avoid using MUST and MUST NOT when not needed. 

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

Ed Remmell responds to Vijay Devarapalli: OK, thanks for your response.

The thing that bothers me about this particular non-requirement is that it
is critical that it be implemented correctly on the CN, so that return
routability will be able to secure the binding update that the MN sends.

A CN implementor could decide that it is too slow to go through the home
agent when sending the HoT if it has an existing binding for the MN, and
then just use route optimization to send the HoT to the MN directly in that
case. That kind of defeats a lot of the purpose of using return routability.

I'm just interested in improving the spec, so we can just forget about
making any changes for this if you feel they are not required, that's fine
by me.

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

Ed Remmell continues: Or, more likely, this might not be a conscious
choice, but by accident. That could have been the case with our CN
implementation, since we use a host routing entry in the routing tree
to implement the CN binding entry. So, our CN send logic does a
routing tree lookup to find the device/interface to send the packet
on. If there is a binding there for the MN's home address, we will (by
default) use it. We have to include special code in our CN
implementation for sending a HoT when there is an existing binding to
avoid using that binding. Without this being clearly documented in the
specification as a mandatory requirement (i.e. MUST, MUST NOT), it is
more likely that an implementor will miss this.

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

Ed Remmell continues: We just took another look at draft 21, and I
guess we were sleeping or something , but we seem to have missed the
following requirement in section 9.4.3:

"The Home Test message MUST be sent to the home address of the mobile node
without route optimization, even when there is an existing binding for the
mobile node."

So, this is a non-issue, thanks for your time.

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

Jari Arkko responds to Ed Remmell: You were probably looking at the
latest draft from the web, where I had already made the modifications
you requested... before Vijay complained about the keywords. The above
text is not in draft 21.

Anyway, I think the change was useful -- even if Section 5 talks about
the same thing. The more exact language we use, the better. I don't
think there's a need to worry about keywords in this text. Even the
requirements for a MUST, as specified by RFC 2119, are fulfilled here.

I have classified this as an editorial modification in issue #267 along
with some other minor edits. 

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