--On Sunday, September 30, 2012 07:53 -0700 The IESG
<iesg-secretary@xxxxxxxx> 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
>
> The IESG plans to make a decision in the next few weeks, and
> solicits final comments on this action. Please send
> substantive comments to the ietf@xxxxxxxx mailing lists by
> 2012-10-29. Exceptionally, comments may be sent to
> iesg@xxxxxxxx instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>
> The Domain Name System's wire protocol includes a number of
> fixed fields whose range has been or soon will be exhausted
> and does not allow requestors to advertise their
> capabilities to responders. This document describes
> backward compatible mechanisms for allowing the protocol to
> grow.
>
> This document updates the EDNS(0) specification (and
> obsoletes RFC 2671) based on feedback from deployment
> experience in several implementations. It also closes the
> IANA registry for extended labels created as part of RFC
> 2671 and obsoletes RFC 2673 ("Binary Labels in the Domain
> Name System") which depends on the existence of extended
> labels.
>...
Hi. Apologies for not noticing this earlier, but this
specification's deprecation of label types raises an issue that
the document doesn't seem to address.
Deprecating RFC 2673 is one thing. Given deployment and
operational experience, I don't know of anyone who would offer a
strong defense of binary labels today. However, the document
doesn't offer a strong justification for deprecating label types
entirely other than, it seems, that there has been only one
example of their use and that failed. If that were the only
motivation, it would be a rather weak one, especially since
having a capability that we don't use (but conceivably might in
the future) would not appear to cause any harm.
With the understanding that this is an example, not a proposal,
it may be useful to review some of the history and context for
IDNs. IDNA represents community consensus as to the right way
to proceed, but that consensus includes both people who believe
it is a good permanent strategy and people who believe it is a
good temporary/transition strategy until a better plan can be
developed and deployed. In particular, some of that latter
group were painfully aware of the rate at which EDNS0 was
deploying in the first half of the last decade, making them more
receptive to IDNA (or other strategies that did not depend on
changes to DNS servers or resolvers).
So suppose the community really does decide that it wants
DNS-based IDNs and that it wants to see if they can be developed
and deployed within the existing DNS rather than moving to what
some have called DNSng. It is reasonably clear that what would
be called "just send 8" in the email community would not be
acceptable if only because there are DNS uses outside the public
network that use UTF-8 directly and others that use ISO 8859-1
or other character coding and repertoires (RFC 6055 discusses
some related issues). The proposal/thought piece I produced in
2001-2002 (with urging from some DNS-expert colleagues) to
transition to a new, i18n-sensitive, Class might be part of the
solution, but it is now clear that it would not be sufficient
(at least without considerable special-casing that would violate
both 1034/1035 and current trends). A different label type that
would permit specialized interpretations of the labels might be
an important part of the puzzle.
Would that be a good idea? I don't know. Personally, I believe
that some of the expectations of and demand for IDNs cannot be
met in the current DNS and that we should not try to go much
further than IDNA: if more is really needed, then it should be
accomplished either in an "above DNS" solution or by designing
and deploying DNS2. But I think it would be terribly unwise to
eliminate a facility that might be useful for i18n simply
because someone tried to use it for something entirely different
and that effort did not succeed.
Therefore:
(1) Did the WG consider i18n and other issues and possibilities
before deciding to deprecate extended label types entirely? If
so, why aren't those considerations described in the document?
We don't have a lot of codes left in the RFC 1035 space on which
other label type models might be constructed.
(2) Is there strong justification for deprecating extended label
types, e.g., evidence that they would cause harm?
(3) If the answer to either of both of the above questions is
"no", wouldn't it be wiser to simply deprecate the use of binary
labels, urge great caution in allocating and using other label
types, and then move on rather than eliminating the facility?
thanks,
john