Telechat Review of draft-ietf-dmm-pmipv6-dlif-05
review-ietf-dmm-pmipv6-dlif-05-intdir-telechat-pignataro-2020-02-28-01

Request Review of draft-ietf-dmm-pmipv6-dlif
Requested rev. no specific revision (document currently at 06)
Type Telechat Review
Team Internet Area Directorate (intdir)
Deadline 2020-03-03
Requested 2020-02-19
Requested by Éric Vyncke
Authors Carlos Bernardos, Antonio de la Oliva, Fabio Giust, Juan-Carlos Zúñiga, Alain Mourad
Draft last updated 2020-02-28
Completed reviews Tsvart Last Call review of -04 by Joerg Ott (diff)
Secdir Last Call review of -04 by Vincent Roca (diff)
Genart Last Call review of -04 by Ines Robles (diff)
Intdir Telechat review of -05 by Carlos Pignataro (diff)
Secdir Telechat review of -05 by Vincent Roca (diff)
Comments
Thank you very much in advance for the review from the Internet area point of view, please try to have the same reviewers for the two DMM documents
Assignment Reviewer Carlos Pignataro 
State Completed
Review review-ietf-dmm-pmipv6-dlif-05-intdir-telechat-pignataro-2020-02-28
Reviewed rev. 05 (document currently at 06)
Review result Ready with Nits
Review completed: 2020-02-28

Review
review-ietf-dmm-pmipv6-dlif-05-intdir-telechat-pignataro-2020-02-28

I am an assigned INT directorate reviewer for this Internet-Draft.  These
comments were written primarily for the benefit of the Internet Area Directors.
Document editors and shepherd(s) should treat these comments just like they
would treat comments from any other IETF contributors and resolve them along
with any other Last Call comments that have been received. For more details on
the INT Directorate, see http://www.ietf.org/iesg/directorate.html.

I hope these comments are clear and useful.

As requested, from the Internet area Directorate review, these two DMM 
documents are being reviewed together: 
* draft-ietf-dmm-distributed-mobility-anchoring-14
* draft-ietf-dmm-pmipv6-dlif-05

This document provides an approach to distributed mobility management
by extending network-based mobility protocols (like Proxy Mobile IPv6). In
this solution, mobility sessions are anchored at the last IP hop router. 

This document’s intended status is Experimental. It is well written for such a complex comprehensive document, and technically complete and sensible.

No major or minor issues.

Nits:

Please find some small comments for your consideration:


4.1.  Proxy Binding Update

   A new flag (D) is included in the Proxy Binding Update to indicate
   that the Proxy Binding Update is coming from a Mobility Anchor and
   Access Router and not from a mobile access gateway.  The rest of the
   Proxy Binding Update format remains the same as defined in [RFC5213].

   0               1               2               3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |            Sequence #         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |A|H|L|K|M|R|P|F|T|B|S|D| Reser |            Lifetime           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

However, for RFC 5213 S 8.1:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |A|H|L|K|M|R|P|  Reserved       |            Lifetime           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

So, therefore, seems like:
1. The definition of Flags F, T, B, and S is missing.
2. “Reser” is not really clear and “Rsrvd” seems to fit and be more unambiguous.

4.2.  Proxy Binding Acknowledgment

…
  The rest of the Proxy Binding Acknowledgment format
   remains the same as defined in [RFC5213].

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |   Status      |K|R|P|T|B|S|D| |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

However, from RFC 5213:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      |   Status      |K|R|P|Reserved |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

And thus, Flags T, B, S are not defined.

4.3.  Anchored Prefix Option

   Anchored Prefix

      A sixteen-byte field containing the mobile node's IPv6 Anchored
      Prefix.  Only the first Prefix Length bytes are valid for the
      Anchored Prefix.  The rest of the bytes MUST be ignored.

Not being pedantic, but:
s/byte/octet/g // throughout.
Or… "128-bit” instead of “sixteen-octet”.


5.  IANA Considerations

   This document defines six new mobility options that need to be
   registered in the Mobility Options registry on the Mobile IPv6
   parameters registry.  The required IANA actions are marked as IANA-1
   to IANA-6.

It would be useful to breakout the specific IANA requests in a table, sections, or other structure detailing how it should look in the IANA registries.

6. Security Considerations

Is there underlying protection against spoofing that can be called out? This should be addressed in the Security Dir review, so I will not mention it here  :-)

8.2.  Informative References

   [I-D.ietf-dmm-deployment-models]
              Gundavelli, S. and S. Jeon, "DMM Deployment Models and
              Architectural Considerations", draft-ietf-dmm-deployment-
              models-04 (work in progress), May 2018.

Since there are key definitions from this document, should this be Normative?

   [RFC7333]  Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J.
              Korhonen, "Requirements for Distributed Mobility
              Management", RFC 7333, DOI 10.17487/RFC7333, August 2014,
              <https://www.rfc-editor.org/info/rfc7333>.

Similarly, should this reference be Normative instead of Informative?

Appendix B.  Implementation experience

Should this really be an Implementation Status section [RFC7942], as it describes a point in time rather than learnings?

Should the Appendices clarify they make no normative specs?

I hope these comments are useful.

Thank you very much,

Carlos Pignataro.