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

[CARLOS JESUS BERNARDOS CANO <[e-mail]>]

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 <[e-mail]>
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