Dear David, Thank you for your answer.
I read the new version and the answers below: * I still vote for clear language without taking care of the current implementations: since the aim is to convey one single option enclosing only one name; then the client and the sever behaviours should be provided accordingly (i.e., use of "must" instead of the "should"). * I see your point about the multi-interface text. This is fair. I would just add a sentence like: "Means to bind a FQDN_NAME configuration to a given interface in a MIFed device are out of scope of this document." Anyway, please do whatever you think it is appropriate to make this document progress. Cheers, Med ________________________________ De : David Hankins [mailto:dhank...@google.com] Envoyé : vendredi 21 janvier 2011 22:27 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Alain Durand; softwires@ietf.org list; Softwire Chairs Objet : Re: [Softwires] WG last call on draft-ietf-softwire-ds-lite-tunnel-option-07 On Sun, Dec 12, 2010 at 11:42 PM, <mohamed.boucad...@orange-ftgroup.com<mailto: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. ********************************* This message and any attachments (the "message") are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. France Telecom Group shall not be liable for the message if altered, changed or falsified. If you are not the intended addressee of this message, please cancel it immediately and inform the sender. ********************************
_______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
