John C Klensin wrote: > (ii) ISPs impose restrictions on their customers all the time > and often even enforce them. Many of us consider some of these > to be desirable (e.g., terms and conditions prohibiting > spamming) and others less so (e.g., prohibitions against running > server or peer-peer protocols over a cable network or address > restrictions that force reasonably-architected LANs into NAT > arrangements) but the conditions clearly exist. > Note I said: >>It is absolutely unreasonable for an ISP to tell their customer >>anything about running their network that is not directely >>related to the customer/provider interface. As long as the >>enterprise traffic over that interface is related to the >>capabilities they are paying for, it is none of the ISPs >>(or IETFs) business what they are doing elsewhere. The ISPs do set terms for the customer/provider interface all the time, and rightly so. They can not restrict me from setting up an 802.11 link to my neighbor, only that my neighbor is not allowed to use that for access to the provider's network. In a similar vein, the provider is not in a position to tell customers what address space they can use for purposes that do not interact with the provider interface. They can try, and in a monopoly environment will probably succeed. That does not mean we can tell ISPs to require that people not use any given address space just because the provider is supplying another one. > I also note that site local addresses open up a whole series of > questions about "locality" and scope-range. Perhaps we also > need "ISP-local" addresses (routing into one ISP's space, or > part of it, but not to that ISP's peers or transit customers) > and so on. The one thing that can be guaranteed about that sort > of arrangement is an extension of the "pay enough and someone > will route it" model will apply: If some ISP sees a potential > competitive advantage in offering such a product (and > addresses), the product will follow soon thereafter. And, > again, I think that this suggests that we had better figures out > how to deal with these things on a policy basis, not a > protocol-imbedded special address scope one. We are almost > certain to have the policy problem anyway and it is not clear > that special cases for peculiar address scopes will buy us that > much in addition. Address filtering exists in the network today, and will continue. Since that is done as an expression of local policies, you are correct the whole discussion is really about policy. It is not clear to me what the IETF is in a position to do, other than define the operation of a multifacited DNS. ;) Tony