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

Thanks Alan … you don’t indicate if you support the document moving forward - but I’ll assume you do.

- Bernie (from iPad)

> On Apr 11, 2025, at 6:41 AM, Alan DeKok <[email protected]> wrote:
> 
>   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]