[Mip6] Review of draft-irtf-mobopts-ro-enhancements-00

Samita Chakrabarti <Samita.Chakrabarti@eng.sun.com> Thu, 02 June 2005 03:23 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdgIh-0003Hg-Mt; Wed, 01 Jun 2005 23:23:19 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdgIf-0003HO-D8; Wed, 01 Jun 2005 23:23:17 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05194; Wed, 1 Jun 2005 23:23:12 -0400 (EDT)
Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdgcX-0008OE-2x; Wed, 01 Jun 2005 23:43:52 -0400
Received: from jurassic.eng.sun.com ([129.146.58.37]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j523N9Kg013472; Wed, 1 Jun 2005 20:23:09 -0700 (PDT)
Received: from shubho (shubho.SFBay.Sun.COM [129.146.74.85]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with SMTP id j523N9bI548231; Wed, 1 Jun 2005 20:23:09 -0700 (PDT)
Message-Id: <200506020323.j523N9bI548231@jurassic.eng.sun.com>
Date: Wed, 01 Jun 2005 20:22:57 -0700
From: Samita Chakrabarti <Samita.Chakrabarti@eng.sun.com>
To: jari.arkko@piuha.net, chvogt@tm.uka.de
MIME-Version: 1.0
Content-Type: TEXT/plain; charset="us-ascii"
Content-MD5: 52WeRDTMpz+fAovmy8baIg==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6 SunOS 5.10 sun4u sparc
X-Spam-Score: 2.4 (++)
X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2
Cc: mip6@ietf.org, mobopts@irtf.org
Subject: [Mip6] Review of draft-irtf-mobopts-ro-enhancements-00
X-BeenThere: mip6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Samita Chakrabarti <Samita.Chakrabarti@eng.sun.com>
List-Id: mip6.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mip6>, <mailto:mip6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mip6@ietf.org>
List-Help: <mailto:mip6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mip6>, <mailto:mip6-request@ietf.org?subject=subscribe>
Sender: mip6-bounces@ietf.org
Errors-To: mip6-bounces@ietf.org

Hello:

As per Basavaraj's request, I am posting my comments on this draft.

Thanks,
-Samita
---------------------------------------------------------------------------

Overall: This document has a lot of information of which significant part can 
         go to the appendix for details. Please shorten this draft. Currently,
         it is too long; at the end the reader can easily forget the purpose.
         This draft needs an editorial change for clear objectives/goals,
         list of deployable proposals and analysis of the suggested ones.
         Again, some more data to show when and how RO might be useful in 
         certain applications would be useful. 

section 1:
  " Mobile IPv6 [29], its
   IPv4 counterpart [28], and the Host Identity Protocol [9] are three
   dominant mobility-management protocols that the IETF has developed to
   facilitate the continued use of existing transport protocols and
   applications in an Internet with mobility support."

   Reference [9] refers to the 00 version of hip draft. At the present,
   both MIP6 and MIP4 are in more mature state than HIP. This sentence
   could be reworded to say something like "additionally  IETF is developing
   Host Identity Protocol [9] for mobility management".
 

   Typo :  Page 5 : s/has send/has sent/
           Page 6: s/lightway/lightweight/


section 2:

     Like to see the description in this section be a bit short and concise.
     Refering to draft-ietf-mip6-ro-sec makes sense to shorten
     this section.


Section 3.1:
       Like the diagram.
       3.2:
        s/could built/could build/
        Please shorten this section

      3.3:        
      "tree types" - three types?
        Here is a good place to refer to ro-sec document and point to certain
        sections of that document.

  Section 4.
         This paragraph is not clear. Please list the three items (latency,
         signalling and security improvement) as goals for clear readability.

   4.1 Last line could be:
       The delays introduced by the rest of the stack can be significant(see
        Section 6.3.1).
 4.2
      s/section Section 3/Section 3/

     "For example, of the 716 Mbps signaling
   overhead generated by 100 million route-optimized mobile nodes, 220
   Mbps goes through a home agent."

   Is this a deployment scenario? 100 milllion MNs per one HA?

Section 5.1 and 5.2

 Not clear about the enhancement of using "IP-address test" and "Protected 
Tunnel".
 Does it suggest a separate IP-address test other than HoTI COTI ?
 Is the "protected tunnel" between MN and CN - not sure what message these two
sections are carrying.

Section 5.3:

  After successful BU to HA, the MN-HA tunnel is created if it is not a refresh.
  So, how does the MN send optimistic RO to CN using Hoti msg while the tunnel
  is not configured yet ?

Section 5.5 :

   Please use a diagram to describe concurrency. It is too much text to follow.

Section 5.12 - 5.17:

   There are too many options to confuse the reader. Why do we need to list so
   many of them ? I think, mobopts draft should pick the strong improvement
  alternatives and list them in the main section. The rest should go to the
  appendix in a concise form. It has got too much information to process.

Section 6;
 What are the criteria to evaluate recent proposals?
 If section 5 lists all the proposals in much abbreviated form, then it'd
 be nice if this section analyzes the primary proposals in a concise manner.



_______________________________________________
Mip6 mailing list
Mip6@ietf.org
https://www1.ietf.org/mailman/listinfo/mip6