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

["Edmon Chung" <edmon@xxxxxxxxxxxxx>]

Do you have any suggestion what we should say?
Edmon



> -----Original Message-----
> From: owner-jig@xxxxxxxxx [mailto:owner-jig@xxxxxxxxx] On Behalf Of Avri
Doria
> Sent: Wednesday, August 11, 2010 11:51 AM
> To: jig
> Subject: [jig] Fwd: [] DNSEXT charter and treating DNS names as "the same"
> 
> 
> 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.
> >
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 9.0.851 / Virus Database: 271.1.1/3055 - Release Date: 08/11/10
02:34:00