Re: [dhcwg] WGLC comments on draft-ietf-dhc-mac-assign-01

["Bernie Volz (volz)" <[e-mail]>]

Hi Tomek:

Some comments on your comments inline below (prefixed by BV>).

I have updated the github repository, but not published an 02 just yet. So, the fixed comments refer to the coming 02 (see the github repository version).

I'll wait a bit to see if you (or anyone else) have any comments regarding this email before publishing the 02 revision.

- Bernie

-----Original Message-----
From: dhcwg <[e-mail]> On Behalf Of Tomek Mrugalski
Sent: Sunday, November 17, 2019 2:48 PM
To: [e-mail]
Subject: [dhcwg] WGLC comments on draft-ietf-dhc-mac-assign-01

Disclaimer: I used to be involved in the draft-ietf-dhc-mac-assign a year ago. I asked the other authors to remove my name from it, but they feel my contributions were significant enough to keep it on.

So it's with my co-chair and co-author hats off, I support this work moving forward. However, I have some comments that should be addressed.

Nitpicks:
Section 6, bullet numbering is wrong (no item 2) Section 6, bullet 3: block of address => block of addresses

BV> Fixed. An earlier version had added ability to request multicast addresses, but that was removed and the bullet numbers were not adjusted (as with XML2RFC V2, we must manually maintain numbered lists).

Section 6 properly explains that the client is supposed to set the valid lifetime field to 0. I'd like to see a text for the other side: the server MUST ignore the valid lifetime value.

BV> OK, the text there said that the server should ignore but I adjusted it to use MUST. Later text also documented that the server MUST ignore:

   In a message sent by a client to a server, the valid lifetime field
   SHOULD be set to 0.  The server MUST ignore any received value.

Nitpick: "a IA_LL" => "an IA_LL". RFC8415 uses an for all IA options.

BV> Fixed.

"The server MAY alter the allocation at this time." This is technically incorrect. Server doesn't have any allocation yet, it's about to make one. Better text would be: "The server allocates block of addresses according to its configured policy. The server MAY assign a different block than requested in the Request message."

BV> Fixed.

Text in section 10.2: "This value can be only sent by a client that requests a new block.". There are two issues with this text. First, I would rephrase this text. The sentence as written now suggests that the only entity allowed to set this field is a client and only under certain circumstances. Maybe something like this: "A client is only allowed to set this value when requesting a new block?". The second problem with this text is that it's not really true, is it? What about renewals?
Client is expected to send the block it already has for renewal.

BV> Fixed. Used " link-layer address that is being requested or renewed, or  a special value to request any address."

"extra-addresses - A four octets long field". Would be useful to clarify that it's an unsigned field encoded in network byte order.

BV> Fixed - add RFC8415 text in all of the placed where integers are used in options.

End of section 10.2: "More than one LLADDR option can appear in an IA_LL option." This seems to be in contradiction with earlier text that says "Therefore, if a client wants more addresses at a later stage, it SHOULD send an IA_LL option with a different IAID to create another "container"
for more addresses.". So what are the circumstances when more than one LLADDR is present in IA_LL? If there are none, perhaps best would be to remove this sentence?

BV> I'm not sure why a "can" contradicts a SHOULD. Just because the usual case would be a single LLADDR (i.e., SHOULD), I don't see why we would need to prohibit having more than one LLADDR (i.e., can). And, we don't really know the use cases someone may have in the future, so I would prefer not to restrict this.  I can see two ways forward - leave as is (perhaps use "MAY" instead of "can") or remove both statements.

BV> Note that SHOULD is:
3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

BV> And MAY is:
5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.
   An implementation which does not include a particular option MUST be
   prepared to interoperate with another implementation which does
   include the option, though perhaps with reduced functionality. In the
   same vein an implementation which does include a particular option
   MUST be prepared to interoperate with another implementation which
   does not include the option (except, of course, for the feature the
   option provides.)

BV> I think the bottom line (just as with IAPREFIX/IAADDR options in IA_PD/IA_NA), a server MUST be able to support multiple instances of these options within a single IA.

Section 13 should probably mentioned that there is no duplicate detection mechanism such as DAD for IPv6. It's not really a problem, though. A malicious node can start using any MAC address and doesn't have to go through the hassles of implementing this protocol.

BV> Hum ... doesn't the paragraph that is there already explain this?

   There is a possibility of the same link-layer address being used by
   more than one device if not all parties on a link use this mechanism
   to obtain a link-layer address from the space assigned to the DHCP
   server.  It is also possible that a bad actor purposely uses a
   device's link-layer address.

I hope to review the second draft in the coming days. Will send a separate mail.

BV> Any comments on the slap-quadrant draft would be appreciated.

Thanks,
Tomek

_______________________________________________
dhcwg mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dhcwg