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

From: John C Klensin <[email-masked]>
Date: Mon, 01 Oct 2012 15:48:31 -0400

--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: Mark Andrews <[email-masked]>
Date: Tue, 02 Oct 2012 12:22:12 +1000

In message <[email-masked]>, John C Klensin writes
> types, and then move on rather than eliminating the facility?

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: John C Klensin <[email-masked]>
Date: Mon, 01 Oct 2012 22:56:59 -0400

--On Tuesday, October 02, 2012 12:22 +1000 Mark Andrews
<[email-masked]> wrote:

>> 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?
>> 
>> "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?
>...
> 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.

Mark,

First, it was just an example.   As I thought I made clear, my
main concern is about completely eliminating a facility because
one instance of trying to use it had not turned out to be as
useful as expected.  Absent demonstration that all possible uses
of the facility are actually useless or that the facility is
harmful, I don't think the case has been made for deprecating
it.   As far as that example is concerned, I don't think this is
the right place to review everything we've learned about i18n,
identifiers, and comparisons in the last couple of decades, but
normalization is just not a very large fraction of the problem.

    john

---

From: Mark Andrews <[email-masked]>
Date: Tue, 02 Oct 2012 13:32:52 +1000

Closing the registry is not irreversable if it needs to be reversed.
It's not like we can forget that there were assigned code points
and anything that attempted to use those code points would have to
consider the fact that they were used at one time.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 02 Oct 2012 11:01:37 -0400

On 01/10/2012 15:48, John C Klensin 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
>>
>> 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. ...
>
> 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.

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

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.

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.

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

     Olafur

>
> 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.
>
> (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
>
>
> _______________________________________________ dnsext mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/dnsext
>
>

---

From: John C Klensin <[email-masked]>
Date: Tue, 02 Oct 2012 11:09:25 -0400

--On Tuesday, October 02, 2012 13:32 +1000 Mark Andrews
<[email-masked]> wrote:

> Closing the registry is not irreversable if it needs to be
> reversed. It's not like we can forget that there were assigned
> code points and anything that attempted to use those code
> points would have to consider the fact that they were used at
> one time.

Actually, Mark, we very rarely close registries if there is any
possibility of reopening them.  We may raise the threshold for
registration, etc. (in this case, new types already require
standards action, which should make it adequately easy to head
off bad or frivolous ideas), but closing is a big step.  Telling
implementers that they don't need to pay attention to the
relevant codes and fields (and might even be able to use them
for a different, even if private, purpose) is an even more
serious step.

But I'd like to ask that this discussion move up a level.  My
question was about what the WG considered and whether, in the
light of those discussions, there was really justification to
take the serious step of abandoning a facility and consensus on
that justification.  It seems to me that your responses have
addressed different questions entirely: your opinion about
alternate approaches in the earlier note and a suggestion about
the possibility of reopening registries in this one. 

Because the questions I asked are tightly connected to what the
WG discussed and on what basis the presumably-consensus decision
was made, I would hope that I (and, more important, the IESG and
the community) would hear from the WG Chairs and other
participants, not only from someone who, coincidentally or not,
is part of the same organization as the three authors of the
draft (a draft that does not indicate the active participation
of any other people or organizations by the presence of an
Acknowledgments section).

best regards,
   john

---

From: John C Klensin <[email-masked]>
Date: Tue, 02 Oct 2012 12:38:22 -0400

--On Tuesday, October 02, 2012 11:01 -0400 Olafur Gudmundsson
<[email-masked]> wrote:

>>> (dnsext) to consider the following document: - 'Extension
>>> Mechanisms for DNS (EDNS(0))'

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.

>     if the name of the first answer record is not compressed (a

Understood.  Of course, some of the same things could be said
about EDNS0 itself.

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

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

> learned strongly enough I will be happy work with you on
> putting better text in the document.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 02 Oct 2012 18:34:17 -0400

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.

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

> 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

---

From: Mark Andrews <[email-masked]>
Date: Wed, 03 Oct 2012 11:15:56 +1000

> in ADDITION sufficient fraction servers in all zones above that zone 

Not true. Binary labels could have been made to work by removing
the left hand label until the remaining suffix consisted of only
RFC 1035 labels, looking up the servers for that domain, then
resuming query processing using those servers similar to what we
do with DS lookups.

Such processing would be required for any new label type used in a
QNAME and would be a significant change to the standard query logic.

Mark

---

From: John C Klensin <[email-masked]>
Date: Wed, 03 Oct 2012 08:10:41 -0400

--On Wednesday, October 03, 2012 10:43 +0200 João Damas
<[email-masked]> wrote:

> I believe you are saying the same things when you are both
> saying that for this to work there may be more than one way to
> do it but all options require completely new functionality in
> implementations (either by implementing support for new labels
> types or by implementing new fall back behavior). The
> conclusion is still the same.

Hmm.  I'm not completely sure who "you" was intended to include,
but my conclusion from the above is that there is no substantial
justification for eliminating, at this time, a capability that
might prove better on balance when and if new capabilities are
considered and tradeoffs evaluated.

To summarize my perspective on this as of now:

(1) No one is making a case for retaining binary labels

(2) The case has not been made, at least in the document, for
eliminating label types.  An argument that there are other ways
to do a particular type of label is not persuasive unless there
is a comprehensive and written analysis of what other labels
might be considered and what the tradeoffs among approaches
would be.  And an argument that almost any significant added
functionality would be very slow and costly to deploy may be an
argument for not approving such functionality, but it is not an
argument for eliminating one, but not all, of the underlying
capabilities.

IMO, this discussion has turned up two ways in which the case
for eliminating the possibility of additional label types could
be made:

(2.1) Demonstrating that simply having the capability defined
and available in principle is somehow harmful.

(2.2) The WG has consensus on a bright line that defines the
nature of proposals that would require going to DNSng rather
than EDNSx-type extensions to the current model, has concluded
that any extensions or alterations to the label definition of
1034/1035 would require crossing that line, and is prepared to
document that line and get IETF consensus on it (either as part
of this document or one normatively referenced from it).

best,
    john

---

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 04 Oct 2012 12:51:39 -0400

Mark,

This will only work if all the recursive resolvers that "consumers" for
this new label types have been updated AND the new label type is the 
left most label(s) in the name.

Olafur

---

From: Mark Andrews <[email-masked]>
Date: Fri, 05 Oct 2012 09:38:37 +1000

> left most label(s) in the name.

This works regardless of the position of the label.  If a TLD label
is a binary label then you strip back the labels until you reach
the root.

Resolvers involved in the lookup need to be updated and I didn't
dispute that.

---

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

---

From: João Damas <[email-masked]>
Date: Fri, 5 Oct 2012 10:29:52 +0200

> Hmm.  I'm not completely sure who "you" was intended to include,

Yourself and Olafur

> argument for eliminating one, but not all, of the underlying

fair enough. The groups consensus over the last years and after the experience with binary labels has been that new label types are basically undeployable because they require a complete renewal of all deployed resolvers.
On the other hand the use of EDNS extension mechanisms can be incrementally deployed (e.g. see some of DNSSEC features that leverage EDNS)

> and available in principle is somehow harmful.

People here can correct me, as my memory is fuzzy, but binary labels did cause harm to several deployed implementations. Don't know if this is just case in favour of natural selection.

> of this document or one normatively referenced from it).

Pretty much, that is my understanding. It is quite possible that this has been a position reached over many iterations of discussions and is not actually documented anywhere.

Joao

---

From: João Damas <[email-masked]>
Date: Tue, 2 Oct 2012 17:08:47 +0200

> better text in the document.

Also would text pointing out the preference to expand DNS's capabilities through EDNS rather than things like extended labels be seen as useful? That could be added to clarify this point if it helps to reduce the number of people left wondering and helps with pointing them in the preferred direction

Joao

---

From: João Damas <[email-masked]>
Date: Wed, 3 Oct 2012 10:43:06 +0200

I believe you are saying the same things when you are both saying that for this to work there may be more than one way to do it but all options require completely new functionality in implementations (either by implementing support for new labels types or by implementing new fall back behavior). The conclusion is still the same.

Joao

---

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

--On Friday, October 05, 2012 10:29 +0200 João Damas
<[email-masked]> wrote:

>> for eliminating the possibility of additional label types
>> could be made:
>> 

> People here can correct me, as my memory is fuzzy, but binary
> labels did cause harm to several deployed implementations.
> Don't know if this is just case in favour of natural selection.

Again, I'm not defending binary labels.  Many people thought
they were a good idea at the time.  But, just as "binary labels
failed" is a good argument for deprecating binary labels but not
a good argument for deprecating label types generally, "binary
labels caused harm" (assuming that is the case) would not be a
basis for inferring that all labels types would cause harm, much
less that retaining the capability for using extended label
types would be harmful.

Just as "some cows are brown and all cows are animals" doesn't
tell you a thing about the color of all animals, "binary labels
were a bad idea and binary labels are an instance of extended
label types" doesn't constitute an argument for deprecating
label types.

>> document that line and get IETF consensus on it (either as
>> part of this document or one normatively referenced from it).
 
> Pretty much, that is my understanding. It is quite possible
> that this has been a position reached over many iterations of
> discussions and is not actually documented anywhere.

If there is a bright line, it would definitely benefit the
broader community to be able to see a description and discuss
it.  If there is only a general feeling in the WG... well, that
doesn't count for much, especially given the history of
disagreements about what the base DNS specifications say and
what assorted terminology means.

   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