Control RE: net.stewards [Re: BitTorrent (Was: Re: [Isms] ISMS charter broken- onus should be on WG to fix it)]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> 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


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]