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 <[email protected]> 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 > > [email protected] > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
