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

From: Francis Dupont <[email-masked]>
Date: Mon, 06 Jul 2015 15:46:21 +0200

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-masked]

---

From: Jari Arkko <[email-masked]>
Date: Wed, 8 Jul 2015 23:59:09 +0200

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-masked]> wrote:

> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: "Dushyant Raghuvanshi (draghuva)" <[email-masked]>
Date: Thu, 9 Jul 2015 06:08:37 +0000

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.

>  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”?

>  believe it interferes with the document so IMHO you can safely ignore

[Dushyant]: Secure DHCPv6 isn’t a standard yet. Can we use that as
reference?

---

From: Kim Kinnear <[email-masked]>
Date: Thu, 9 Jul 2015 16:40:28 -0400

Jari, Francis,

Thanks for the information regarding the TLS transport.  As Dusyhant
said, we will incorporate both of your TLS suggestions into the

>  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

---

From: Brian Haberman <[email-masked]>
Date: Fri, 10 Jul 2015 08:19:59 -0400

> [Dushyant]: Secure DHCPv6 isn’t a standard yet. Can we use that as

I don't see a reason to reference the sedhcpv6 draft.

Regards,
Brian