Hi Francis, Thanks for your comments. I shall fix all below issues in next version of the draft. Although I have comments for couple of issues below. Please check inline.
Thanks, Dushyant. On 06/07/15 19:16, "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). [Dushyant]: I understand that currently we don’t have any option to be sent in STARTTLS message. But it could be a case that we reuse this message for some other feature (in future) and there we may send some option in the same. So should we ignore that possibility and say that "STARTTLS message SHOULD be sent without any option”? > > - 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. [Dushyant]: Secure DHCPv6 isn’t a standard yet. Can we use that as reference? > > - 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
