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.dup...@fdupont.fr _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
