Network Mobility Support Goals and Requirements
draft-ietf-nemo-requirements-06
Yes
No Objection
Note: This ballot was opened for revision 06 and is now closed.
Lars Eggert No Objection
Section 1., paragraph 2:
> Cases of mobile networks include, for instance:
At least in the way they are currently implemented/provided, many of
these examples don't fit the definition of NEMO above ("network that
changes its point of attachment to the Internet").
Section 2., paragraph 0:
> 2. NEMO Working Group Objectives and Methodology
I'd remove this section. Nothing in here is related to goals or
requirements; section just documents WG history and approach.
Section 4., paragraph 0:
> 4. NEMO Basic Support One-Liner Requirements
Section uses RFC2119 language without the required boilerplate and
citation.
(Jari Arkko; former steering group member) Yes
(Brian Carpenter; former steering group member) No Objection
>> 3.1. Migration Transparency >> >> Permanent connectivity to the Internet has to be provided to all >> MNNs, since continuous sessions are expected to be maintained as the >> mobile router changes its point of attachment. For maintaining those >> sessions, MNNs are expected to be reachable via their permanent IP >> addresses. It isn't quite clear what "permanent" means. If the MNN is running MIP6 it presumably means its home address. If it is not running MIP6, it presumably means an address acquired from the MR. This could usefully be clarified. >> 3.10. Location Privacy >> >> Location privacy means to hide the actual location of MNNS to third >> parties other than the HA are desired. It is not clear to which >> extend this has to be enforced, since it is always possible to >> determine the topological location by analysing IPv6 headers. That isn't *always* true; see draft-ietf-v6ops-nap. For example, replace the last bit of the text with "since it might be possible to determine the topological location by some traffic engineering means" >> 5. Security Considerations Suggest a reference to the security considerations in RFC 3963.
(Cullen Jennings; former steering group member) No Objection
(Dan Romascanu; former steering group member) No Objection
(David Kessens; former steering group member) No Objection
I support Ross' DISCUSS
(Lisa Dusseault; former steering group member) No Objection
(Magnus Westerlund; former steering group member) No Objection
(Mark Townsley; former steering group member) No Objection
(Ross Callon; former steering group member) (was No Record, Discuss) No Objection
(Russ Housley; former steering group member) No Objection
Sam Hartman has a DISCUSS on the major points from the SecDir Review by Radia Perlman. I support it, but there is no value in putting another DISCUSS on this document.
(Sam Hartman; former steering group member) (was Discuss) No Objection
(Ted Hardie; former steering group member) No Objection
I find the language on location privacy to be pretty hard to parse as a goal. It says:
Location privacy means to hide the actual location of MNNS to third
parties other than the HA are desired. It is not clear to which
extend this has to be enforced, since it is always possible to
determine the topological location by analysing IPv6 headers. It
would thus require some kind of encryption of the IPv6 header to
prevent third parties from monitoring IPv6 addresses between the MR
and the HA. On the other hand, it is at the very least desirable to
provide a means for MNNs to hide their real topological location to
their CNs.
if there will be an update to the document, clarifying this statment would
be useful, in my opinion.
I also believe that this requirement is misphrased:
R03: All traffic exchanged between an MNN and a CN in the global
Internet MUST transit through the bi-directional MRHA tunnel.
Since the document acknowledges that there might be quite complex
topologies, including multihoming, I assume that the working group
recognizes that this limitation applies only to the address associated
with the MRHA.
Similarly, may I suggest that this:
R04: MNNs MUST be reachable at a permanent IP address and name.
would be better phrased as a "stable IP address and name". Permanent
has implications I do not believe the rest of the document supports.