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

[Avri Doria <avri@xxxxxxx>]

Hi,

I don't really have a suggestion, but ...

One of the problems the IETF DNS EXT working group is having is that they are 
working with the most generalized case - that is the IETF way.  And for that 
case there is no solution on the table.

However, if there is a need for a technical solution for variants that want to 
be treated as it they were the same can :

a. be shown to be a real need
b. be shown to be really important
c. be shown to be a subset of the general case

Then it may be possible to contribute a reason to suggest what they call 
solution 2 for those special cases.

On the other hand since if  some in this group have of the experience of those 
who are doing it through the use of maintenance methods, then we may be able 
contribute:

a. a statement that it is sufficient
b. or a statement that it is not.

I consider myself as having a fairly decent understanding of the problem and 
the tech options on the table, but my knowledge is rather academic so I don't 
really have a opinion on what we should do.

What I want to avoid, if possible, is that this moment pass by and the DNS Ext 
group makes a decision that may not be optimal for those doing variants without 
us having even conveyed the problem, as this group or its members see it.

a.



On 11 Aug 2010, at 05:48, Edmon Chung wrote:

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