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
