Subject: [Mip6] AD review of draft-ietf-mip6-dsmip-problem-02.txt

From: Jari Arkko <[email-masked]>
Date: Fri, 29 Dec 2006 16:38:07 +0200

Hi all,

I reviewed this document. While I agree with
its conclusions, the draft still needs another
revision.

Here are the detailed comments:

Technical:
>    - Double the amount of configuration in the mobile node and the home
>
>      agent (e.g., security associations). 
... and later ...
>    In addition, deploying both protocols will require duplication of
>    security credentials on mobile nodes and home agents. This includes,
>    IPsec security associations, keying material, and new authentication
>    protocols for Mobile IPv6, in addition to the security credentials
>    and associations required by Mobile IPv4. Such duplication is again
>    significant with no gain to the operator or the mobile node.
 
Is this true under all circumstances? For instance,
is it true if one uses RFC 4285 or EAP for Mobile IPv6
authentication?

Depending on the answer, please reword
and add the necessary explanations.
>    - Local network optimizations for handovers will also need to be 
>      duplicated.
Only insofar as  they are bound to the mobility
protocol. There are a large number of optimizations
(L2 pre-auth etc) that deal with other aspects of the
handover problem and do not impact what happens
at IP or IP mobility layers.

Please reword.
> 3.1. Implementation burdens
>    
>    As mentioned above, a node that is IPv4 and IPv6 capable must also be
>
>    MIPv4 and MIPv6 capable to roam within the Internet. Clearly this
>    will add implementation efforts, which, we argue, are not necessary.
>
>    
>    In addition to the implementation efforts, some vendors may not
>    support both protocols in either mobile nodes or home agents.
>    Although this is more of a commercial issue, it does affect the
>    large-scale deployment of mobile devices on the Internet. 
>     
I'm not sure this section reflects the complete
picture. In a situation where host vendors
are independent of those who deploy the
mobility infrastructure, for instance, its
not clear that there is any reduction in
implementation effort.

Please reword for better balance.
 
>   Checking nits according to http://www.ietf.org/ID-Checklist.html:
>   * The document seems to lack a Security Considerations section.
>   

This is needed (not just the section but the
content as well).

>    Further work in this area, possibly independent of Mobile IP, may
>    also be of interest to some parties in which case it should be dealt
>    with separately from the incremental Mobile IP based changes.
This statement seems out of place. Or at least I could
not think of what specific further work you were thinking
of.
> 3.0 Problem description 
I am missing an explanation of why various existing,
non-mobility related transition mechanisms are insufficient
for solving the issues listed in this document. I believe
they are insufficient, but the document needs to explain
why.

Please add the explanation.

Editorial:

Overall, this document needs an editorial
cleanup and better formatting. Random
linefeeds in particular are making it hard
to read.
> 1. Terminology
>    
>    In addition to [KEYWORDS], this draft uses the following terms as
You do not use any keywords.
>   * The document seems to lack an IANA Considerations section.
>   
This is optional, but I normally insert a "There are no IANA
considerations." text just to make it clear that the IANA does
not have to read the entire document.
>   * The document seems to lack separate sections for Informative/Normative
>     References.
>   
This is needed.
>     
>     Checking conformance with RFC 3978/3979 boilerplate...
>
>   * The document seems to lack an RFC 3978 Section 5.5 Disclaimer -- however,
>     there's a paragraph with a matching beginning. Boilerplate error?
>   * The document seems to lack an RFC 3979 Section 5, para 1 IPR Disclosure
>     Acknowledgement -- however, there's a paragraph with a matching beginning.
>     Boilerplate error?
>   * The document seems to lack an RFC 3979 Section 5, para 2 IPR Disclosure
>     Acknowledgement -- however, there's a paragraph with a matching beginning.
>     Boilerplate error?
>
>   Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
>   * The document seems to lack a 1id_guidelines paragraph about
>     Internet-Drafts being working documents -- however, there's a paragraph
>     with a matching beginning. Boilerplate error?
>   * The document seems to lack a 1id_guidelines paragraph about 6 months
>     document validity -- however, there's a paragraph with a matching
>     beginning. Boilerplate error?
>   * The document seems to lack a 1id_guidelines paragraph about the list of
>     current Internet-Drafts -- however, there's a paragraph with a matching
>     beginning. Boilerplate error?
>   - The page length should not exceed 58 lines per page, but there was 7
>     longer pages, the longest (page 6) being 68 lines
>   - It seems as if not all pages are separated by form feeds - found 0 form
>     feeds but 7 pages
>   
Hesham, please, move to xml2rfc. Its so much easier
for everyone. You don't need any software, btw,
you can convert to text at xml.resource.org.
>   Miscellaneous warnings:
>   - The "Author's Address" (or "Authors' Addresses") section title is
>     misspelled.
>   
Please fix.

>    We argue that all of the above will hinder the deployment of Mobile
>    IPv6 as well as any dual stack solution in a mobile environment. We
I would suggest saying "makes harder to deploy ..." instead
of "will hinder". This could be just a language issue, but
my understanding is that "hinder" can be interpreted
as "block" -- and I'm not sure I would agree with such
a strong statement.
>    clearly inefficient since it requires: 
s/clearly// (better style)

> Each of these systems 
>      requiring their own sets of optimizations that may include
>      hierarchical Mobile IPv4, hierarchical Mobile IPv6 and Fast 
>      Handoffs for Mobile IPv4, mechanisms that are currently in 
>      development in the IETF. 
The list seems a bit out of place, and somewhat arbitrary.
I would suggest s/optimizations .*/optimizations./

> Deploying both in a dual stack mobile node
> introduces a number of inefficiencies.
s/inefficiencies/problems/ (a pure mip6+mip4 solution
would block either v4 or v6 communications, depending
on which type of access network you are in)
> The draft
>    also hints on how the current [MIPv4] and [MIPv6] protocols could be
>    extended so that they can support mobility management for a dual
>    stack node. 
References in abstract.

Also, I'm not sure you really talk or should talk about the "how"
part. Suggested rewording: "The draft also discusses requirements
for the Mobile IPv4 and Mobile IPv6 protocols so that they can
support ..."

> 2. Introduction and motivation 
This section focuses on the argument that we need
to have one mobility protocol handle both protocol
versions. I would suggest the addition of the basic
connectivity problem explanation before bullet
list.
> 3.4. The impossibility of maintaining IP connectivity 
I would start with this in Section 3.

--Jari

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