Last Call Review of draft-ietf-dhc-dhcp4o6-saddr-opt-04
review-ietf-dhc-dhcp4o6-saddr-opt-04-genart-lc-davies-2018-09-06-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-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