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

Hi Eric,
We have a couple of questions related to your comments:

  1.  (point 1) Do we consider this document updating RFC7341? We are actually not extending the protocol.
  2.  (point 15) When clarifying that address translation is actually NAT, do we also need to add a reference to RFC2663?
Thanks and best regards,
Claudio Porfiri

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]