Hi Carlos, Thanks again. Short comment below.
On Thu, Mar 12, 2020 at 6:00 AM Carlos Pignataro (cpignata) < [email protected]> wrote: > Hi, Carlos, > > Thanks for the response! Please see inline, prefaced with CMP. > > 2020/03/08 午後0:43、CARLOS JESUS BERNARDOS CANO <[email protected]>のメール: > > 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. > > > > CMP: The problem I see is that the document currently says: > The rest of the > Proxy Binding Update format remains the same as defined in [RFC5213] > > But based on what you write, that is not the case. > > No, you do not need to explain what each flag does — but I’d suggest > either not say where they are defined, or include the other RFCs. > > I checked IANA and found: > > https://www.iana.org/assignments/mobility-parameters/mobility-parameters.xhtml#mobility-parameters-11 > > [CB] OK, I was referring to the rest of the PBU format in general. I can add that a note referring to the IANA registry for the definition and references of the flags. Would that work? Thanks, Carlos > > >> 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). > > > THanks, I understand. I was commenting on the text that says “the rest is > defined in RFC5213”. > > >> 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. > > > Thanks! As strictly there can be non-octet bytes. > > >> >> 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. > > > Thank you. > > >> 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. > > > Ack. > > >> 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. > > > Got it. > > > >> >> [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. > > > Your call. Thanks for considering. > > >> 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. > > > Ack. > > >> I hope these comments are useful. >> > > [CB] Yes, they are indeed. Thanks! > > > :-) Super. > > (Another) Carlos. > > > Carlos > > >> >> Thank you very much, >> >> Carlos Pignataro. > > >
_______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
