Subject: [Mipshop] last call comments on LMM requirements

From: "Carl Williams" <[email-masked]>
Date: Fri, 31 Oct 2003 02:51:35 -0800

Per Gab's request to send out last call comments
on LMM requirements:
 
Last Call Comments on LMM requirements draft
============================================

LMM_LC1  
 
Proposed Change:  Add statement to goals that
LMM should introduce no new security vulnerabilities.
 
Propose to ACCEPT
 
    In intro section the following statement will
    be added:
 
    - introduce no new security vulnerabilities

LMM_LC2
 
Proposed Change:   Section 3.1 should not be specific 
only to MIPv6 (protocol dependent).
 
Propose to ACCEPT
 
   Section 3.1 change:
 
    "This is the fundamental reason for introducing localized 
     mobility management extensions to core Mobile IPv6."  
 
    to:
 
     "This is the fundamental reason for introducing localized
      mobility management extensions to Mobile IP based protocols [2,3].
 
LMM_LC3
 
Proposed Change:  In Section 3.4.2 remove sentence stating how
                  this requirement may be realized.
 
Propose to ACCEPT
 
     In Section 3.4.2 remove the following sentence:
 
      This would involve MIP-specific routing state as binding 
      caches in addition to standard routing table host routes. 

LMM_LC4
 
Proposed Change:  In section 3.4.4 reword requirement a bit better
       to allow for performance improvements.
 
Propose to ACCEPT
 
       In Section 3.4.4 change to:
 
          The LMM framework MUST NOT degrade in any way the basic
          IP mobility performance of a mobile host communications
          with a Correspondent Node(s).
 
LMM_LC5
 
Concern over Requirement 3.4.6 being too restrictive:
 
   "Section 3.4.6. Again, if the requirement is taken literally, 
    it is indeed quite restrictive, ruling out all hierarchical 
    schemes, for example."
 
Preliminary Response:
 
Section 3.4.6 states:
 
   3.4.6 Resilience to topological changes
 
   The LMM protocols MUST be topology-independent.  The LMM protocols
   MUST be able to adapt to topological changes within the domain.  The
   topological changes may include the addition or removal/failure of
   LMM agents or that of changes in the routing of the local domain
   over which the LMM scheme is applied.

The requirement can be left as is.  LMM solution proposals
can address via on-link replication mechanisms, use of anycast
may pose as a promising solution for effecting an LMM function
that supports transparently topological changes.  Dynamic anycast
routing may encompass path-healing semantics for LMM agent nodes
so as to consider alternative routing paths in the event of a 
topological change.  See ref [1] for analysis for this requirement.
 
LMM_LC6
 
Proposed Change:  Security consideration should refect what
the issues with LMM and security.  
 
Propose to ACCEPT
 
   Need to come up with proposed text in security
   consideration section - probable include security requirements
   here as well.  Any help is appreciated.

LMM_LC7 
 
Proposed Change:  IESG NITS
 
Propose to ACCEPT: YES!  used msft word and saved as text - where
                    at least formating problems arose.
 
Other minor nits:  
 
         - Move ref [1] to intro and refer to it for more detailed
           analysis.
         - [8] is not referenced.  I wish to keep [8] in and will
           mention fmipv6 somehow.
 
LMM_LC8
 
Question posed:  phrase "security provisioning" used.  Question:
                 is this phrased used elsewhere? (i.e., IPsec)
                 Term is used in section 3.2.
 
                 Propose to use "provide security services" instead.
 
Response:  we used security provisioning as a general term in the
           LMM requirement analysis [1].  "Provide Security Services"
           communicates the requirement just as well.
 
LMM_LC9
 
Propose to Change Title.
 
Propose to ACCEPT:
 
              Propose to change title to:

   Requirements for Mobile IP Localized Mobility Management