[dhcwg] Re: Reminder: WGLC for draft-ietf-dhc-dhcpv4-over- dhcpv6-ra, respond by April 14, 2025

  Nits, and nothing more.



Abstract:

...
This document specifies a RFC7341-based approach that allows DHCP 4o6 to be deployed as a Relay Agent (4o6RA) that implements the 4o6 DHCP encapsulation and decapsulation in contexts where it is not possible at the client.
..

  Bare "it" can be ambiguous.  Perhaps:

  ... where the client supports DHCPv4, but not DHPv6.

Section 3:

...
All prerequisites and configuration that apply to the DHCP client in Section 5 of [RFC7341] shall be applied to 4o6RA instead.
...

  "instead" seems an odd choice.  "Instead of" ... what?  Perhaps:

  As the 4o6RA is acting as a DHCP 4o6 client, all prerequisites and configuration that apply to the DHCP client in Section 5 of [RFC7341] shall be applied to the 4o6RA.


Section 3:

...
When DHCPV4-RESPONSE Message is received by the 4o6 Relay Agent, it looks for the DHCPv4 Message option within this message. If this option is not found, the DHCPv4-response message MUST be discarded. If the DHCPv4 Message option is present, the 4o6RA MUST extract the DHCPv4 message and forward the encapsulated DHCPv4-response to the requesting DHCPv4 client.
...

  Q: should the 4o6RA validate that the DHCPv4 message is well-formed?


Section 3:

...
Layer 2 Relay Agents receiving DHCPV4-QUERY or DHCPV4-RESPONSE messages are expected to handle them as specified in Section 6 of [RFC6221].
..

 "are expected" seems more philosophical than normative to me.  Perhaps "MUST handle them..."


Section 3.2:

...
In order to preserve the topology information, it is recommended that the implementation of 4o6RA
..

  Perhaps normative it is RECOMMENDED


Section 4:

...
As clients are not aware of the presence of 4o6RA, the network deployment needs to ensure that all DHCPv4 broadcast and unicast messages from clients are steered to a 4o6RA. This can, e.g., be
...

  The "e.g." doesn't seem necessary and can be omitted.

Section 4:

...
achieved by placing the 4o6RA in a central position that can observe all traffic from the clients or use of address translation
...

  "or use of" --> "or use"

Section 5:

...
This mechanism differs from [RFC7341] as the DHCP client sends and receives DHCPv4 messages, whereas in [RFC7341] it only sends DHCPv6 messages.
...

  This seems ambiguous until read a few times.  Perhaps;

The mechanism defined here differs from [RFC7341] as we allow the DHCP client to send and receive DHCPv4 messages, whereas in [RFC7341] the client only sends DHCPv6 messages.

  And continuing:

...
This makes it possible that DHCPv4 messages could reach a DHCPv4 server without using the 4o6RA
..

  This... what?  Perhaps:

Without 4o6RA, a DHCP client could send DHCPv4 messages that could reach a DHCPv4 server, ???

  Resulting in different views of the network?  What practical problems are there if a DHCP client does DHCPv4 to one server, and DHCPv6 to a different server?

...
While this can cause erroneous state in both clients and servers 
...

  Such as?

> On Apr 11, 2025, at 6:00 AM, Bernie Volz <[email protected]> wrote:
> 
> Just a reminder regarding this WGLC. We haven’t received any comments either for or against this work.
> 
> - Bernie Volz
> 
>> On Mar 30, 2025, at 11:54 AM, Bernie Volz <[email protected]> wrote:
>> 
>> Hi:
>> 
>> The DHC WG is starting a WGLC on the draft-ietf-dhc-dhcpv4-over-dhcpv6-ra document (see https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv4-over-dhcpv6-ra/).
>> 
>> Please review the document and send comments by April 14, 2025.
>> 
>> Thanks,
>> 
>> - Bernie for DHC WG
> 
> _______________________________________________
> dhcwg mailing list -- [email protected]
> To unsubscribe send an email to [email protected]

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