Last Call Review of draft-ietf-dhc-relay-port-06
review-ietf-dhc-relay-port-06-genart-lc-dupont-2017-10-24-00

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-dhc-relay-port-06.txt
Reviewer: Francis Dupont
Review Date: 20171024
IETF LC End Date: 20171024
IESG Telechat date: unknown

Summary: Ready

Major issues: None

Minor issues: None

Nits/editorial comments: 
 - 1.1 page 3: please upgrade the 2119 section to RFC 8174
  (it is not yet an enforced policy but it is at least strongly
   recommended. BTW if you don't need to update the document for
   another reason you can leave this at RFC Editor's discretion)

 - 4.1 and 4.2 page 5 (5 occurrences): xxx bits value -> xxx bit value

 - 6 page 7: I am afraid the logic behind this option for DHCPv6 (*)
  is not very understable before this example. Unfortunately I both
  know well this document and DHCP protocols so I can't say if I am
  right and/or if it is a real problem (i.e. for the second if it can
  be a problem for intended readers)... Perhaps not DHCP specialists
  reading the document will help?

Thanks

Francis.Dupont@fdupont.fr

PS (*): DHCPv4 and DHCPv6 use relays for very different purposes: DHCPv4
  relays are only for allowing out of local link servers, DHCPv6 relays
  have other uses (this is why DHCPv6 relays can be cascaded) in particular
  for prefix delegation (which is specific to DHCPv6) as embedded relay
  in clients or spoofing relays (I actively pushed these two ideas :-).