Network Mobility Home Network Models
RFC 4887

Comments from the Ops directorate by Pekka Savola:

I found this document reasonably clear.  I do not think there are any
blocking issues, but there seem to be suitably many editorial
clarifications that could help.  As the doc has normative refs to work
that is still at WG, there should be time to revise it.

semi-editorial issues
---------------------


   If the Mobile Router returns Home by Egress, a specific support is
   required to control the bridging operation depending on whether a
   Mobile Router is at Home or not.  This support might not be present
   in all implementations.

==> in a number of places you say "present in ... implementations" ..
but what about the specifications?  Do specifications provide with
sufficient mechanisms to convey which mechanism should be used by
mobile routers in each of the scenarios so that they would pick an
interoperable and/or working approach?  (As I haven't studied the
specs in detail, I don't know the answer -- this is just something
that was not apparent from reading the doc.)

13.1  normative reference
...
   [9]   Ernst, T. and H. Lach, "Network Mobility Support Terminology",
         draft-ietf-nemo-terminology-03 (work in progress),
         February 2005.

   [10]  Ernst, T., "Network Mobility Support Goals and Requirements",
         draft-ietf-nemo-requirements-04 (work in progress),
         February 2005.

==> these two are normative references but are still at WG.  The
publication of this document will be blocked until these are published
as well... I hope the WG is aware of this.

editorial
---------

==> examples used the prefixes A:B:C::/48 and CAB:C0::/32.  You should
use 2001:db8::/32 instead as it's specifically meant as a doc prefix --
unless you have strong reasons for otherwise.


==> a number of terms weren't spelled out, such as MNP, MNN, ...

Abstract

   This paper documents some usage patterns and the associated issues
   when deploying a Home Network for NEMO-enabled Mobile Routers,
   conforming the NEMO Basic Support draft [8].

==> no refs in the abstract.  Don't use the word, "draft" especially if it's
an RFC ;-).

   The following terms used in this document are defined in the IPv6
   Addressing Architecture document [5]:

      link-local unicast address

      link-local scope multicast address

==> these terms are in fact not used in this doc, so this can be
removed.

6.2 [Aggregated Home Network - Returning home]
...
   Since the Home Network prefix is an aggregation that encompasses all
   the MNPs, the Home Address that an MR forms from one of its Mobile
   Network Prefixes will actually match both the Home Network prefix and
   its Mobile Network prefix.  To properly identify the Home Network,
   the MR must expect a shorter prefix than that of the Mobile Network
   from which the Home Address was formed.

   When the Mobile Router forms its Home Address out of one of its
   Mobile Network Prefixes, since the Home Network prefix is an
   aggregation that encompasses all the MNPs, the Home Address actually
   matches both prefixes.  As a result, the MR must expect a shorter
   prefix than that of the Mobile Network from which the Home Address
   was formed.

==> Isn't the 2nd paragraph baiscally text duplication of the first, or was
there a separate point there?  I had hard time following this.  In any case,
I'd suggest rewording.

Please
   refer to the NEMO multihoming issues [13] draft for more on this.

== remove or reword "draft"

   One should check with the product specifications of an Home Agent to
   see whether the implementation actually supports a Virtual Home
   Network, and if so, whether in that cases, it is optimized for faster
   DAD-less bindings.

==> remove "with".  Is the present wording even good for an IETF doc?

The citation "[8]" should be removed from the Abstract and the technical summary portion of the ballot write-up.

The document uses this example:

"Cab Co is a taxi Company that owns a /32 prefix"

The phrase "owns a /NN prefix" might be better put as "uses".  The question of ownership and
address prefixes has been the subject of non-technical debate over the years, and skipping it
might make sense.