Subject: [Softwires] WG last call on draft-ietf-softwire-ds-lite-tunnel-option-07

From: Alain Durand <[email-masked]>
Date: Fri, 10 Dec 2010 12:15:03 -0800

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.

---

From: Jari Arkko <[email-masked]>
Date: Sat, 11 Dec 2010 20:47:55 +0200

The new draft looks good to me.

Jari

---

From: Ted Lemon <[email-masked]>
Date: Sat, 11 Dec 2010 13:04:04 -0600

I'm mostly okay with the draft, but there are two statements that need to be deleted:

In section 4:

   A DHCPv6 server MUST NOT send more than one AFTR-Name option.  It
   SHOULD NOT permit the configuration of multiple names within one
   AFTR-Name option.

This requires special handling for this option in DHCP servers.   What you should say is this:

   DHCPv6 server administrators should not configure DHCP servers to return more
   than one AFTR-Name option in any given context.   If more than one AFTR-Name
   option is sent, it will be treated as an error by the client.

And in section 5:

   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.

Instead say:

   It is an error for the DHCP server to return more than one AFTR-Name option.
   If a DHCP client receives more than one AFTR-Name option, it SHOULD ignore all
   AFTR-name options.

I'm not adamant about the second change, but I think it's the right thing to do.   Generally speaking, it's not the DHCP client itself that's going to implement this restriction--it's the thing that's building the tunnel.   So to implement the requirement stated in the draft, the DHCP client has to communicate a lot of information to the tunnel builder that clients ought not to have to communicate.   Since it's a misconfiguration for the DHCP server to present more than one option, it seems to me that the best thing to do when more than one option appears is to simply not set up a tunnel--wait for the administrator to correct the problem, and maybe pop up a dialog box indicating what went wrong.

---

From: <[email-masked]>
Date: Mon, 13 Dec 2010 08:42:50 +0100

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   

"

"

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 : [email-masked] [mailto:[email-masked]] De la part de Alain Durand
Envoyé : vendredi 10 décembre 2010 21:15
À : [email-masked] list
Cc : Softwire Chairs
Objet : [Softwires] WG last call on draft-ietf-softwire-ds-lite-tunnel-option-07

_______________________________________________
Softwires mailing list
[email-masked]
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.
********************************