My original message was not copied to ietf mailing list.
John quoted all of my text so I'm sending this follow-up to ietf as well
as dnsext
mailing lists.
On 02/10/2012 12:38, John C Klensin wrote:
--On Tuesday, October 02, 2012 11:01 -0400 Olafur Gudmundsson
<ogud(_at_)ogud(_dot_)com> wrote:
...
The IESG has received a request from the DNS Extensions WG
(dnsext) to consider the following document: - 'Extension
Mechanisms for DNS (EDNS(0))'
<draft-ietf-dnsext-rfc2671bis-edns0-09.txt> as Internet
Standard
...
John,
<no-hat>
We learned two main things from binary labels:
a) the specification of them caused expensive processing, and
the
utility of binary labels w/o A6 record was none.
Huh? While I certainly agree that the binary label experiment
failed, RFC 2673 didn't seem to me to have anything to do with
A6 records and a quick review just now doesn't convince me
otherwise. As I recall, it came out of the period in which we
were evolving to classless IPv4 addresses (with prefix
lengths/netmasks on arbitrary bit boundaries) and was intended
to permit address delegation entities to easily delegate ranges
of reverse-mapping records to the appropriate address-holding
entities for management. The failure of that idea (for the
reasons you outline) contributed, IMO, to PTR records being much
less useful today than they were pre-CIDR.
Conversely, if a significant reason for getting rid of binary
labels was the link to A6 records, why doesn't the document just
say "these existed solely to support A6 records, A6 records have
been deprecated, therefore these are too". All of us could be
spared the discussion of why they failed relative to deployment
issues, etc. But the question of whether it is appropriate to
get rid of label types would remain.
b) In order to introduce a new label type: All DNS
infrastructure
needs to understand the new label type before it is can be
reliability used. Lots of DNS processing elements barf at
labels that
they do not expect. For example number of firewalls drop
answers
if the name of the first answer record is not compressed (a
protocol violation)
Understood. Of course, some of the same things could be said
about EDNS0 itself.
Based on this experience the DNSEXT felt that the best message
to send
out is new label types do not work, in the current Internet.
Deploying a new label type requires an effort similar to what
we are
going through right now with DNSSEC, upgrade all DNS protocol
processing elements, plus systems and processes that feed and
operate the DNS systems.
But, coming back to my example, this is exactly the problem with
internationalization. If one is willing to settle for keeping
ASCII primary and applying a hack to accommodate non-ASCII
characters, then one can avoid that very long and expensive
transition effort. We have such a solution in IDNA. Some parts
of the external community (including, albeit largely for
historical reasons, a couple of very significant vendors) do not
believe that is a satisfactory solution and that it would be
better to have all characters that are considered valid treated
equally.
That puts your DNSSEC comparison into an interesting light. I
believe that, when the DNSSEC effort started, the community
would have been appalled at how long deployment would take and
how painful it would be (with or without allowances were made
for reduced expectations). But, as far as I know, we didn't
have a good alternative way to do the job even in retrospect,
so, presumably, the community decided that the pain and slow
deployment associated with DNSSEC was (and is) worth it. Is a
clean i18n model on a par with that? I don't know (and I'm
personally willing to live with IDNA forever if we have to).
But I'm sure that some people would be willing to make the case
that such an i18n model is at least as important as DNSSEC and
worth whatever effort it would take.
As I've tried to say to Mark, based on the experience with
binary labels, I would have no problem if the document
deprecated binary labels, noted that deployment of different
label types is horrendously difficult and/or very slow and hence
not recommended unless the requirement is really important and
there are no plausible alternatives, and then just moved on.
There just doesn't seem to be nearly enough documented support
for moving beyond "we had a bad experience" to "completely
discard the feature/ capability".
I also note that part of what you said is "...do not work, in
the current Internet". I'm not sure what that means. If it
means that the WG has reached the conclusion that there are some
set of possible extensions that are sufficiently problematic
(including different label interpretation models) that they are
simply incompatible with the current DNS, i.e., that those who
want them should be working on a plausible strategy for what is
variously called DNSng or DNS2, I think that would be great and
an extremely useful contribution, especially as expectations for
things that DNS should do/support that lie well outside the
original design assumptions continue to increase... but the
document doesn't say that, much less describe that boundary.
Well as if DNS has reached some limits to extensibility this document
points out the
label types. Talking about other limitations is outside the documents
scope.
Personally at the time of introduction of the label registry I
thought
it was a good idea, but operational realities demonstrated
that its time
had passed, i.e. if we had defined more label types in
RFC1034/5 then
there might have been a chance. But given how many
implementations are
based on coding against what that implementor sees in traffic
dumps
rather than what is in the RFC's makes extending DNS much
harder than it should be, upgrading the installed base takes
decades.
Absolutely. But those same comments couple be an argument for
closing EDS down entirely except for the facilities needed to
support DNSSEC and maybe DNAME, i.e., "closing the registries"
as far as new options, header flags, etc., are concerned. What
you've said is a strong argument for caution, but I'm trying to
understand what makes label types so special as to require this
special treatment and to either get that understanding into the
document or to back away from the drastic measure.
Labels only work when all the severs for a zone that has a new label type,
in ADDITION sufficient fraction servers in all zones above that zone
MUST understand the new
label type.
in ADDITION all resolvers uses MUST understand the label type or treat
it as unknown
label type.
This is even harder problem than DNSSEC as it was possible to fetch data
via most resolvers
and configure local trust anchors or use TAR/DLV to create islands of
trust.
Olafur
<dnsext-chair-hat=on>
<document-shepard-hat=on>
If you think the text in the document does not reflect the
lessons
learned strongly enough I will be happy work with you on
putting better text in the document.