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

[Barry Leiba <[e-mail]>]

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.

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

Barry