Network Mobility Home Network Models
RFC 4887

[Ballot comment]
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?

[Ballot comment]
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?

[Ballot comment]
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.

[Ballot discuss]
In 6.4.1, the document says:

  Thus, on the Home Link, the Home Agent must intercept all the packets
  to ALL the Mobile Network Nodes on the registered prefixes.  In order
  to do so, the Home Agent might perform some form of ND proxying for
  all addresses in all registered Mobile Network Prefixes.  The Home
  Agent must also protect the MNP space from autoconfiguration by
  uncontrolled visitors at Neighbor Discovery level.

  Alternatives based on a routing protocol or ICMP redirect may apply
  in some cases.

The second paragraph is not clear to me.  Is the intent to say that ICMP redirect
or some routing protocol behavior will substitute for ND proxying?