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@xxxxxxxx] On Behalf Of Ted Lemon >Sent: Saturday, September 27, 2014 3:35 AM >To: ietf@xxxxxxxx >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.