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

[Tina Dam <tina.dam@xxxxxxxxx>]

I think what is a really important contribution from the policy side is to 
clearly explain what the problem is that is being sought by implementing 
variants as TLDs. To set the policy limitations and explain the desired outcome.

Said shortly: explain exactly what do we want to see happen.

I note on this that the ccNSO IDN ccTLD PDP (not sure I got the name right, but 
the long term IDN ccTLD policy) is working on the same subject matter. I do 
think it would be useful if the two groups would be on if not the same then 
similar page on the subject matter.

On a related note, a lot of additional variant related activities are ongoing. 
We are at staff forming an internal variant-coordination team to ensure that 
all staff involved with variants one way or another, are coordinated and know 
what's going on and who to refer to among colleagues.

Tina

> -----Original Message-----
> From: owner-jig@xxxxxxxxx [mailto:owner-jig@xxxxxxxxx] On Behalf Of
> Edmon Chung
> Sent: Wednesday, August 11, 2010 2:48 AM
> To: 'Avri Doria'; 'jig'
> Subject: RE: [jig] Fwd: [] DNSEXT charter and treating DNS names as
> "the same"
> 
> 
> 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