[dhcwg] Gunter Van de Velde's No Objection on draft-ietf-dhc-addr-notification-11: (with COMMENT)

[Gunter Van de Velde via Datatracker <[e-mail]>]

Gunter Van de Velde has entered the following ballot position for
draft-ietf-dhc-addr-notification-11: 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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dhc-addr-notification/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

# Gunter Van de Velde, RTG AD, comments for draft-ietf-dhc-addr-notification-11

Please find https://www.ietf.org/blog/handling-iesg-ballot-positions/
documenting the handling of ballots.

#GENERIC COMMENTS
#================
## well written draft edited in a nice reading style. Fun to read, especially
the motivation for this work. Fully support this very relevant functionality.

## It is unclear what actions to take when the option-len is set to  value
different as zero, eventhough the document prescribes that the value MUST be 0
(line211)

## In the abstract is written that statically assigned addresses can be
reported. However later in the document only SLAAC seems discussed. For some
reason CGA (RFC3972) type addresses is not mentioned. Not sure that was
intentional or by accident.

#DETAILED COMMENTS
#=================
##classified as [minor] and [major]

117        The lack of this parity with IPv4 is one of the reasons that may be
118        hindering IPv6 deployment, especially in enterprise networks.

[minor] WHile potentially true, i am not convinced that this phrase adds
value for the document. The first paragraph already details well enough
the problem space without the procedure outlined in this draft.

141        address registration.  It can do this by including the Address
142        Registration option code the Option Request option (see Section 21.7
143        of [RFC8415]) of the Information-Request, Solicit, Request, Renew, or
144        Rebind messages it sends to the server as part of the regular

[minor] i am wondering if adding 'within'
s/Registration option code the Option Request/Registration option code within
the Option Request/ would make sense from readability perspective?

147        option in its Reply message.  If the network does not support (or is
148        not willing to receive) any address registration information, the
149        client MUST NOT register any addresses.  Otherwise, the client
150        registers addresses as described below.

[minor] I assume that it is the DHCP server and not the network that may
not support (or i snot willing) to process such information.

152        After successfully assigning a self-generated IPv6 address on one of
153        its interfaces, a client implementing this specification SHOULD

[minor] or statical configured

211         option-len            0

[major] what to do if its not zero?

215        If a client has the address registration mechanism enabled, it SHOULD
216        include this option in all Option Request options that it sends.

[minor] Would a stronger MUST not be justified? Why would a client, which
supports the functionality AND has it enabled not advertise this?

218        A server which is configured to support the address registration
219        mechanism MUST include this option in Reply messages.

[minor] as a response when receiving such option from a client? or
simply always add this option?

223        The DHCPv6 client sends an ADDR-REG-INFORM message to inform that an
224        IPv6 address is in use.  The format of the ADDR-REG-INFORM message is
225        described as follows:

[minor] Is it intended that the address is 'in use' or 'allocated and assigned
by the device on an interface'?

284        The client MUST only send the ADDR-REG-INFORM message for valid
285        ([RFC4862]) addresses of global scope ([RFC4007]).  This includes ULA
286        addresses, which are defined in [RFC4193] to have global scope.  The
287        client MUST NOT send the ADDR-REG-INFORM message for addresses
288        configured by DHCPv6.

[major] In the abstract is written "or statically configured addresses" which
is more then RFC4862 addresses. The text should include the statically
addresses. What about Cryptographically Generated Addresses (CGAs) defined in
RFC 3972?

290        The client SHOULD NOT send the ADDR-REG-INFORM message if it has not
291        received any Router Advertisement message with either M or O flags
292        set to 1.

[minor] This reads difficult because it is a double negative. What about
following rewrite: "The client SHOULD NOT send the ADDR-REG-INFORM message if
it has received no Router Advertisement message with either the M or O flags
set to 1"

298        Servers MUST discard any ADDR-REG-INFORM messages that meet any of
299        the following conditions:

[major] What abot receiving such with length =! 0?

314        If the message is not discarded, the address registration server
315        SHOULD verify that the address being registered is "appropriate to
316        the link" as defined by [RFC8415] or within a prefix delegated to the
317        client.  Otherwise, it MUST drop the message, and SHOULD log this
318        fact.  Otherwise, the server:

[minor] i got thrown offguard with the the construct 'prefix delegated'.
Is this RFC 3633 (IPv6 Prefix Options for Dynamic Host Configuration
Protocol (DHCP) version 6)? i asusme it is not, but in that case maybe
explain what 'prefix delegated' means? if it is RFC3633, maybe add reference.

320        *  SHOULD register or update a binding between the provided Client
321           Identifier and IPv6 address in its database.  The lifetime of the
322           binding is equal to the Valid Lifetime of the address reported by
323           the client.  If there is already a binding between the registered
324           address and another client, the server SHOULD log the fact and
325           update the binding.

[minor] is there any thoughts about managing misbahaving clients
sending 1000000000's of these by accident?

472        We define a function AddrRegRefreshInterval(address) as min(4 hours,
473        80% of the address's current Valid Lifetime).  When calculating this

[minor] who is 'we'? the WG, the authors? the IETF community?