Skip to main content

Network Mobility Support Goals and Requirements
draft-ietf-nemo-requirements-06

Yes

(Jari Arkko)

No Objection

(Cullen Jennings)
(Dan Romascanu)
(Lisa Dusseault)
(Magnus Westerlund)
(Mark Townsley)
(Ross Callon)
(Sam Hartman)

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

Lars Eggert No Objection

Comment (2006-11-28)
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

Yes ()

                            

(Brian Carpenter; former steering group member) No Objection

No Objection (2006-11-30)
>> 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

No Objection ()

                            

(Dan Romascanu; former steering group member) No Objection

No Objection ()

                            

(David Kessens; former steering group member) No Objection

No Objection (2006-11-30)
I support Ross' DISCUSS

(Lisa Dusseault; former steering group member) No Objection

No Objection ()

                            

(Magnus Westerlund; former steering group member) No Objection

No Objection ()

                            

(Mark Townsley; former steering group member) No Objection

No Objection ()

                            

(Ross Callon; former steering group member) (was No Record, Discuss) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) No Objection

No Objection (2006-11-29)
  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

No Objection ()

                            

(Ted Hardie; former steering group member) No Objection

No Objection (2006-11-29)
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.