Hi, Ted,
Thanks for your comments. Your proposed text is reasonable and straightforward.
I have applied into the new version that I am preparing. Sorry for that I did
not response earlier.
Best regards,
Sheng
-----Original Message-----
From: ietf [mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of Ted Lemon
Sent: Saturday, September 27, 2014 3:35 AM
To: ietf(_at_)ietf(_dot_)org
Subject: Re: [Softwires] Last Call: <draft-ietf-softwire-4rd-08.txt> (IPv4
Residual Deployment via IPv6 - a Stateless Solution (4rd)) to Experimental RFC
So this is a little bit embarrassing given that I just did my AD review of this
document, but the way the DHCP options were done violates the
recommendation in the DHCPv6 Option Guidelines document (RFC 7227) in
that it uses suboption codes for the 4RD_MAP_RULE and
4RD_NON_MAP_RULE options, instead of treating OPTION_4RD as an
encapsulating option, and the other two options as encapsulated options (see
section 9 of RFC 7227).
o One DHCPv6 option codes TBD1 for OPTION_4RD of Section 4.9
respectively (to be added to section 24.3 of [RFC3315]. Suboption
values of 4RD_MAP_RULE (0) and 4RD_NON_MAP_RULE (1) should
also be
recorded into the DHCPv6 option code space.
Also, the suboption configuration is expressed as a server requirement, when
it's actually an operational requirement:
OLD:
o 4rd rule suboptions: the 4RD DHCPv6 option SHOULD contain at least
one 4RD_MAP_RULE suboption and maximum one
4RD_NON_MAP_RULE
suboption. the length of suboptions in octets
NEW:
o 4rd rule suboptions: the 4RD DHCPv6 option contains at least
one 4RD_MAP_RULE suboption and maximum one
4RD_NON_MAP_RULE
suboption. Since DHCP servers normally send whatever options
the operator configures, operators should be advised to
configure these options appropriately. DHCP servers MAY
check to see that the configuration follows these rules and
notify the operator in an implementation-dependent manner
if the settings for these options aren't valid.