Network Mobility (NEMO) Extensions for Mobile IPv4
RFC 5177

[Ballot discuss] There is no information about the manageability of mobile routers and operational implication of their deployment in mip4 environments. At a minimum I ...

[Ballot discuss]
There is no information about the manageability of mobile routers and operational implication of their deployment in mip4 environments. At a minimum I would expect some indication about what initial configuration they require if any, and what status and management information is made available for operational and maintenance purposes. If there are any significant implications on the network traffic level and paterns these should be also mentioned.

[Ballot comment] Section 1., paragraph 0: > 1. Introduction For a document that is the base specification for network mobility, this introduction isn't introductory enough ...

[Ballot comment]
Section 1., paragraph 0:
> 1.  Introduction

  For a document that is the base specification for network mobility,
  this introduction isn't introductory enough. It needs to provide
  something more generally understandable, and a few illustrations
  wouldn't hurt. There is a lot of text on what kinds of modes this is
  and isn't about and what kinds of optimizations are or aren't in
  scope, but very little that actually explains the basic ideas behind
  NEMO. (Or this section needs to point the reader at another draft that
  gives an introduction into NEMO.)

Section 8., paragraph 0:
> 8.  Nested Mobile Networks

  Dave Borman's tsv-dir review resulted in the following suggested
  addition to this section: "Applications that do not support MTU
  discovery are adversely affected by the additional header
  encapsulations, because the usable MTU is reduced with each level of
  nesting."

[Ballot discuss] Can this document be progressed before draft-ietf-mip4-rfc3344bis? I realize that it is listed as an informational reference. But it is not clear to ...

[Ballot discuss]
Can this document be progressed before draft-ietf-mip4-rfc3344bis?  I
  realize that it is listed as an informational reference.  But it is
  not clear to me why.  If RFC 3344 has all of the stuff that is needed
  for this document, what does the additional reference add?

  Can this document be progressed before draft-narten-iana-
  considerations-rfc2434bis?  The reference appears normative to me.

[Ballot comment] While 3344bis has been moved to informative, the text references seem to indicate it is normative. The strongest statement is found in the ...

[Ballot comment]
While 3344bis has been moved to informative, the text references seem to indicate it
is normative.  The strongest statement is found in the first sentence of 6.1:

  A Home Agent MUST support all the operations specified in RFC 3344
  [RFC3344] and its update [I-D.ietf-mip4-rfc3344bis] for Mobile Node
  support.

I probably won't have time to review the delta between 3344 and 3344bis or sort out its
implications for this spec.  Perhaps one of the other ADs is in a position to determine
whether 3344 is really informative or normative...

[Ballot discuss] While it may be obvious to a reader with more mobile clue, the text fails to differentiate between the code values for registration ...

[Ballot discuss]
While it may be obvious to a reader with more mobile clue, the text fails to
differentiate between the code values for registration reply messages and code
values for the mobile network acknowledgement extension.  Since that extension
is conveyed in a registration reply message, that is a bit confusing.

For example, sections 6.3 and 6.6 seem to be in conflict with respect to the value
in the Code field of a Registration Reply message when forwarding and setup was
successful for a subset of the mobile network prefixes.

Paragraph seven in 6.3 states:

  If forwarding and setup was successful for at least one Mobile
  Network Prefix then the Code field of the Registration Reply message
  should be set to 0.  Otherwise that Code should be HA_MOBNET_ERROR.

The first paragraph in 6.6 states:

  The Home Agent MUST set the status code in the registration reply to
  0 to indicate successful processing of the registration request and
  successful set up of forwarding for all the mobile network prefixes
  served by the Mobile Router.  The registration reply MUST contain at
  least one Mobile Network Acknowledgement extension.

So, what should the value of code be when forwarding and setup was successful
for a subset of the prefixes? Perhaps the text in 6.6 is referring to the code
value in a mobile network acknowledgement extension?  I would encourage the
authors to review references to the code field or status code and ensure that
the correct field is clearly specified.

(Note that the problem is particularly bad when the code value is zero; the
reader can reverse-engineer the field from the error code names.)

PROTO Write-up > (1.a) Who is the Document Shepherd for this document? Has the > Document Shepherd personally reviewed this version of the > document and, in ...

PROTO Write-up

> (1.a) Who is the Document Shepherd for this document? Has the
> Document Shepherd personally reviewed this version of the
> document and, in particular, does he or she believe this
> version is ready for forwarding to the IESG for publication?

Document shepherd: Pete McCann
I have reviewed this version of the I-D and believe it is ready for
IESG review and publication.


> (1.b) Has the document had adequate review both from key WG members
> and from key non-WG members? Does the Document Shepherd have
> any concerns about the depth or breadth of the reviews that
> have been performed?

The draft has been reviewed extensively by the working group, but
has not gotten much exposure to non-WG members. I have no concern
about the depth or breadth of the reviews.

> (1.c) Does the Document Shepherd have concerns that the document
> needs more review from a particular or broader perspective,
> e.g., security, operational complexity, someone familiar with
> AAA, internationalization, or XML?

Perhaps the draft would benefit by some review from the Routing
Area, due to its mention of running dynamic routing protocols
over the tunnel between MN and HA. Hopefully this can happen
as part of IETF last call.

> (1.d) Does the Document Shepherd have any specific concerns or
> issues with this document that the Responsible Area Director
> and/or the IESG should be aware of? For example, perhaps he
> or she is uncomfortable with certain parts of the document,
or
> has concerns whether there really is a need for it. In any
> event, if the WG has discussed those issues and has indicated
> that it still wishes to advance the document, detail those
> concerns here. Has an IPR disclosure related to this
document
> been filed? If so, please include a reference to the
> disclosure and summarize the WG discussion and conclusion on
> this issue.

I have no areas of concern. No disclosures relating to the draft
have been filed at this time. However, there is a rumor that one
company does indeed hold IPR on the solution.

> (1.e) How solid is the WG consensus behind this document? Does it
> represent the strong concurrence of a few individuals, with
> others being silent, or does the WG as a whole understand and
> agree with it?

There is strong WG consensus to advance the document. Consensus to
advance it was exhibited during WGLC.

> (1.f) Has anyone threatened an appeal or otherwise indicated
extreme
> discontent? If so, please summarize the areas of conflict in
> separate email messages to the Responsible Area Director.
(It
> should be in a separate email because this questionnaire is
> entered into the ID Tracker.)

No appeals have been threatened.

> (1.g) Has the Document Shepherd personally verified that the
> document satisfies all ID nits? (See
> http://www.ietf.org/ID-Checklist.html and
> http://tools.ietf.org/tools/idnits/.) Boilerplate checks are
> not enough; this check needs to be thorough. Has the
document
> met all formal review criteria it needs to, such as the MIB
> Doctor, media type, and URI type reviews? If the document
> does not already indicate its intended status at the top of
> the first page, please indicate the intended status here.

No nits were found during automatic checking or manual inspection.
The document does have 2 informative references to drafts, which
should be published in the not-to-distant future.

> (1.h) Has the document split its references into normative and
> informative? Are there normative references to documents
that
> are not ready for advancement or are otherwise in an unclear
> state? If such normative references exist, what is the
> strategy for their completion? Are there normative
references
> that are downward references, as described in [RFC3967]? If
> so, list these downward references to support the Area
> Director in the Last Call procedure for them [RFC3967].

The document split references into normative and informative sections.
No downrefs exist in the normative references section.

> (1.i) Has the Document Shepherd verified that the document's IANA
> Considerations section exists and is consistent with the body
> of the document? If the document specifies protocol
> extensions, are reservations requested in appropriate IANA
> registries? Are the IANA registries clearly identified? If
> the document creates a new registry, does it define the
> proposed initial contents of the registry and an allocation
> procedure for future registrations? Does it suggest a
> reasonable name for the new registry? See [RFC2434]. If the
> document describes an Expert Review process, has the Document
> Shepherd conferred with the Responsible Area Director so that
> the IESG can appoint the needed Expert during IESG
> Evaluation?

The IANA considerations section is in the document and is complete.
The document creates two new number spaces, each with an assignment
policy of "Expert Review." We have not yet designated an Expert,
but will confer with the ADs soon.

> (1.j) Has the Document Shepherd verified that sections of the
> document that are written in a formal language, such as XML
> code, BNF rules, MIB definitions, etc., validate correctly in
> an automated checker?

No such formal languages are used.

> (1.k) The IESG approval announcement includes a Document
> Announcement Write-Up. Please provide such a Document
> Announcement Write-Up. Recent examples can be found in the
> "Action" announcements for approved documents. The approval
> announcement contains the following sections:

Technical Summary

This document defines some new extensions to Mobile IPv4 that
allow the Mobile Node to communicate with the Home Agent about
additional network prefixes that it may serve in the capacity
of a Mobile Router. A Mobile Router can be used to provide
connectivity and mobility to an entire mobile network without
any modification to other nodes in the mobile network.

While it is technically possible to create a Mobile Router through
static configuration, this extension allows the network prefixes
to be signaled in Registration Request and Reply messages, so that
the MN and HA can be explicit about which networks are requested
and granted to the Mobile Router.

Working Group Summary

The working group made some recent changes to indicate that this
is just an extension to the Mobile IPv4 protocol, rather than a
new mobility management protocol. The document went through last
call without any major disagreements coming up.

Document Quality

The document was reviewed for quality by Pete McCann.

Personnel

Document shepherd: Pete McCann
Responsible AD: Jari Arkko