[MEXT] review of draft-gundavelli-mext-dsmip-ipv4-overlap-01

Hi,

In beijing meeting I volunteered to review draft-gundavelli-mext-dsmip-ipv4-overlap-01.

Some content concerning comments follow.

      address is not uniquely assigned to a single mobile node.  The
      home agent MUST make the forwarding decision based on the context
      identifier that is associated with the received packet and the
      context identifier in the Binding Cache entry.

This is an implementation issue.. entirely. It can be a context identifier (any kind that suffices for the purpose) or the whole HA instance can be running in a separate routing context.

   o  In deployments where the home agent is supporting hosted home
      agent service model, the context identifier field of the Binding
      Cache entry MUST be set to the identifier of the tunnel
      established between the home agent and the enterprise gateway.

Implementation issue again. I do not see why the HA or binding cache internal implementation is enforced here using RFC2119 language. 

Actually most material in Section 4.1.2. Signaling Considerations are purely internal to HA implementation. I do not really see a compelling reason why to document these. In past when we standardized GRE encap for PMIP6 that had similar concerns regarding the LMA. However, that was a different case as we got an impact also on wire and specification of new signaling.

In Section 4.2.  Mobile Node Considerations it is stated:

   This specification does not introduce any new considerations for the
   mobile node implementation.  The IPv4 private address assigned from

If this document has no on wire protocol implications, then there is no interoperability issues from the protocol point of view. The HA product either supports overlapping private addresses or does not. Therefore, I cannot really see why the document aims to be a Proposed Standard? It could be Informational if these points of the HA internal workings has to be documented. So, I would say that Informational without any RFC2119 language is OK.

      However, the assigned addresses MUST be unique within the 3GPP APN
      scope (Ex: @internetsvcs.cisco.com).  The default value for this

I would give a reference to APN and a short description of it as APN is such an alien concept within IETF. Also the example "@internetsvcs.cisco.com" is incorrect if it attempts to give an example of an APN (there is no '@' in APN).


- Jouni