On Oct 18, 2010, at 8:06 AM, <[email protected]> <[email protected]> wrote: > In addition to the technical reasons mentioned in previous e-mails, I
I'm sorry, I must have missed that email. I saw a lot of talk about how the WG consensus was for the FQDN option, and the IESG ought to respect that, and the DHCwg ought not to have a say in it. I saw some accusations about abuse of power (for the record, I have none, other than my ability to try to get the process to be followed, which it was not for this draft). But I didn't see a *single* technical reason given for your position. Unless "DHCP won't work for us" is a technical reason. > Distinct operational teams are responsible for each of the above > mentioned levels. A clear separation between the functional > perimeter of each team is a sensitive task for the maintenance of the > services we are running. In particular, regional teams will require > to introduce new resources (e.g., new CGN devices) to meet an > increase of customer base. The introduction of these new devices > (addressing, redirection, etc.) is implemented locally. Having this > regional separation provides flexibility to manage portions of > network operated by dedicated teams. Okay, I can dig that. > In order to be able to meet this operational constraint, the AFTR > option name is part of our requirements. See, this is the disconnect. Are you trying to suggest that this statement logically follows the previous paragraph's description of your circumstances? Or was that just a non-sequitur? Because I don't see any logical connection between these two statements. It seems to me that you are saying that the DNS will be under the control of this regional team, and the DHCP server is not. So the regional team is the only team that can make changes to the DNS. But since the DHCP server will be looking the name up in the DNS, this is a non-problem. Whether the DHCP server provides an FQDN or an IP address, the source for the IP address the client eventually uses will _always_ be the DNS. So the regional team will not have a problem updating that information. Furthermore, even if it were the case that the regional team couldn't do what you want, is that any justification for the position you've taken? I don't think it is, because it's an operational issue specific to your organization. We can't design protocols to suit your organization. Obviously we'd like to have the flexibility to address your needs, but as far as I can tell, we *have* that flexibility. And you haven't given any technical explanation for why we don't. _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
