Last Call Review of draft-ietf-dhc-dhcpv4-over-dhcpv6-07
review-ietf-dhc-dhcpv4-over-dhcpv6-07-genart-lc-romascanu-2014-04-28-00

Request Review of draft-ietf-dhc-dhcpv4-over-dhcpv6
Requested revision No specific revision (document currently at 09)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2014-04-29
Requested 2014-04-16
Authors Qi Sun , Yong Cui , Marcin Siodelski , Suresh Krishnan , Ian Farrer
I-D last updated 2014-04-28
Completed reviews Genart Last Call review of -07 by Dan Romascanu (diff)
Opsdir Last Call review of -07 by Fred Baker (diff)
Assignment Reviewer Dan Romascanu
State Completed
Request Last Call review on draft-ietf-dhc-dhcpv4-over-dhcpv6 by General Area Review Team (Gen-ART) Assigned
Reviewed revision 07 (document currently at 09)
Result Ready w/issues
Completed 2014-04-28
review-ietf-dhc-dhcpv4-over-dhcpv6-07-genart-lc-romascanu-2014-04-28-00

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART,
please see the FAQ at



<

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.



Please resolve these comments along with any other Last Call comments you may
receive.



Document: http://www.ietf.org/id/draft-ietf-dhc-dhcpv4-over-dhcpv6-07.txt

Reviewer: Dan Romascanu

Review Date: 4/28/14

IETF LC End Date: 4/29/14

IESG Telechat date:



Summary: Ready, with a few small issues



Major issues: None



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?



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.





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.