Jari, Francis, Thanks for the information regarding the TLS transport. As Dusyhant said, we will incorporate both of your TLS suggestions into the document:
> 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. In addition, we will incorporate your other editorial comments as well, though I've never before been told that I can't use "may" in a draft. The comment about sending STARTTLS without any options: Generally we expect that any options not explicitly documented to have meaning in a message on the receiving end will be ignored when receiving a DHCP message. If we say in this document that you SHOULD send no options in a STARTTLS message, if we reuse that message later (as I expect we will) and that re-use involves options (as it might), then the later draft has to update this document just to re-use the message, even though it doesn't have anything to do with leasequery (but just wants to do a TLS connection to the DHCP server). Which seems a bit confusing for someone who is implementing this draft in the years to come. On the other hand, we have no current plans for options on the STARTTLS message, so we will say that you SHOULD send it with no options and let the future be as it will be. Thanks for your review, Kim On Jul 8, 2015, at 5:59 PM, Jari Arkko <jari.ar...@piuha.net> wrote: > Thanks for the review. Authors, shepherd/AD, do you have any comments on > Francis’ TLS issue below? > > Jari > > On 06 Jul 2015, at 15:46, Francis Dupont <francis.dup...@fdupont.fr> wrote: > >> 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 > _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
