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
