[dhcwg] Re: Reminder: WGLC for draft-ietf-dhc-dhcpv4-over- dhcpv6-ra, respond by April 14, 2025
Alan DeKok <[email protected]> Fri, 11 Apr 2025 11:26:43 -0400
| Newsgroups | gmane.ietf.dhc |
|---|---|
| Message-ID | <[email protected]> |
Yes, I support the document. > On Apr 11, 2025, at 11:05 AM, Bernie Volz <[email protected]> wrote: > > 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]