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: Mon, 3 Aug 2020 18:25:28 +0200

Hi Barry,

Thanks! Please see inline below.

On Fri, Jul 31, 2020 at 9:42 PM Barry Leiba <[email-masked]> wrote:

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

[Carlos] Current text (in -10 to be submitted) is the following:

-8-<-
   o  In SLAP Quadrant 01, "Extended Local Identifier" (ELI) MAC
      addresses are assigned based on a 24-bit Company ID (CID),
      assigned by the IEEE Registration Authority (RA).  The remaining
      bits are specified as an extension by the CID assignee or by a
      protocol designated by the CID assignee.

   o  In SLAP Quadrant 11, "Standard Assigned Identifier" (SAI) MAC
      addresses are assigned based on a protocol specified in an IEEE
      802 standard.  For 48-bit MAC addresses, 44 bits are available.
      Multiple protocols for assigning SAIs may be specified in IEEE
      standards.  Coexistence of multiple protocols may be supported by
      limiting the subspace available for assignment by each protocol.

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

The last one is a bit different because it is the quadrant that is reserved
for future use.

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

[Carlos] OK, I see your point. I still think I'm going to keep the current
text.

Thanks a lot!

Carlos

> Barry

---

From: Barry Leiba <[email-masked]>
Date: Mon, 3 Aug 2020 12:45:25 -0400

The new text looks great; thanks!

Barry

On Mon, Aug 3, 2020 at 12:26 PM CARLOS JESUS BERNARDOS CANO
<[email-masked]> wrote:
> The last one is a bit different because it is the quadrant that is reserved for future use.
>
>>
>> >> — Section 4.1 —
>> >>
>> >> 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
>> > [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
> [Carlos] OK, I see your point. I still think I'm going to keep the current text.
>
> Thanks a lot!
>
> Carlos
>
>>
>>
>> Barry