Subject: Re: [iucg] Last Call: <draft-ietf-dnsext-rfc2671bis-edns0-09.txt> (Extension Mechanisms for DNS (EDNS(0))) to Internet Standard

From: JFC Morfin <[email-masked]>
Date: Fri, 05 Oct 2012 05:50:53 +0200

John,

Thank you for this mail which has brought my attention to this 
critical issue. I fully support your position for two reasons:

1. It logically makes sense. It establishes a reasonable position 
while calling for at least some explanation.

2. I thought the key target was to keep the whole digital ecosystem 
name space consistent.

I have engaged in the preparation of a complete review of the digital 
naming from the point of view of the IETF RFCs. The target is to 
consider how it could be kept interoperational with other 
technologies and needs, such as ML-DNS, semantic addressing, and 
content centric networking, etc. We (IUTF) globally call this work 
"IUse specifications" (Intelligent Use of available resources). This 
work is not trivial on the technical side or the linguistic side, as 
it studies naming from what it permits now, and not from what it was 
planned for. Extended label types are Internet DNS features that will 
certainly be retained in these specs and the current prototyping work 
does include the support of Binary labels for testing.

The proposed sentence "This document obsoletes the use of the 2-bit 
combination defined by [RFC2671] to identify extended label types" 
is, therefore, at least premature. It would make the Internet DNS 
incompatible with the integrated universal digital naming syntax 
independent contribution that we planned to introduce in the coming 
months, but we can quickly produce a first draft if we feel that the 
IETF DNS might progressively, arbitrarily disintegrate in the meanwhile.

jfc

At 21:48 01/10/2012, John C Klensin wrote:
>--On Sunday, September 30, 2012 07:53 -0700 The IESG
><[email-masked]> 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 [email-masked] mailing lists by
> > 2012-10-29. Exceptionally, comments may be sent to
> > [email-masked] 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

---

From: John C Klensin <[email-masked]>
Date: Fri, 05 Oct 2012 14:07:21 -0400

Hi.   

Jefsey's note shows me that I should clarify why I think the
topic of deprecating labels types is worth the effort to
discuss.  

Let me suggest a little calibration about one aspect of this
discussion and its possible interactions with the plans Jefsey
mentions and plans others might have.

--On Friday, October 05, 2012 05:50 +0200 JFC Morfin
<[email-masked]> wrote:

>...
>  Extended label types are Internet DNS features that will
> certainly be retained in these specs and the current
> prototyping work does include the support of Binary labels for
> testing.

Because extended label types have never been successfully
deployed and used, it would be better to describe them as a
design opportunity than as a DNS feature.  More important, what
everyone who has looked closely at the "extended DNS" landscape
seems to agree on is that the practical deployment time for new
features is almost certain to be a decade or more.  Some new
features, like DNAME, can be designed so that upgraded servers
have a mechanism for dealing with un-upgraded clients (resolvers
and recursive servers) without loss of information or
functionality.  Others, like DNSSEC an binary labels, cannot.  

Even one decade is a rather long time in Internet years.  Few
communities have shown a willingness to sit around and wait that
long for good solutions.  Kludges and poor solutions that
address only part of the problem are much more attractive and
much more common.

However, deploying a necessarily-incompatible DNSng would almost
certainly take even longer. I assume that is one of the reasons
we have so much interest in (or toleration for) EDNSx and
incremental extension mechanisms.  

If there is any plausible possibility of developing new
extensions that build on label types in the future, then I think
it is a bad idea to deprecate the feature, no matter how many
arguments are made about alternate mechanisms or the failure of
one attempt.  On the other hand, if the intent is to get rid of
extension models that cannot be effectively deployed and used in
a few years, then any future EDNS0 extension that would require
a long deployment time before becoming useful should be
prohibited by the spec too.  I just don't see how one can have
it both ways... again, unless it can be demonstrated that the
existence of the label-type capability causes harm even if
unused.

best,
   john