On Oct 19, 2010, at 4:48 AM, <mohamed.boucad...@orange-ftgroup.com> <mohamed.boucad...@orange-ftgroup.com> wrote: > We believe that AFTR (CGN) capabilities should be distributed as close to > the customers as possible, not only for scalability, flexibility and > performance reasons, but also to improve the overall availability of > the DS-Lite service while dramatically facilitating DS-Lite > management as briefly exposed in one of my previous e-mails.
Okay, so I asked you a specific question about this, and outlined a solution that involves resolving the FQDN in the DHCP server rather than in the client. You haven't said why this won't work for you. Could you speak to that? > This use case could be further elaborated in a specific draft, but > I'm curious to know why the use of the FQDN option mandates yet > another effort, I explained this early, but I'll reiterate. If you have two different ways in DHCP to configure a value in the client, then you create an interoperability problem. The DHCP client requests one or the other option; if it requests the wrong option, the server will not respond, because it wasn't configured with that option. In order to correct this problem, the DHCP server needs to know that the FQDN option is an alias for the IP address option. This requires custom code on the DHCP server, just for your option. Imagine if every single working group that wanted a DHCP option wanted custom code for the option as well. You would have more customization code in the server than protocol code. This is what I am trying to avoid by having this discussion with you. I am not objecting to sending the FQDN, if that is what you really need. But I *am* asking you (that is, the softwires working group) to make a decision: do you want FQDN, or do you want IP address. We had a pretty unequivocal "no" to DNS from David Hankins. We have a pretty unequivocal "yes" to DNS from you. I'm asking you to work that out. > [...details about your protocol...] I just want to briefly explain why I haven't responded to any of your statements about your protocol, and how it works. The reason is because you are using DHCP as an information delivery mechanism. It's not part of your protocol. You (the working group) need to decide what information you need DHCP to deliver to you. Once you've made that decision, the inner workings of your protocol are irrelevant to the DHCP protocol. > And indeed, there used to be a WG consensus on supporting both > options, as you rightfully recalled. The WG consensus was a consensus in the softwires working group, not in the DHC working group. Both working groups need to weigh in on this option, not just softwires. Now that you have feedback from the DHC working group, which you should have got before you sent the draft to the IESG, it would be nice if you could have a discussion in softwires about what the right course of action is, rather than insisting that such a discussion is not necessary because softwires has consensus. > Last but not least, I think the unnecessary aggressively of your > comments jeopardizes the serenity of the discussion (in particular > the tone and contents of your message > http://www.ietf.org/mail-archive/web/softwires/current/msg01703.html > were totally inappropriate, especially because you are a WG chair), > and I would therefore appreciate a greater show of courtesy from your > side. The essential source of suffering in the world is the belief that my serenity depends on the actions of another. If I can free myself from this mistaken belief, serenity is available to me in any circumstance. I am sorry that you do not feel that I have been appropriately courteous. You are not the only person to have said this--I got a private note from someone at ISC who thought my response was a bit over the top as well. I'm sorry it came across this way, and I don't claim that it was appropriately worded. But the essence of my question was this: "do you want this to be easy to implement, or hard to implement." I phrased it the way I did to emphasize my belief that the direction you wanted to go in the discussion was counterproductive. It was not my intention to insult you. Nor was it my intention to be "aggressive," whatever that means in this context. My intention was, and is, to get the issue resolved. It would be highly effective if you were to avoid taking my comments personally, and instead see them in the context of a discussion about what the right technical solution is here. I don't know you personally, don't hold any ill will toward you, and really just want to get to the right outcome here. _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
