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 . 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 :-).