<<<
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
>>>
|