In message <56DB6FE506A144D1183B93A8@xxxxxxxxxxxxxxxxxx>, John C Klensin writes
:
>
>
> --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
I don't think we need to do this in label types. An EDNS option
would be sufficient to specify alternate normalisation rules should
be applied to the QNAME when looking for data and when normalising
the owner names when performing DNSSEC validation.
> _______________________________________________
> dnsext mailing list
> dnsext@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/dnsext
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka@xxxxxxx