Re: [Gen-art] review of draft-ietf-dhc-dhcpv6-active-leasequery-03.txt

[Jari Arkko <[e-mail]>]

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 <[e-mail]> 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:
>  [phone] -> [phone]
> 
> Regards
> 
> [e-mail]
> 
> _______________________________________________
> Gen-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art