Competition ? Re: [governance] is icann ...

[Carlos A. Afonso]

This is a fascinating discussion, and of course, even for the initiated
(perhaps with the exception of the very few who are capable to keep in
clear memory a big list of interrelated RFCs), difficult to follow in
all its implications.

For me, as Thomas Kuhn has taught us, this is the sorely needed process
which leads to the breaking of existing paradigms (the horror of
established scientific tribes) and the creation of new ones. Karl's msg
below is a good summary of this, and I welcome very much Francis's
initiative to create this debate track not only in our list but in
broader consitutencies as well.

I count on our colleagues who do dominate the intricate relationships in
the ocean of RFCs to participate very constructively in this debate.

frt rgds

--c.a.

Karl Auerbach wrote:
> On 09/21/2009 10:14 AM, Dr. Francis MUGUET wrote:
> 
>> except for some fields like the CNAME ...
> 
> I invite you to dig into the following domain name, which has a single
> CNAME resource record... maps-to-nonascii.rfc-test.net
> 
> As the name suggests, it uses a CNAME RR to load an indirect name that
> contains unusual, but 100% Internet-Standard legitimate characters, such
> as carriage-return, linefeed, and null.  That indirect name causes
> things like gethostbyname() on *nix systems to fail.
> 
> There are uncharted traps in the DNS world that will be exposed as we
> start to stretch DNS into parts that are legal but have not been
> exercised, parts such as using DNS classes other than IN.
> 
> I am in the business of testing internet code.  We test not so much for
> conformance but for robustness.  And we, unfortunately, have learned
> that much internet code is nowhere close to being worthy of being
> labeled as "robust" but is instead implemented according to a design
> practice that says "it worked once on our unstressed lab network, so
> let's ship it as a finished product".  That kind of code is often very
> brittle; it often breaks when subjected to uses beyond what the norm of
> today.  (And besides inducing failure, user confusion, and ISP support
> headaches, it opens doors for security penetrations.)
> 
> It is becoming increasingly clear that DNS is simply not adequate for
> the name mapping needs for the future.  We need name mapping systems
> that are more agile and have greater temporal stability than DNS, and
> they need to avoid the trademark entanglements that have strangled
> rational DNS policies.
> 
> What I am suggesting is that rather than trying to patch DNS and dealing
> with the mass of the installed base we should concentrate on better
> technolgies that perhaps map to an underlying DNS base, perhaps not, but
> that are themselves more attuned to the developing needs of the net.
> 
> Of course, these new technologies might need new bodies of governance.
> They would likely be new bodies, not ICANN, thus giving us a chance to
> do governance things well from the outset rather than do a retrofit.
> 
>         --karl--
> ____________________________________________________________
> You received this message as a subscriber on the list:
>     governance at lists.cpsr.org
> To be removed from the list, send any message to:
>     governance-unsubscribe at lists.cpsr.org
> 
> For all list information and functions, see:
>     http://lists.cpsr.org/lists/info/governance
> 
____________________________________________________________
You received this message as a subscriber on the list:
     governance at lists.cpsr.org
To be removed from the list, send any message to:
     governance-unsubscribe at lists.cpsr.org

For all list information and functions, see:
     http://lists.cpsr.org/lists/info/governance