Subject: [Mipshop] AD review of mipshop-3gfh

From: Jari Arkko <[email-masked]>
Date: Wed, 28 Nov 2007 13:53:26 +0200

I have done my AD review on this document as well. It still
needs work. Here are my comments:

1. References should be updated to point to RFC 4068bis.

2. The spec needs to be clearer about when FMIP procedures are
   needed upon link change, and when not. Is a link change in 3G
   CDMA networks always a subnet change, too? Text several places
   in the document appears to assume this is so.

3. The spec needs to document how it deals with the issues
   from RFC 4907 Section 2.

4. A review from 3GPP2 or experts in 3GPP2 networks is required.

5. I do not understand how it is possible to use the interface
   ID (you mean the IP layer interface ID, right?) in the
   MN-LLA option, as suggested in Section 5.1.

6. I do not understand the instructions in Section 5.1
   regarding UNA. It appears that this draft is disobeying
   a MUST from RFC 4068bis. If UNA is not applicable in all
   cases, is there something that needs to be fixed RFC 4068bis?

7. I do not understand what "SHOULD be confirmed that NAR
   supports this [IPCP] option" means. Confirm how? The delay
   that you try to avoid is part of normal PPP processing, so
   are you expecting something to be done configuration-wise?

8. In the end of Section 5.1, the advantage of being able to
   avoid PPP authentication, RA, etc is brought up. Some of
   these optimizations are potentially very useful, but I would
   argue that it is not the place of FMIP-over-Foo to define
   everything that can be optimized in Foo. It should only
   define how to run FMIP over Foo.

9. The spec needs to talk about the case where L2 indications
   that Section 5.2 relies on are unreliable or turn out to be
   wrong. E.g., the connection was closed but came back to the
   same router again.

10. It is unclear how Steps a-b differ from each other in Sections
    5.1 and 5.2. Step b in the latter says that prefix information
    is not sent. How do the devices know whether reactive or predictive
    mode is being employed? Section 5.1 Step a talks about data that
    the MN needs to attach to the proxy solicitation. Is such data
    required, allowed, or disallowed in Section 5.2 step a?

11. Flows in both Section 5.1 and 5.2 appear to missing the
    security details outlined in mipshop-handover-key.

12. Section 5.3, network controlled handover. This is a possible use
    of the router-to-router messages of FMIP. But would such use follow
    all the requirements in the FMIP spec? I'm not sure the spec has
    all the details, how would the routers know about the interface IDs
    in use by the mobile node, for instance. Also, my read of the charter
    does not include development of network-based version of FMIP.

13. Section 6.1, handover assist information option. I have
    interoperability concerns about this, and in general we should
    not define completely open options. Please replace by a more
    specific option that can carry the information needed for 3GPP2
    network identification, not a container that can carry anything
    by anyone.

14. Section 6.2, the B option. If such instruction for buffering
    is needed, why isn't it a part of the base protocol?

15. Section 7, s/trusting/trust/. Is draft-ietf-mipshop-handover-key
    required or not?

I am expecting a revised draft and answers to the questions above.

Jari

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