Last Call Review of draft-ietf-dhc-dhcpv6-active-leasequery-03
review-ietf-dhc-dhcpv6-active-leasequery-03-genart-lc-dupont-2015-07-06-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: draft-ietf-dhc-dhcpv6-active-leasequery-03.txt
Reviewer: Francis Dupont
Review Date: 20150701
IETF LC End Date: 20150629
IESG Telechat date: 20150709

Summary: Almost Ready

Major issues: None

Minor issues: the TLS part is a bit underspecified (nothing critical
 as the missing text should get a quick and easy consensus)

Nits/editorial comments:
 - ToC page 2 and 12 page 27: Acknowledgements -> Acknowledgments
  (you chose US spelling by using behavior :-)

 - 6.1 page 8: you assume TLS offers the same transport facility than TCP.
  In fact it is not true: TCP is a pure octet stream when TLS is a
  sequenced packet. This has an impact in the framing: you have to say
  something about the message framing for TLS. I strongly suggest to say:
  1- the message framing for TLS uses the same format than for TCP
   (so RFC 5460 5.1).
  2- one DHCP message SHOULD be carried in one TLS record.
   IMHO it is easy, simple and works well with tunneling.

 - 6.2.1 page 8: MUST BE -> MUST be

 - 6.2.2 page 9: it is one of the places you should give more details
  about STARTTLS. I suggest to add the STARTTLS message SHOULD be sent
  without any option, and any valid option in received STARTTLS messages
  should be ignored (I put the word valid to catch the bad server ID
  case which BTW seems to be one of the few possible errors).

 - 6.3.1 page 9, 8.4 page 16, 8.6.1 page 20: i.e. -> i.e.,

 - 8.2 page 13: requestor should proceed -> requestor SHOULD proceed ?

 - 8.2 page 14 (3 times): drop -> close

 - 8.2 page 14: verify -> validate
  (my concern about verify is this term is more about the signature,
   so I recommend to use RFC 5280 term, i.e., validate).

 - 8.2 page 14 and 8.3 page 14: Active Leasequery -> ACTIVELEASEQUERY ?

 - 8.4 page 17: server should close -> server SHOULD close

 - 8.4.1 page 17: may run -> MAY run or can run or...
  (i.e., please avoid lower case keywords)

 - 8.4.1 page 17: can't parse: "If this should occur,"

 - 8.4.1 (very end of) page 18: there may be -> there can be

 - 8.4.1 page 19: This Bulk Leasequery request should include -> SHOULD

 - 8.5 page 20: first sentence, twice: may -> can

 - 10 page 26: there is a new security mechanism proposed for DHCPv6,
  secure DHCPv6. As it is clearly designed for UDP transport I don't
  believe it interferes with the document so IMHO you can safely ignore it.

 - Authors' Addresses page 28: according to ITU TS E.123 international
  phone numbers have no optional prefixes so there should be nothing
  included in (), for instance:
  +91 (080) 4365-7476 -> +91 080 4365-7476

Regards

Francis.Dupont at fdupont.fr