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

[Barry Leiba <[e-mail]>]

The new text looks great; thanks!

Barry

On Mon, Aug 3, 2020 at 12:26 PM CARLOS JESUS BERNARDOS CANO
<[e-mail]> wrote:
>
> Hi Barry,
>
> Thanks! Please see inline below.
>
> On Fri, Jul 31, 2020 at 9:42 PM Barry Leiba <[e-mail]> 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