Hi Qi, Thanks for the answer and for addressing my comments. The proposed edits look fine.
Regards, Dan From: Qi Sun [mailto:[email protected]] Sent: Monday, May 12, 2014 7:37 AM To: Romascanu, Dan (Dan) Cc: [email protected]; [email protected] Subject: Re: GenART review of draft-ietf-dhc-dhcpv4-over-dhcpv6 Dear Dan, Thanks for your review and comments. We have some proposed changes to the -07 version. Please see inline. Best Regards, Qi On Apr 28, 2014, at 6:05 PM, Romascanu, Dan (Dan) <[email protected]<mailto:[email protected]>> wrote: Minor issues: 1. In section 10: When the server receives a DHCPv4-query message from a client, it searches for the DHCPv4 Message option. The server discards the packet without this option. The server MAY notify an administrator about the receipt of a malformed packet. The mechanism for this notification is out of scope for this document. It would be good to clarify the behavior of the server beyond possibly notifying an administrator at the receipt of a malformed packet. Is the packet discarded? [Qi] The original text is a little odd. How about the following text: OLD: When the server receives a DHCPv4-query message from a client, it searches for the DHCPv4 Message option. The server discards the packet without this option. The server MAY notify an administrator about the receipt of a malformed packet. The mechanism for this notification is out of scope for this document. NEW: When the server receives a DHCPv4-query message from a client, it searches for the DHCPv4 Message option. The server discards a packet without this option. In addition, the server MAY notify an administrator about the receipt of this malformed packet. The mechanism for this notification is out of scope for this document. 2. I believe that [RFC3527] should rather be a Normative Reference. Even if the use of a Link Selection sub-option is under a 'may' - it cannot be implemented unless RFC3527 is read. [Qi] When we wrote the related text, we didn't try to detail it for actually implement. And during the develop of DHCPv4 over DHCPv6 (and WGLC), the working group hasn't showed intention to do anything about that. So it might be better by taking out some text: OLD: The server may also act as a DHCPv4 relay agent and forward the DHCPv4 packet to a "normal" DHCPv4 server. In this case, the server would need to set the giaddr to one of its own addresses and add Relay Agent Information option (82), including a Link Selection suboption [RFC3527] with the IPv4 subnet to assign a DHCPv4 address from, as mentioned above. There are other complexities with this solution as enough information needs to be retained (or included in a Relay Agent Information option) to be able to return the response back to the client; how this might be done is outside the scope of this document. NEW: Alternatively, the server may act as a DHCPv4 relay agent and forward the DHCPv4 packet to a "normal" DHCPv4 server. The details of of such a solution have not been considered by the working group; describing that solution is out of scope of this document and is left as future work should the need for it arise. Would the new text be OK? Nits/editorial comments: In the introduction there is reference to the 'DHCP leasequery'. Actually in RFC 4388 one can find Leasequery either capitalized (in the title) or ALL-CAPS in the text. [Qi] Thanks. Have updated accordingly.
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
