Subject: [Mip4] reg-tunnel Appendix A

From: Pete McCann <[email-masked]>
Date: Fri, 4 Nov 2005 11:34:39 -0600

The attached review of Appendix A of the reg-tunnel draft was done by
Hesham back in September.  Our apologies for not forwarding it sooner.

The suggestion is made to remove the appendix.  Please post opinions
to the list.

-Pete

Subject: RE: draft-ietf-mip4-reg-tunnel
From: "Soliman, Hesham" <[email-masked]>
To: "Henrik Levkowetz" <[email-masked]>
Cc: "Pete McCann" <[email-masked]>
Date: Thu, 29 Sep 2005 11:25:13 -0400

Hi Henrik and Pete, 

Notes to the editor (chairs) :) :
This is more of a research paper than an appendix to a draft. 
It depends on many components that don't exist today. It would
probably be less confusing to the draft if it were removed.
Anyway, here is my review. 

thx, 
Hesham

General:

The appendix depends heavily on the [route optim] spec, 
which is non-existent at this point. So I wonder if this
is helpful for understanding the apendix and making it work
one day. I don't think it is. 
Also, the appendix relies on many assumptions that are not
practically solveable today. For instance, there is no
concrete proposal for the FA-R/G/FA security issues. This 
is brushed over in the text. 
Finally, the colocated CoA case is a bit vague and needs to
be made sharper. 
All this makes me see this appendix differently from other 
appendices in other drafts. Typically, the appendix presents
future extensions, further explanations or detailed processing
of protocol messages. But this one doesn't fall into any of 
the above. It is presenting an idea that can't really be done
based on this spec because it needs several other 
specs to be available before it can happen. More importantly, 
the need for such idea is not clear. 

I think the appendix can be removed without having any effect
on the draft; removing it might have a positive effect actually.

In any case, more specific comments:

- Assumptions about inter FA security and distribution of keys seem
vague. How can this be done today?

- The reference to [route optim] might be a bit confusing given that
this is no longer work in progress. Thoughts?

- Should it be clearly stated that an FA cannot be connected to 
more than one tree of FAs?  I.e. there can be no overlap
between the "GFA domains"? It seems to me like this is not doable
because it will make it difficult to announce all CoAs in the 
FAA. 

End of page 33 :
"It SHOULD then add, for instance, a new FA-FA Key
   Reply extension to the Registration Reply message, before relaying it
   to the next foreign agent"

Remove "for instance".

section 5:

" If a mobile node uses a co-located care-of address, it MAY use
   Regional Registrations directly to the GFA (see Section 4.1 and
   Section 5).  It MAY also use the same method to make use of multiple
   levels of Foreign Agents, if it can find out about the hierarchy,
   either from Mobility Agent Advertisements, or in some other way
   outside the scope of this specification.

This is really vague. How can it make use of multiple levels of 
FAs? Assume that it found out the hierarchy from the FAA, what 
does it do ? I think this point is key. If this specification
assumes that multiple levels of FAs is a good thing then it should
be doable with colocated or non-colocated CoAs. But it looks like it's
very difficult to do that for the colocated case. 

Section 6:

   "In case of decapsulation and re-encapsulation, it should be noted
   that the actual decapsulation need not occur at each step of the
   hierarchy.  Instead, the foreign agent at that level can merely
   change the source and destination IP addresses of the encapsulating
   IP header." 

This is a bit vague as well. I guess you mean change the src 
and dst addresses of the *outer* header? 
Also the paragraph is worded in a way that makes it sound like encapsulation
is optional "In case of decapsulation....". 

 > -----Original Message-----
 > From: Henrik Levkowetz [mailto:[email-masked]]
 > Sent: Tuesday, September 13, 2005 7:11 AM
 > To: Soliman, Hesham
 > Cc: Pete McCann
 > Subject: draft-ietf-mip4-reg-tunnel
 > 
 > 
 > Hi Hesham,
 > 
 >     At the MIP4 WG meeting, you promised to review appendix A of
 > this draft.  Margaret is now nudging the authors, and we need the
 > review in order to complete the editing.  Do you think you could
 > could do this review fairly soon?
 > 
 > Link:
 >    http://tools.ietf.org/id/draft-ietf-mip4-reg-tunnel-00.txt
 > 
 > 
 > Regards,
 > 
 > 	Henrik
 > 

===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is strictly
 prohibited.  If you are not the intended recipient please contact the sender
 and delete all copies.
===========================================================
-- 
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/