Subject: Re: [Gen-art] GenART review of draft-ietf-dhc-dhcpv4-over-dhcpv6

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 12 May 2014 11:07:45 +0000

Hi Qi,

Thanks for the answer and for addressing my comments. The proposed edits look fine.

Regards,

Dan

From: Qi Sun [mailto:[email-masked]]
Sent: Monday, May 12, 2014 7:37 AM
To: Romascanu, Dan (Dan)
Cc: [email-masked]; [email-masked]
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-masked]<mailto:[email-masked]>> 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.

---

From: Qi Sun <[email-masked]>
Date: Mon, 12 May 2014 12:37:04 +0800

Dear Dan,

Best Regards,
Qi

NEW:

>  
> 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:

>  
> 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.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 28 May 2014 21:51:21 +0300

Dan: many thanks for your review. Qi: thanks for the updates.

Jari