[dhcwg] Re: AD review of draft-ietf-dhc-dhcpv4-over-dhcpv6-r a-03

Hi Eric,
Thanks for your work.

We will take care of all the points.

Best regards,
Claudio & the other authors.

From: Eric Vyncke (evyncke) <[email protected]>
Sent: Thursday, June 26, 2025 1:36 PM
To: dhcwg <[email protected]>
Cc: Claudio Porfiri <[email protected]>; Suresh Krishnan (sureshk) <[email protected]>; Jari Arkko <[email protected]>; [email protected]
Subject: AD review of draft-ietf-dhc-dhcpv4-over-dhcpv6-ra-03

Dear authors, shepherd, and DHC WG,

Thanks for your patience and for the simple but useful work done; here is my AD review of draft-ietf-dhc-dhcpv4-over-dhcpv6-ra-03. As usual, I am requesting that all points (except the nits) below are addressed, either by a revised I-D or by an email reply (and of course, happy to be proven wrong). Once, all points below are addressed, I am proceeding with the publication process (i.e., IETF Last Call).

BTW, thanks for using SVG graphics, the document renders much better in HTML !


  1.  Should this document update RFC 7341 ? I think so as it changes somehow the applicability of RFC 7341


  1.  Title: suggest remove the acronym `DHCP 4o6`


  1.  Abstract: also suggest removing all acronyms (the ones between parenthesis).


  1.  Abstract: suggest s/to use services provided by *DHCPv6 using* DHCPv4-over-DHCPv6 (DHCP 4o6) in a Relay Agent/to use services provided by DHCPv4-over-DHCPv6 (DHCP 4o6) in a Relay Agent/


  1.  Rather than referencing RFC8415 (for DHCPv6), let’s use draft-ietf-dhc-rfc8415bis, which is already in the RFC editor queue, so, added delay for publication.


  1.  S 1: please expand LDRA and L3RA (even if LDRA is more defined in S 2)


  1.  S 3: in figure 3 s/L2 Network/IPv6-only L2 Network/ or /IPv6-only link/


  1.  S 3: s/described in [RFC7341<https://www.rfc-editor.org/rfc/rfc7341>]/specified in [RFC7341<https://www.rfc-editor.org/rfc/rfc7341>]/


  1.  S 3:  ` forward the encapsulated DHCPv4-response to the requesting DHCPv4 client` may not always be possible if the DHCP server replies is incorrect. Should there be some text for this corner case ?


  1.  S 3.2: suggest to use a bullet list for the IPv4 and IPv6 use cases after `Topology discovery as described in [RFC7969<https://www.rfc-editor.org/rfc/rfc7969>] differs between IPv4 and IPv6`


  1.  S 3.2: in `all Relay Agents can send link-address` let’s rather use “may” or “must” or “should” ?


  1.  S 3.2: in `topology information for the given IP address can be obtained from the DHCPv6 server and used for configuration or other purposes` is it from or to the DHCPv6 server ? If from, then some context about ‘topology information’ would be welcome


  1.  S 3.2: if the issue is about intermediates L2 switches in the “L2 Network”, then suggest adding a box in this network labelled ‘L2 switch’


  1.  S 4: s/messages from clients are steered/messages from and to clients are steered/ ?


  1.  S 4: to be honest, I do not understand what `address translation` is doing here ? Is it about NAT or something else ? Please be specific.


  1.  Appendix A: suggest adding 3GPPP in the section title and perhaps also in the leading paragraph.


  1.  Appendix A: is figure 5 about IPv4-only ? If so, suggest indicated it.

Some nits as well (can be ignored)


  *   S 1: s/instead this document/instead, this document/


  *   S 2: s/Layer 2 devices/layer-2 devices/ and similar cases elsewhere. In the same vein, be consistent and avoid the simultaneous use of ‘L2 networks’ (except in graphics).


  *   S 3.2: s/Thus in a network/Thus, in a network/


Regards,

-éric

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