Network Mobility (NEMO) Basic Support Protocol
RFC 3963

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

(Margaret Cullen) Yes

(Harald Alvestrand) (was Discuss) No Objection

Comment (2004-06-09)
No email
send info
Not all considerations for which I put in a DISCUSS have been fixed.
Version -03 section 8 says (unchanged):

>    When the Mobile Router is attached to the home link, it runs a
>    routing protocol by sending routing updates through its egress
>    interface.  When the mobile router moves and attaches to a visited
>    network, it MUST stop sending routing updates on the interface
>    with which it attaches to the visited link.

But the other comment is, so I'm changing this to a comment.

Further comments from Gen-ART reviewer Michael Patton on this URL:

(Steven Bellovin) (was Discuss) No Objection

(Bill Fenner) No Objection

(Ted Hardie) No Objection

Comment (2004-03-17 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I'm a bit confused by this text in section 5.6:

   When the Mobile Router is at home, it MAY be configured to send
   Router Advertisements and reply to Router Solicitations on the
   interface attached to the home link.  The value of the Router
   Lifetime field MUST be set to zero to prevent other nodes from
   configuring the Mobile Router as the default router.

I don't see cases where the mobile router would have a different
upstream link in its home link than a non-mobile router on this
link.  Is there a use case where it is expected that all the routers
on the home link might be mobile routers (so only mobile routers
are replying to RSs?)

Not a blocking comment, obviously; I'm just curious about the use
case that drives this.

(Scott Hollenbeck) No Objection

Comment (2004-03-11 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Editorial nits:

The NEMO acronym should be spelled out as "Network Mobility" in the abstract.

Section 2: RFC 2119 is cited as reference #2, but it's not listed among the references.

Section 4.2 (first instance): I noticed that all of the numeric values used in the document for things like status values aren't clearly identified as being represented in decimal format.  With values like "128" it's obvious, but at a quick glance values like "140" aren't so clear.  draft-ietf-mobileip-ipv6-24.txt, which is being expanded upon, does the same thing so I can understand continuing the convention.  I think it would be a good idea, though, to clearly note that these are decimal values and not octal values.

(Russ Housley) No Objection

Comment (2004-03-16 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
  Section 2: s/defined in [8] [9]./defined in [8] and [9]./

(David Kessens) No Objection

(Allison Mankin) No Objection

(Jon Peterson) No Objection

(Bert Wijnen) No Objection

Comment (2004-03-18 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I see two "sections" named "References"
I assume the first one is normative refs and 2nd one 
is informative refs.

(Alex Zinin) (was Discuss) No Objection