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

From: CARLOS JESUS BERNARDOS CANO <[email-masked]>
Date: Sun, 8 Mar 2020 19:43:00 +0100

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

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 12 Mar 2020 05:00:31 +0000

Hi, Carlos,

Thanks for the response! Please see inline, prefaced with CMP.

2020/03/08 午後0:43、CARLOS JESUS BERNARDOS CANO <[email-masked]<mailto:[email-masked]>>のメール:

Hi Carlos,

On Sat, Feb 29, 2020 at 4:15 AM Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> 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.

The intended status is Informational. It is a very well written and comprehensive
document. It is technically sound.

Nits:

1.  Introduction

Capitalize:

Should this figure’s label be “Anchor Relocation” instead of ‘Anchor mobility”?

The relationship of this document and draft-ietf-dmm-deployment-models is mostly clear, thank you for that.

Carlos Pignataro.

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.

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

Nits:

   0               1               2               3

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

…

   0                   1                   2                   3

However, from RFC 5213:

       0                   1                   2                   3

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

   Anchored Prefix

Not being pedantic, but:

[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

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.

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.

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.

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

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

Ack.

:-) Super.

(Another) Carlos.

Carlos

Thank you very much,

Carlos Pignataro.

---

From: CARLOS JESUS BERNARDOS CANO <[email-masked]>
Date: Thu, 12 Mar 2020 09:56:09 +0100

Hi Carlos,

Thanks again. Short comment below.

On Thu, Mar 12, 2020 at 6:00 AM Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> 2020/03/08 午後0:43、CARLOS JESUS BERNARDOS CANO <[email-masked]>のメール:
>
> Hi Carlos,
>
> 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.
>
> [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

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

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 12 Mar 2020 12:59:57 +0000

That would work great, Carlos. Many thanks for the quick response, and addressing all my review comments!

Carlos.

2020/03/12 午前4:56、CARLOS JESUS BERNARDOS CANO <[email-masked]<mailto:[email-masked]>>のメール:

Hi Carlos,

On Thu, Mar 12, 2020 at 6:00 AM Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Carlos,

Hi Carlos,

Nits:

1.  Introduction

Capitalize:

Carlos Pignataro.

Nits:

   0               1               2               3

[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

…

   0                   1                   2                   3

However, from RFC 5213:

       0                   1                   2                   3

   Anchored Prefix

Not being pedantic, but:

5.  IANA Considerations

Thank you.

Ack.

Got it.

Ack.

:-) Super.

(Another) Carlos.

Carlos

Thank you very much,

Carlos Pignataro.