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

[Ballot discuss]
I think that this requirements document needs to contain a requirement that the NEMO solution(s) MUST have minimal negative effect on the global Internet routing system. As one example of why this is necessary, the approach of just advertising the mobile network's connectivity into BGP, and as the network moves withdrawing old routes and injecting new routes, has been tried and even with moderate deployment (order of a hundred mobile networks) this had significant negative effect on the global operation of BGP. If there were tens of thousands of mobile networks each advertising and withdrawing routes at the speed that an airplane can move from one ground station to another, the potential effect on BGP could be unfortunate.

I understand that entering this Discuss implies that I will need to work with the authors to help them come up with appropriate text.

[Ballot discuss]
I think that this requirements document needs to contain a requirement that the NEMO solution(s) MUST have minimal negative effect on the global Internet routing system. As one example of why this is necessary, the approach of just advertising the mobile network's connectivity into BGP, and as the network moves withdrawing old routes and injecting new routes, has been tried and even with moderate deployment (order of a hundred mobile networks) this had significant negative effect on the global operation of BGP. If there were tens of thousands of mobile networks each advertising and withdrawing routes at the speed that an airplane can move from one ground station to another, the potential effect on BGP could be unfortunate.

I understand that entering this Discuss implies that I will need to work with the authors to help them come up with appropriate text.

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

This is the writeup from Thierry, who is also an author (!):

    (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?

I am the document editor, so I will shepherd these documents. I believe
they are ready for 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?

I do not have any concerns about the review of the documents. They 
were presented numerous times in the NEMO working group sessions and 
discussed on the mailing list. The issues which have been raised have been considered as it could be shown on http://www.sfc.wide.ad.jp/~ernst/nemo/


    (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?

At this point, I believe the documents have had sufficient review. The
documents are informational and do not bear such concernd as listed here
above.

    (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.

No, there has not been any controversy about these documents and I 
don't have any reservation putting them forward.

    (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?

A few terms from the terminology draft have had some controversy; the
definitions of these term have been brought during the IETF meetings and
amended when necessary (some proposed terms have been removed, or a new
definitions have been proposed). These documents have had a long life,
the WG has been somewhat upset that it took so long for the editor to
produce the final version but the WG has a consensus that these
documents are needed and where useful to structure the discussions on
issues and solutions.

    (1.f)  Has anyone threatened an appeal or otherwise indicated 
extreme
          discontent?  If so, please summarise 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.

  (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?

I have personally run both documents through the nits checker, with 
no nits found.

    (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].

Yes, they are split into normative and informative. The only  normative
reference that is not finished is draft-ietf-nemo-multihoming-issues
that is also exptectedd to be submitted for IESG review.

    (1.i)  Has the Document Shepherd verified that the document IANA
          consideration 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 suggested a
          reasonable name for the new registry?  See
          [I-D.narten-iana-considerations-rfc2434bis].  If the document
          describes an Expert Review process has Shepherd conferred 
with
          the Responsible Area Director so that the IESG can appoint 
the
          needed Expert during the IESG Evaluation?

The section exists, and it states that there is no IANA action 
needed. Since the documents are informative and do not propose any 
new protocol elements, I believe this is correct.

    (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?

Not applicable.

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

draft-ietf-nemo-terminology:

Network mobility arises when a router connecting a network to the 
Internet dynamically changes its point of attachment to the Internet 
thereby causing the reachability of the said network to be changed in 
relation to the fixed Internet topology.  Such kind of network is 
referred to as a mobile network.  With appropriate mechanisms, 
sessions established between nodes in the mobile network and the 
global Internet can be maintained after the mobile router changes its 
point of attachment. 

This document is an informative reference, and defines a terminology for
discussing network mobility (NEMO) issues and solution requirements. The
document was written with the extensive help and review of the NEMO
working  group. The Document Shepherd for this document is T. Ernst and
the Responsible Area Director is Jari Arkko.

draft-ietf-nemo-requirements:

Network mobility arises when a router connecting a network to the 
Internet dynamically changes its point of attachment to the Internet 
thereby causing the reachability of the said network to be changed in 
relation to the fixed Internet topology.  Such kind of network is 
referred to as a mobile network.  With appropriate mechanisms, 
sessions established between nodes in the mobile network and the 
global Internet can be maintained after the mobile router changes its 
point of attachment. 

This document is an informative reference, and  outlines the goals
expected from  network mobility support and defines the requirements
that must be  met by the NEMO Basic Support solution. The document was
written with the extensive help and review of the NEMO working  group.
The Document Shepherd for this document is T. Ernst and the Responsible
Area Director is Jari Arkko.

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

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

[Ballot discuss]
Based on a security review by Radia Perlman.

The security considerations section needs to point to the security
requirements in section 3 and 4.

Requirement R10 is unclear; neither Radia nor I understand what it
means.

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