On Sun, Dec 12, 2010 at 11:42 PM, <mohamed.boucad...@orange-ftgroup.com>wrote:
> This version is almost Ok. I still have two comments: > Thank you for your constancy in review and participation. I suggest to change > "It SHOULD NOT permit the configuration of multiple names within one > AFTR-Name option." > > To > > "It MUST NOT permit the configuration of multiple names within one > AFTR-Name option." > So far as I'm aware, DHCPv6 servers today do not implement any restriction on how many names can be configured if the server is informed that the format of the new option is the RFC 3315 format domain name (in fact, in ISC DHCP's v6 implementation, I called the atom to do RFC 3315 domain names a "domain list" atom). >From my point of view it can be validated that only one option can be configured, but Ted has reminded me that this is not the case in all currently conforming DHCPv6 server implementations. So this would mean that current DHCPv6 implementations could not conform to specification without software changes, something I was trying to avoid (incompletely) with the "MUST / SHOULD" language this version of the draft had. " > If the client receives more than one AFTR-Name option, it MUST use > only the first instance of that option. > > If the AFTR-Name option contains more than one FQDN, as distinguished > by the presence of multiple root labels, the client MUST use only the > first FQDN listed in configuration. > " > > To "If the DHCP Client receives more than one AFTR-Name option or if the > AFTR-Name option contains more than one FQDN, the DHCP Client MUST ignore > the received AFTR-Name option(s))". > I think this would require a software change in current DHCPv6 client implementations. I can't speak for B4 implementations, but if I were a B4 implementor, I would also be concerned that if I conformed to this direction and some other (it only takes one) B4 implementation didn't, then my software would not work where other software does, and this reasoning would not be very obvious to customers. If we're shaping conformance language away from concrete validation and towards current implementation practice, then I think we should do it both on the server and client side. (2) Multi-interface use case: this text has been introduced in 07: > > " Note that a client may have multiple network interfaces, and these > interfaces may be configured differently; some may be connected to > networks that call for DS-Lite, and some may be connected to networks > that are using normal dual stack or other means. The client should > consider the above on an interface-by-interface basis. For example, > if the client is attached to multiple networks that provide the AFTR > Name option, then the client MUST configure a tunnel for each > interface separately as each DS-Lite tunnel provides IPv4 > connectivity for each distinct interface." > > > The text does not elaborate on how an interface is identified and how the > server/client will proceed to enforce the received configuration for the > appropriate interface. BTW, this issue is not specific to DS-Lite and it is > generic to any MIFed device. > For this reason, I didn't want to elaborate. The goal is to include text that reminds the implementor that perhaps they should not follow a mindset that they will have only one B4 element on their system, in the case where they plan to have multiple external network interfaces, since we just finished explaining carefully that there should be only one domain name sent to configuration. The danger is that they may configure only one tunnel endpoint, either having only one B4 element running, or multiple endpoints for each interface all using some single endpoint. These would all be bad decisions, which may seem reinforced by the specification's demand for a single name. Can you suggest simpler language? -- David W. Hankins SRE Google, Inc.
_______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
