ICANN ICANN Email List Archives

[jig]


<<< Chronological Index >>>    <<< Thread Index >>>

[jig] Fwd: [] DNSEXT charter and treating DNS names as "the same"

  • To: jig <jig@xxxxxxxxx>
  • Subject: [jig] Fwd: [] DNSEXT charter and treating DNS names as "the same"
  • From: Avri Doria <avri@xxxxxxx>
  • Date: Tue, 10 Aug 2010 23:50:37 -0400

Hi,

This might be a point for us to say anything if we have anything to say.

a.


Begin forwarded message:

> From: Andrew Sullivan <ajs@xxxxxxxxxxxx>
> Date: 10 August 2010 09:36:49 EDT
> To: namedroppers@xxxxxxxxxxxx
> Subject: [dnsext] DNSEXT charter and treating DNS names as "the same"
> 
> Dear colleagues,
> 
> One of our primary goals for DNSEXT at IETF 78 was to get feedback
> from the user community (in particular, we aimed at application
> developers) who have the "aliasing" and "sameness" problem(s) with the
> DNS.  Unfortunately, we were unable to attract many such participants.
> 
> It is clear to us that none of the proposals now before DNSEXT
> addresses all the problems that people have.  As far as we are able to
> tell, there are needs with respect to domain names, with respect to
> whole trees in the DNS, and perhaps with respect to individual labels
> no matter where they might appear in a domain name.  None of the
> proposals handles all of these, and some of these needs are not
> addressed at all.
> 
> We appear to be faced with a choice among three basic strategies:
> 
>   1.  Experiment: Since we don't know what the problems are, but we
>   have people proposing solutions, we could adopt the proposed
>   solutions experimentally, and evaluate in (say) five years whether
>   the proposals solved the problems people have.
> 
>   2.  Limp along: We could accept that no proposal will solve
>   everything, and "limp along" by standardizing properly the
>   proposals we have: work towards clarity and precision in the
>   problem statement and then proceed to work on the proposals
>   themselves.
> 
>   3.  Kick it upstairs: A basic problem in all of this is that the
>   DNS does not have a presentation layer.  Domain names end up being
>   used in presentation contexts, and that's what's broken.  So, we
>   could say that there is no problem here for the DNS, but that we
>   are ready and willing to support building a presentation layer
>   atop the DNS.  Such a specification needs to come from elsewhere.
> 
> The problem with (1) is that some of the proposals are simply
> impossible to do as experiments (if we change the rules for CNAME,
> they're effectively changed forever whether we like it or not).  In
> addition, we think it would be a very bad idea to perform such an
> experiment in the root, but we expect that there would be operational
> pressures to do so.
> 
> The problem with (2) is that we make the DNS more complicated without
> solving all or perhaps even most of the problems people really have.
> The complication will be greater than many people seem to think: for
> instance, the BNAME proposal as it is currently written is, as far as
> we can tell, simply incompatible with all the deployed validators in
> the world.  That seems like a problem that needs addressing, and we
> can't see how to do so easily.
> 
> The problem with (3) is that it was suggested before, and got no
> traction.  Moreover, it's very complicated, such that the work might
> never complete; and in the meantime, people who have a problem have no
> help.
> 
> We DNSEXT chairs are mostly convinced that there is no current
> proposal that is any simpler than just duplicating zone apex data and
> adding a DNAME to the "alias" zones.  This suggests an option 4:
> 
>   4.  Provisioning only: document how to do what's needed by
>   provisioning, and explain why the WG is not doing anything else.
> 
> Before we propose another charter for the WG, we'd like to hear more
> arguments why any work is needed, and which of the options 1-4 seem
> like the best bet for that work.
> 
> Best regards,
> 
> Andrew and Olafur
> 
> -- 
> Andrew Sullivan
> ajs@xxxxxxxxxxxx
> Shinkuro, Inc.
> 




<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy