Ted, all, Please see a few additional comments inline.
[snip] 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? CJ: capitalizing on VoIP SBC operation experience, the de-correlation of DNS and DHCP functions facilitates redirection operations (e.g. towards the CGN that maintains static entries for a given customer), and the opportunity to apply similar operational procedures to NAT capabilities whether they are embedded in a CGN or in a SBC is something that is often valued by service providers, at least from an OPEX standpoint. [snip] 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. CJ: it seems to me that the above comment mostly reflects an implementation/configuration-driven concern. I can understand this position, but I think IETF WGs are chartered to document tools (namely protocols) that are meant to address specific issues and requirements. WGs are not supposed to document how to *implement* (let alone configure) such tools, which is basically the responsibility of service providers and other players. I think the requirement for the FQDN option makes sense (at least in some providers' environments), and this is why the standardization of this option is useful. This does not mean that this option must be used by each and every service provider. As long as this FQDN information can be made available by means of a DHCP option, then it's up to the service providers to deal with corresponding yet required configuration tasks. This is why I don't see any harm in standardizing this option along with the IP address option, and I therefore support the need to re-include this option in the core spec. Cheers, Christian. ********************************* 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 [email protected] https://www.ietf.org/mailman/listinfo/softwires
