Subject: Re: [dhcwg] Barry Leiba's No Objection on draft-ietf-dhc-slap-quadrant-09: (with COMMENT)

From: CARLOS JESUS BERNARDOS CANO <[email-masked]>
Date: Fri, 31 Jul 2020 18:56:13 +0200

Dear Barry,

Thanks a lot for your review. Apologies for my belated reply. Please see
comments inline below.

Changes have been made in version -10, to be posted soon.

On Tue, Jun 9, 2020 at 3:44 AM Barry Leiba via Datatracker <[email-masked]>
wrote:

> Barry Leiba has entered the following ballot position for
> draft-ietf-dhc-slap-quadrant-09: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dhc-slap-quadrant/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> — Abstract —
>
>    The IEEE is working on mechanisms to allocate addresses in the one of
>    these quadrants (IEEE 802.1CQ).
>
> Nit: change “in the one of” to “in one of”.
>

[Carlos] Thanks. This part of the abstract has been slightly refined also
as part of another comment.

>
>    given client out of the quadrant requested by relay or client.
>
> Nit: make it “by the relay or client.”
>

[Carlos] Thanks. Same as above. This part of the abstract has been slightly
refined also as part of another comment.

>
> — Section 1 —
>
>       Multicast
>       IPv6 packets use a destination address starting in 33-33 and this
>       falls within this space and therefore should not be used to avoid
>       conflict with the MAC addresses used for use with IPv6 multicast
>       addresses.
>
> There are multiple problems with this sentence, starting with its being too
> long.  I suggest this (but please correct this if I got it wrong):
>
> NEW
>       Multicast
>       IPv6 packets use a destination address starting with 33-33, which
>       falls within the AAI quadrant.  Those addresses should not be used,
>       in order to avoid conflict with the MAC addresses used for IPv6
>       multicast.
> END
>
> [Carlos] This part has been rewritten and simplified. Now it reads:

   o  In SLAP Quadrant 00, "Administratively Assigned Identifier" (AAI)
      MAC addresses are assigned locally by an administrator.  Multicast
      IPv6 packets use a destination address starting in 33-33, so AAI
      addresses in that range should not be assigned.  For 48-bit MAC
      addresses, 44 bits are available.

>    o  Quadrant "Reserved for future use" where MAC addresses may be
>
> Nit: remove “where”.
>

[Carlos] Why should I remove it? Current text reads:

   o  SLAP Quadrant 10 is "Reserved for future use" where MAC addresses
      may be assigned using new methods yet to be defined, or until then
      by an administrator as in the AAI quadrant.  For 48-bit MAC
      addresses, 44 bits would be available.

>
> — Section 1.1 —
>
>    allocates the MAC address to the given client out of the quadrant
>    requested by relay or client.
>
> Nit: make it “by the relay or client.”
>

[Carlos] Fixed, thanks.

>
> — Section 3 —
>
>    o  Type of IoT deployment: e.g., industrial, domestic, rural, etc.
>       For small deployments, such as domestic ones, the IoT itself can
>
> Twice in this paragraph you say “the IoT”, when I think you mean “the IoT
> device”.
>

[Carlos] Yes, right. Thanks.

>
>    IoT devices are typically very resource constrained, so
>    there may only be simple decision making process
>
> Make it “be a simple decision-making process”
>

[Carlos] OK, thanks.

>
>    If we now take the WiFi device scenario, considering for example that
>    a laptop or smartphone connects to a network using its built in MAC
>    address.
>
> This is not a complete sentence; please make it one.
>

[Carlos] Fixed, thanks.

>
>    Besides,
>    changing the SLAP quadrant used might also be used as an additional
>    enhancement to make it harder to track the user location.
>
> This is awkward, “used might also be used”.  I suggest, “...changing the
> SLAP
> quadrant might also...”.
>

[Carlos] OK, thanks.

>
>    SLAP quadrant using information provided by the cloud management
>    system (CMS) or virtualization infrastructure manager (VIM) running
>
> Neither abbreviation is used elsewhere in this document, so I suggest
> removing
> both “(CMS)” and “(VIM)”.
>

[Carlos] Done.

>
>       as some quadrants are
>       better suited (e.g., ELI/SAI) for supporting migration in a large
>
> The parenthetical is misplaced and interrupts the sentence flow.
>

> NEW
>       as some quadrants (ELI and SAI) are
>       better suited for supporting migration in a large
> END
>
> or, better still:
>
> NEW
>       as the ELI and SAI quadrants are
>       better suited for supporting migration in a large
> END
>
>
[Carlos] Fixed, thanks.

>    o  VM connectivity characteristics , e.g.,: standalone, part of a
>
> Nit: punctuation around “e.g.” is wrong:
>
> NEW
>    o  VM connectivity characteristics, e.g., standalone, part of a
> END
>

[Carlos] Fixed, thanks.

>
> — Section 4.1 —
>
>       The client SHOULD NOT pick a server that does not
>        advertise an address in the requested quadrant.
>
> This SHOULD NOT doesn’t make sense to me.  Why would it?  What would be an
> informed reason to pick one that doesn’t have what it wants?  Is there a
> reason
> not to just say, “The client will pick a server that advertises an address
> in
> the quadrant the client requested,” without using BCP 14 key words?
>
> [Carlos] We wrote in that way to leave freedom for cases in which maybe
there are no servers that have what the client wants (or better, prefers)
and still allow the client to get an address allocation from a server.

Thanks again,

Carlos

---

From: Barry Leiba <[email-masked]>
Date: Fri, 31 Jul 2020 15:42:44 -0400

Thanks for the reply, Carlos.  Just responding to the two items for
which there are questions -- and keep in mind that my comments are
suggestions, and that you should do as you think best.

>       addresses, 44 bits would be available.

If you've changed the list text this comment might not apply any more,
but I suggested removing "where" because it makes that item different
from all the others in the list.  In -09, the list looks like this:

   o  Quadrant "Extended Local Identifier" (ELI) MAC addresses are
      assigned based on a Company ID (CID)

   o  Quadrant "Standard Assigned Identifier" (SAI) MAC addresses are
      assigned based on a protocol specified in an IEEE 802 standard.

   o  Quadrant "Administratively Assigned Identifier" (AAI) MAC
      addresses are assigned locally by an administrator.

   o  Quadrant "Reserved for future use" where MAC addresses may be
      assigned using new methods yet to be defined

Why does the last one have "where", and the first three don't?  The
nit I noted was just the lack of parallelism, that's all.

>> informed reason to pick one that doesn’t have what it wants?  Is there a reason
>> not to just say, “The client will pick a server that advertises an address in
> [Carlos] We wrote in that way to leave freedom for cases in which maybe there are no
> servers that have what the client wants (or better, prefers) and still allow the client to
> get an address allocation from a server.

It might be good, then, to explain that briefly: the text that's there
simply says what I quote above, with no explanation, and says nothing
about what the client might want or prefer.  So when I read it, I say
to myself, "If I ask for an address in a specific quadrant, why would
I pick a server that doesn't have one?"  Maybe it's just as simple as,
"The client will pick a server that advertises an address in the
quadrant the client requested, unless no server advertises one."  Or
maybe the "SHOULD NOT" is fine with a brief explanation.  Or maybe
readers will just understand this, and I'm blowing smoke: as I said,
do as you think best.

Barry