Subject: Re: 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: 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: SM <[email-masked]>
Date: Tue, 02 Oct 2012 10:31:47 -0700

>for a different, even if private, purpose) is an even more

Yes.

In Section 6.1.2:

   "OPTION-CODE
          Assigned by the Expert Review process as defined by the dnsext
          working group and the IESG."

It's odd to keep this defined by a working group which is being 
closed.  Section 9.1 does not provide much information.  One 
significant change in the draft is the inclusion of requirements for 
"middleboxes".  It's not mentioned under in Appendix A.2.

BTW, the RFC 2119 reference could be normative.

Regards,
-sm

---

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.

On 02/10/2012 12:38, John C Klensin wrote:
>
> --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))'
>> 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.

---

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: SM <[email-masked]>
Date: Tue, 02 Oct 2012 23:39:20 -0700

From Section 7 of the draft:

  "Responders which choose not to implement the protocol extensions
   defined in this document MUST respond with a return code (RCODE) of
   FORMERR to messages containing an OPT RR in the additional section
   and MUST NOT include an OPT record in the response."

That looks like a change [1] to STD 13.  Responders which respond 
with a return code of 4 would not be compliant.

On publication of draft-ietf-dnsext-rfc2671bis-edns0-09, will it be 
part of STD 13?

 From RFC 3225:

   "In the event a server returns a NOTIMP, FORMERR or SERVFAIL response
    to a query that has the DO bit set, the resolver SHOULD NOT expect
    DNSSEC security RRs and SHOULD retry the query without EDNS0 in
    accordance with section 5.3 of [RFC2671]."

There's a normative reference [2] to that RFC in this draft.

In Section 1:

  "This document deprecates Extended Labels, and therefore Binary Labels,
    obsoleting [RFC2673]."

draft-ietf-dnsext-rfc6195bis-04 mentions that:

  "The Binary label type is Historic [RFC2671bis]."

The IETF might wish to consider whether it is necessary to align the 
text in the two drafts.

Regards,
-sm

1. Whether it is a change or not depends upon how one reads RFC 
6410.  The write-up mentions that there are no unused features in the 
specification that greatly increase implementation complexity.  It is 
unclear whether this document is a minor revision of RFC 2671.

2. http://www.ietf.org/mail-archive/web/weirds/current/msg01668.html

---

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: John C Klensin <[email-masked]>
Date: Wed, 03 Oct 2012 08:17:13 -0400

--On Tuesday, October 02, 2012 23:39 -0700 SM <[email-masked]>
wrote:

> That looks like a change [1] to STD 13.  Responders which
> respond with a return code of 4 would not be compliant.
>...
> The IETF might wish to consider whether it is necessary to
> align the text in the two drafts.
>...

One observation on this part of the thread...

While I'm much more concerned about the substantive impact of
deprecating a possibly-useful (even if painful to use) feature
without adequate justification and documentation, I believe that
documents being processed for classification as Internet
Standard should be held to a very high standard for editorial
quality and clarity and consistency of relationships to other
specifications.  If others agree with that belief, SM's analysis
appears to represent a strong case that the current version of
this draft (and possibly draft-ietf-dnsext-rfc6195bis-04) are
not ready for prime time.

   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: João Damas <[email-masked]>
Date: Tue, 2 Oct 2012 22:23:34 +0200

On 2 Oct 2012, at 19:31, SM wrote:

> It's odd to keep this defined by a working group which is being closed.

The process is (has been) defined by the wg. The assignment is done by the Expert Review process, not the wg.

>  Section 9.1 does not provide much information.  One significant change in the draft is the inclusion of requirements for "middleboxes".  It's not mentioned under in Appendix A.2.

OK, can add mention in there, no problem.

---

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: 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: SM <[email-masked]>
Date: Tue, 16 Oct 2012 14:43:56 -0700

Hi Olafur,

I posted the following question about the draft about two weeks ago [1]:

   "On publication of draft-ietf-dnsext-rfc2671bis-edns0-09, will it be
    part of STD 13?"

I did not see any comments from the WG about that.  I had an off-list 
exchange with the RFC Series Editor about STDs.  The question seems 
like an IETF matter.  Has this question been discussed by the WG, and 
if so, what was the conclusion?

Regards,
-sm

1. http://www.ietf.org/mail-archive/web/ietf/current/msg75156.html

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 16 Oct 2012 21:13:30 -0400

> if so, what was the conclusion?

It was not explicitly discussed.

     Olafur

---

From: SM <[email-masked]>
Date: Tue, 16 Oct 2012 23:48:18 -0700

Hello,
>It was not explicitly discussed.

The IESG received a request from the DNSEXT WG to create an Internet 
Standard [1].  The IESG solicited comments.  As this is the second 
last Call I presume that someone might know whether that Internet 
Standard will be STD 13 or something else.  Could the  information be shared?

Are there any guidelines about the publication of Internet Standards, 
i.e. how are STDs assigned and who does the assignment?

Regards,
-sm

P.S. According to mx.ams1.isc.org [email-masked] is not a valid email address.

1. http://www.ietf.org/mail-archive/web/ietf-announce/current/msg10742.html