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.

_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

Reply via email to