Hi Ted,
I am not one of the authors of this draft, thus my final goal is not to
publish an RFC with my name. As Service Provider I come to IETF to find
standard and interoperable solutions that would fit my deployment scenarios.
I fully respect technical advices provided by technical people like you, my
point is that IETF community should work with Service Providers to find
solutions that both fulfill our requirements and they don't break existing
stuff. In the specific case being able to provide load-balancing and redundancy
in DS-Lite scenario is a requirement for us, thus I would like to see a
solution for this coming from IETF.
Best regards,
Roberta
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Ted Lemon
Sent: mercoledì 13 ottobre 2010 17.33
To: [email protected]
Cc: Softwires WG; Softwire Chairs;
[email protected]
Subject: Re: [Softwires] DHCPv6 AFTR name option is needed
On Oct 12, 2010, at 11:49 PM, <[email protected]>
<[email protected]> wrote:
> If we adopt the sub-option scheme with the following values:
> 1 AFTR IP Addres
> 2 AFTR Name
Mohamed, Roberta, you seem to have a very strong opinion that is based on the
principle "someone insists that we have this." I have to ask: what is your
goal here? Is your goal to publish an RFC with your name on it that does what
you want, even though probably no-one will implement it because it requires
code changes to both the server and client? Or is it to get something that
works, and can be used?
If it's the former, then by all means, ignore our advice. If it's the latter,
you might want to consider listening to the advice you're getting. The point
of the advice is not to be authoritarian or arbitrary. It's to encourage you
to write a spec that will be implemented and widely deployed, because it will
require no code changes on DHCP servers or clients.
David's suggestion to use suboptions wasn't necessary. You can use both FQDN
and IP address, and just require that the client request both. The problem
with this is that you gain nothing over just doing FQDN in this case, since the
client must implement a resolver in case the server doesn't send the IP address
option.
I think you are driving very hard for a Pyrrhic victory.
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone
indicate. La diffusione, copia o qualsiasi altra azione derivante dalla
conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate
ricevuto questo documento per errore siete cortesemente pregati di darne
immediata comunicazione al mittente e di provvedere alla sua distruzione,
Grazie.
This e-mail and any attachments is confidential and may contain privileged
information intended for the addressee(s) only. Dissemination, copying,
printing or use by anybody else is unauthorised. If you are not the intended
recipient, please delete this message and any attachments and advise the sender
by return e-mail, Thanks.
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
