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-dhcp4o6-saddr-opt-04
Reviewer: Elwyn Davies
Review Date: 2018-09-06
IETF LC End Date: 2018-09-07
IESG Telechat date: Not scheduled for a telechat

Summary: Ready with nits. Thanks - well written and almost all quite clear.

Major issues:
None

Minor issues:
s7.4:
>    o  The received bindprefix6-len value is not larger than the number
>       of bytes, divided by 8, received in the bind-ipv6-prefix field.
>       (e.g. the bindprefix6-len is 128 but the bind-ipv6-prefix field is
>       only 8 bytes long).
Given that s6.1 gives a deterministic algorithm for calculating the length of the bind-ipv6-prefix field, I don't understand why the validation does not check that the length of the field is exactly as specified by this algorithm rather than using it as a lower limit.

s7.5 and s8 (last para): Given that the time constraints and number of retries will interact and are implemented in different devices, I think these two values need some sensible defaults defined so that devices from different sources should interoperate successfully out of the box.

Nits/editorial comments:
General: s/e.g./e.g.,/g

Abstract, sentence 2: Introduce DHCP 4o6 abbreviation: s/For DHCPv4 over DHCPv6/For DHCPv4 over DHCPv6 (DHCP 4o6)/.

Abstract: Add mention of RFC 6346 and RFC 7598 for explanation of softwire scheme.

Abstract, para 2: Expand ORO (Option Request Option) and give ref to rfc3315bis.

s1, para 3:  s/attached to any routable IPv6 prefix/attached to a network segment using any routable IPv6 prefix/

s4, para 1: It would be useful to remind readers of the expansion of BR in OPTION_S46_BR:  Maybe s/the remote IPv6 address for the softwire/the remote IPv6 address used for the softwire border router/

s4, para 1: Expand ULA (not a well-known abbreviation).

s7.2.1, para 1: 'flash' is colloquial and may not be generally understood.  I think it can safely be removed.

s7.4, para after bullets: s/For either of these cases,/If either check fails,/

s10: To be absolutely clear, there are two instances where the following change ought to be made:
OLD:
in the table at https://www.iana.org/assignments/dhcpv6-parameters:
NEW:
in the Option Codes table at https://www.iana.org/assignments/dhcpv6-parameters:
ENDS