[dhcwg] Mohamed Boucadair's Yes on draft-ietf-dhc-rfc8415bis -10: (with COMMENT)

Mohamed Boucadair has entered the following ballot position for
draft-ietf-dhc-rfc8415bis-10: Yes

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-rfc8415bis/



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

Hi Tomek, Bernie, Michael, Sheng, and Tim,

Thank you for taking care of the DISCUSS and COMMENTs points in [1]. I also
appreciate the detailed reply to Tim’s comprehensive review [2]. I was waiting
for a follow-up from Tim before updating by ballot. I will leave it to Éric if
he can hold publication for some few days. Thanks.

I checked diff 09/10. I really like the changes. FWIW, some minor “things” I
sport when reviewing the changes:

# Section 1.3: More accurate scope of 9243

OLD: One possible way to manage a DHCPv6 server is proposed in [RFC9243]

NEW: An approach to manage DHCPv6 relays and servers is specified  in [RFC9243]

# Section 5

## ALL_DHCP_Relay_Agents_and_Servers

Consider changing it to All_DHCP_Relay_Agents_and_Servers :-)

## Naturally inherit whatever updates will be made to RFC8085

OLD: and BCP 145 [RFC8085]

NEW: and [BCP145]

## Help readers find where DHCP multicast addresses are defined

For example, consider the following change:

OLD: All_DHCP_Relay_Agents_and_Servers multicast address

NEW: All_DHCP_Relay_Agents_and_Servers multicast address (Section 7.1)

# Section 6.5: nit

OLD: To meet the recommendations of [RFC7934], A client

NEW: To meet the recommendations of [RFC7934], a client

# Section 6.6

## nit

OLD: [RFC9686] introduced a method

NEW: [RFC9686] introduces a method

## minor edit

OLD: The major difference between other use cases and this is

NEW: The major specificity of this mechanism is

# Section 18.2.6: Use the correct option name

OLD: The relay SHOULD insert a Client Link-Layer option

NEW: The relay SHOULD insert a Client Link-Layer Address option

Thank you again for your effort on the maintenance of this important piece.

Cheers,
Med

[1] https://mailarchive.ietf.org/arch/msg/dhcwg/j7I13uN9pjlSnCoT3Q3_htz7YCo/

[2] https://mailarchive.ietf.org/arch/msg/dhcwg/mcUhzp1lh_icTH6fW4F9yqeuGWA/



_______________________________________________
dhcwg mailing list -- [email protected]
To unsubscribe send an email to [email protected]