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

From: "Tsirtsis, George" <[email-masked]>
Date: Mon, 15 Jan 2007 14:51:46 -0800

Jari, thanks for the review and sorry for the long delay in replying. I
am going over your comments and revising the draft so I think I will
come up with a new draft soon.

Thanks again for the thorough review.
George

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]]
> Sent: Friday, December 29, 2006 9:38 AM
> To: Soliman, Hesham; Tsirtsis, George
> Cc: Mobile IPv6 Mailing List; Mobile IPv4 Mailing List
> Subject: [Mip4] AD review of draft-ietf-mip6-dsmip-problem-02.txt
> 
> 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
> 
> 
> --
> Mip4 mailing list: [email-masked]
>     Web interface: https://www1.ietf.org/mailman/listinfo/mip4
>      Charter page: http://www.ietf.org/html.charters/mip4-charter.html
> Supplemental site: http://www.mip4.org/

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

---

From: "Tsirtsis, George" <[email-masked]>
Date: Wed, 17 Jan 2007 02:12:06 -0800

Hi Jari,

Thanks again for the review. Please find some comments below as well as
some suggestions about how to deal with some of your comments. If you
are ok with these I will publish a new version early next week.

Regards
George

home
includes,
authentication
credentials
again
> and add the necessary explanations.

GT> I believe that, assuming nothing is changed, what the draft says is
accurate since typically applications/protocols can not share keys
unless security is implemented at a lower layer than that of the
application/protocol. Still, I will add something to indicate that for
some of the mechanisms listed and with further work, it might be
possible to optimize operations.

> at IP or IP mobility layers.

GT> I will clarify that we are talking about IP layer optimizations

also be
necessary.
> Please reword for better balance.

GT> OK, I will clarify 

dealt
> not think of what specific further work you were thinking

GT> Ok, I think we can remove this.

> Please add the explanation.

GT> It is a bit difficult to write general negative statements like
this. I will add a section on this and add something generic about the
fact that current transition mechanisms do not seem to deal with
mobility. 

> linefeeds in particular are making it hard

GT> Yes, the XML template corrected all this, sorry about that.

> not have to read the entire document.

GT> I added this in a new IANA section.

> >   * The document seems to lack separate sections for

GT> fixed

error?

> >     Acknowledgement -- however, there's a paragraph with a matching

GT> Fixed

> >     Acknowledgement -- however, there's a paragraph with a matching

GT> Fixed

> >     with a matching beginning. Boilerplate error?

GT> Fixed

months
matching
> >     beginning. Boilerplate error?

GT> Fixed

list
> >     beginning. Boilerplate error?

GT> Fixed

was 7
> >     longer pages, the longest (page 6) being 68 lines

GT> Fixed

0
> >     feeds but 7 pages

GT> Fixed

is
> Please fix.

GT> Fixed

Mobile
We
> as "block" -- and I'm not sure I would agree with such

GT> OK

> s/clearly// (better style)

GT> OK

> I would suggest s/optimizations .*/optimizations./

GT> I will remove the list.

be
> >    extended so that they can support mobility management for a dual

GT> Removed

> for the Mobile IPv4 and Mobile IPv6 protocols so that they can

GT> OK

> connectivity problem explanation before bullet

GT> Added

> I would start with this in Section 3.

GT> Done

---

From: Jari Arkko <[email-masked]>
Date: Wed, 17 Jan 2007 13:19:36 +0200

George,
> possible to optimize operations.
Do you have text? We are not talking about typical applications,
we are talking about a very specific case. And there are many
applications that can share the same credentials through, say,
AAA.
> GT> I will clarify that we are talking about IP layer optimizations
Ok.
>>>    As mentioned above, a node that is IPv4 and IPv6 capable mustalso be
>>>       
>>>    will add implementation efforts, which, we argue, are not necessary.
>>>       
Good. Again, I would like to see the text...
>>>    also be of interest to some parties in which case it should be dealt
>>>       
Good.
> fact that current transition mechanisms do not seem to deal with
Ok. Text needed.

Jari