Re: [Last-Call] Intdir telechat review of draft-ietf-dmm-pmipv6-dlif -05

Hi Carlos,

Thanks for your review. Please find inline below my comments.

On Sat, Feb 29, 2020 at 4:15 AM Carlos Pignataro (cpignata) <
[email protected]> wrote:

> Reviewer: Carlos Pignataro
> Review result: Ready with Nits
>
> 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 defines distributed mobility anchoring, in terms of the
> different configurations and functions to provide IP mobility support,
> including network-based or host-based mobility support.
>
> The intended status is Informational. It is a very well written and
> comprehensive
> document. It is technically sound.
>
> No major or minor issues.
>
> Nits:
>
> A set of small nits for your consideration.
>
> 1.  Introduction
>
>    As a Mobile Node (MN) attaches to an access router and establishes a
>    link between them, a /64 IPv6 prefix anchored to the router may be
>    assigned to the link for exclusive use by the MN [RFC6459].  The MN
>    may then configure a global IPv6 address from this prefix and use it
>    as the source IP address in a flow to communicate with its
>    correspondent node (CN).
>
> Capitalize:
> s/correspondent node/Correspondent Node/
>
> 2.  Conventions and Terminology
>
>    These include terms such as mobile node (MN), correspondent node
>    (CN), home agent (HA), home address (HoA), care-of-address (CoA),
>    local mobility anchor (LMA), and mobile access gateway (MAG).
>
> Capitalize “Mobile Node” (as per § 1), “Corespondent Node”, etc.
>
> Similar within this same § 2, “mobile router”, etc.
> Same throughout the document (e.g., “router advertisement (RA)”)
>
> 4.3.  Mobility case, anchor relocation
>
>    The IP prefix/address anchoring may move without changing the IP
>    prefix/address of the flow.  Here the LM and FM functions in Figure 1
>    in Section 3.1 are implemented as shown in Figure 7.
>
> “Figure 1 in Section 3.1.1 are implemented”
>
>                          Figure 7: Anchor mobility
>
> Should this figure’s label be “Anchor Relocation” instead of ‘Anchor
> mobility”?
>
> 5.  Security Considerations
>
>    As stated in [RFC7333], "a DMM solution MUST supportany security
>
> s/supportany/support any/
>
> 8.2. Informative References
>
> The relationship of this document and draft-ietf-dmm-deployment-models is
> mostly clear, thank you for that.
>
> I hope you fid these comments useful.
>
> Carlos Pignataro.
>
>
> https://tools.ietf.org/html/draft-ietf-dmm-pmipv6-dlif-05
>
> 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.
>

[CB] I've replaced "Reser" with "Rsrvd". The other flags are defined in
other RFCs, published after RFC 5213. Do I need to explain what each of
these flags do in this document? In any case, there might be additional
flags defined in the future, so I think it is not needed.


>
> 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.
>

[CB] Same as before. Additional flags were defined and added to IANA
registry after RFC 5213 was published. I refer to RFC 5213 as it is where
the actual PBU/PBA format was specified (although they are basically BU/BA
with P flag set to 1).


> 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”.
>

[CB] OK, I see that RFC 6275 uses only "octet", while RFC 5213 uses both
"octet" and "byte". But I agree that using only one is the right thing to
do. I've chosen "octet" as you suggested.


>
> 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.
>

[CB] I've added some additional text, but following the approach of RFC
5213, which keeps it simple. I hope this is sufficient.


> 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 🙂
>

[CB] We assume that using the mechanisms described for RFC 5213 is enough.
We have added some additional considerations for the risks/procedures that
are specific to the distributed solution.


> 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?
>

[CB] Since this document is not going to be progressed any further, we have
included the relevant terms in the terminology section and remove the
reference.


>
>    [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?
>

[CB] I don't have a strong opinion here. I've moved it to Normative, but I
think it could stay as Informative as well.


> 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?
>

[CB] Based also on other comments we have remove both appendixes.


> I hope these comments are useful.
>

[CB] Yes, they are indeed. Thanks!

Carlos


>
> Thank you very much,
>
> Carlos Pignataro.

_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm