Dear all, This version is almost Ok. I still have two comments:
(1) Malformed DHCP answers sent by the DHCP Server: The I-D restricts the server to convey only on FQDN in the AFTR-Name. Then, it is coherent for the client to not accept an AFTR-Name which conveys several FQDN since this is a malformed message. I understand picking the first FQDN in the list is pragmatic but this is not coherent with the scope of this option: convey one single FQDN in one single option occurrence. 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." And " 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))". (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. Other complications may raise in a multi-interface context. This is what is supposed to be solved by MIF WG. I suggest to remove this text from the I-D or to add a statement that multi-interface considerations are out of scope and are handled in MIF. Cheers, Med -----Message d'origine----- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Alain Durand Envoyé : vendredi 10 décembre 2010 21:15 À : softwires@ietf.org list Cc : Softwire Chairs Objet : [Softwires] WG last call on draft-ietf-softwire-ds-lite-tunnel-option-07 I'd like to start a one week wg last call on draft-ietf-softwire-ds-lite-tunnel-option-07. http://www.ietf.org/internet-drafts/draft-ietf-softwire-ds-lite-tunnel-option-07.txt History and rationale for a 1 week last call: The softwire wg had a regular 2 week wg last call on the -05 version. That version was sent to IESG, An issue was raised during IESG review: do we need to define 2 options for DS-Lite: one FQDN based and one IP based. -05 was defining both. As a response to IESG comments, -06 was published to removed the FQDN option. Further discussion followed, and the Softwire chairs declared a consensus to define only one option, but to choose the FQDN one instead of the IP option. The draft authors have reflected this change in the -07. In order to verify the above consensus, I am starting this one week-long wg last call. I'm also asking Ted Lemon, DHC workign group chair, Cc: here, to start a similar last call in the DHC wg. The Softwire last call will end on 12/17/2010. Alain Durand, Softwire co-chair. _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ********************************* 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
