Subject: [Mipshop] lc comments on LMM requirements

From: "Carl Williams" <[email-masked]>
Date: Fri, 31 Oct 2003 10:59:47 -0800

Per Gab's request here are lc comments and response on
LMM requirements.
 
Last Call Comments on LMM requirements
======================================
LMM_LC1  
 
Proposed Change:  Add statement to goals that
LMM should introduce no new security vulnerabilities.
 
Propose to ACCEPT
 
LMM_LC2
 
Proposed Change:   Section 3.1 should not be specific 
only to MIPv6 (protocol dependent).
 
Propose to ACCEPT
 
 Section 3.1 change 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:
 
 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
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
 
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."
 
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.
 
LMM_LC7 
 
Proposed Change:  IESG NITS
 
Propose to ACCEPT: YES!  used msft word and saved as text - where
at least formating problems arose.
 
Other nits:
         - Move ref [1] to intro and refer to it for more detailed
           analysis.
         - [8] is not referenced.
 
LMM_LC8
 
Question:  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.
 
ACCEPT:
 
Propose to change title to:
   Requirements for Mobile IP Localized Mobility Management

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 31 Oct 2003 14:03:49 -0500

fyi... There may be duplication of lc comment
email as there was an intial limit on size
of emails (40K).  I resent trying to reduce
size each time until it went through.  But
now Gab approved a few and those are duplicates
(with extra non-essential text removed).

Just assume duplication and respond accordingly
with any feedback you may have.

Carl

Original Message:
-----------------
From: Carl Williams [email-masked]
Date: Fri, 31 Oct 2003 10:59:47 -0800
To: [email-masked]
Subject: [Mipshop] lc comments on LMM requirements

 
 
Propose to ACCEPT
 
LMM_LC2

Propose to ACCEPT
 
 Section 3.1 change to:

LMM_LC3

Propose to ACCEPT
 
In Section 3.4.2 remove:

LMM_LC4

Propose to ACCEPT

 
LMM_LC5

 
Response:
 
Section 3.4.6 states:

 
 
LMM_LC6

Propose to ACCEPT

LMM_LC7 

 
Other nits:
 
LMM_LC8

 
 
LMM_LC9
Propose to Change Title.
 
ACCEPT:

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop