> From: Gray, Eric [mailto:Eric.Gray@xxxxxxxxxxx] > Philip, > > Apology in advance if this seems to be removed from > context, but your statement (below) seems to have been made > generally and is > not self consistent. Perhaps you could clarify it somewhat? > > --- [ SNIP ] --- > --> > --> Sure the IETF can pursuade IANA not to register a code > point. But if > --> that happens it only makes things worse. There is nothing > that can > --> be done to prevent unregistered use and no real disadvantage to > --> doing so as as nobody will want to accept an official > registration > --> polluted by prior use. > --> > --- [ SNIP ] --- > > Generally, the existence of an assignment authority does > encourage its (proper) use - mostly for the reason you state > above. Just as > "nobody will want to accept an official registration polluted by > prior use", "nobody" (deliberately in quotes) will want to attempt > to establish an unofficial registration using the approach > you've described. Doing so is - at the very least - going to > adversely affect popularity and is very likely to result in > interference and potentially even litigation. That is only the case up to the point that an attempt is made to use the registry as a means of political control. For example if the US congress was to decide to 'require' ICANN to drop Cuba, North Korea, Palestine etc. out of the DNS master zone file the result would be an immediate end to the authority of ICANN beyond the borders of the US. It would not result in the zones disappearing. Similar issues crop up all the time in radio frequency spectrum allocations. People will not want to use an unofficial registration unless the registration process is unacceptable, either because the process itself is too tedious or there are unacceptable costs such as politically driven side constraints. The DNS extensions draft proposed by some members of the IAB suffers from this falacy. They essentially conclude that the only legitimate way to extend the DNS is by registering a new RR with IANA. The only 'benefit' of this approach is that it gives political control over use of the DNS to the DNSEXT working group. This is not considered a benefit by any of the groups looking to create DNS policy extensions and in each case the group has essentially decided to reuse TXT records, either with or without prefixes. Nobody has the slightest intention of ever using the proposed 'proper' DNS record, as has been demonstrated at some length publishing the same information through different mechanisms leads to inconsistency. But this approach is inisted on because 1) the fear of losing control and 2) in order to force the pace of DNS server upgrades that allow use of new resource records. What has happened here is that the result is very much worse for all parties than could be achieved if the insistence on control was dropped - control that is in any case illusory. Forcing IETF-firendly initiatives such as SPF and DKIM to accept IETF control does nothing to prevent the introduction of 'dangerous' records that might actually cause severe problems. If the insistence on cutting new RRs is dropped it is entirely possible to define a method of applying prefixed records that provides all the wildcard administrative functionality that is possible with a new RR. This means that the protocols can be supported by the existing DNS rather than only 50% of deployments according to empirical measurement. It also means that we can get more protocols that make use of DNS based policy statements which in turn means that the security of the DNS becomes a much more important issue which in turn means that DNSSEC becomes a much more important issue which in turn means that there is a real incentive to deploy the DNS extensions to support deployment of new RRs. If you run the numbers through a spreadsheet simulation you will soon discover that making new protocols *dependent* on an infrastructure deployment is a much less effective deployment strategy than designing the new protocols to be independent of the infrastructure deployment but capable of taking advantage of the infrastructure where it exists. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf