Re: [dnsext] Last Call: draft-ietf-dnsext-rfc2671bis-edns0-09.txt (Extension Mechanisms for DNS (EDNS(0))) to Internet Standard
Hello, At 18:13 16-10-2012, Olafur Gudmundsson wrote: 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 mgr...@isc.org is not a valid email address. 1. http://www.ietf.org/mail-archive/web/ietf-announce/current/msg10742.html
Re: [dnsext] Last Call: draft-ietf-dnsext-rfc2671bis-edns0-09.txt (Extension Mechanisms for DNS (EDNS(0))) to Internet Standard
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
Re: [dnsext] Last Call: draft-ietf-dnsext-rfc2671bis-edns0-09.txt (Extension Mechanisms for DNS (EDNS(0))) to Internet Standard
On 16/10/2012 17:43, SM wrote: 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? It was not explicitly discussed. Olafur Regards, -sm 1. http://www.ietf.org/mail-archive/web/ietf/current/msg75156.html
Re: [dnsext] Last Call: draft-ietf-dnsext-rfc2671bis-edns0-09.txt (Extension Mechanisms for DNS (EDNS(0))) to Internet Standard
On 2 Oct 2012, at 19:31, SM wrote: At 08:09 02-10-2012, John C Klensin wrote: 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. 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. 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. BTW, the RFC 2119 reference could be normative. Regards, -sm
Re: [dnsext] Last Call: draft-ietf-dnsext-rfc2671bis-edns0-09.txt (Extension Mechanisms for DNS (EDNS(0))) to Internet Standard
On 3 Oct 2012, at 14:10, John C Klensin wrote: --On Wednesday, October 03, 2012 10:43 +0200 João Damas j...@bondis.org 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, Yourself and Olafur 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. 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) 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. 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. (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). 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
Re: [dnsext] Last Call: draft-ietf-dnsext-rfc2671bis-edns0-09.txt (Extension Mechanisms for DNS (EDNS(0))) to Internet Standard
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 On 3 Oct 2012, at 03:15, Mark Andrews wrote: 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. 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: [dnsext] Last Call: draft-ietf-dnsext-rfc2671bis-edns0-09.txt (Extension Mechanisms for DNS (EDNS(0))) to Internet Standard
--On Friday, October 05, 2012 10:29 +0200 João Damas j...@bondis.org wrote: ... 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. 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. (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). 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
Re: [dnsext] Last Call: draft-ietf-dnsext-rfc2671bis-edns0-09.txt (Extension Mechanisms for DNS (EDNS(0))) to Internet Standard
On 02/10/2012 21:15, Mark Andrews wrote: 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. 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 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
Re: [dnsext] Last Call: draft-ietf-dnsext-rfc2671bis-edns0-09.txt (Extension Mechanisms for DNS (EDNS(0))) to Internet Standard
In message 506dbe9b.3070...@ogud.com, Olafur Gudmundsson writes: On 02/10/2012 21:15, Mark Andrews wrote: 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. 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 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. 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. Olafur -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: [dnsext] Last Call: draft-ietf-dnsext-rfc2671bis-edns0-09.txt (Extension Mechanisms for DNS (EDNS(0))) to Internet Standard
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
Re: [dnsext] Last Call: draft-ietf-dnsext-rfc2671bis-edns0-09.txt (Extension Mechanisms for DNS (EDNS(0))) to Internet Standard
--On Wednesday, October 03, 2012 10:43 +0200 João Damas j...@bondis.org 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
Re: [dnsext] Last Call: draft-ietf-dnsext-rfc2671bis-edns0-09.txt (Extension Mechanisms for DNS (EDNS(0))) to Internet Standard
--On Tuesday, October 02, 2012 23:39 -0700 SM s...@resistor.net wrote: 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. ... 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
Re: [dnsext] Last Call: draft-ietf-dnsext-rfc2671bis-edns0-09.txt (Extension Mechanisms for DNS (EDNS(0))) to Internet Standard
--On Tuesday, October 02, 2012 13:32 +1000 Mark Andrews ma...@isc.org 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
Re: [dnsext] Last Call: draft-ietf-dnsext-rfc2671bis-edns0-09.txt (Extension Mechanisms for DNS (EDNS(0))) to Internet Standard
At 08:09 02-10-2012, John C Klensin wrote: 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. 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
Re: [dnsext] Last Call: draft-ietf-dnsext-rfc2671bis-edns0-09.txt (Extension Mechanisms for DNS (EDNS(0))) to Internet Standard
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 o...@ogud.com 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 ... 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
Re: [dnsext] Last Call: draft-ietf-dnsext-rfc2671bis-edns0-09.txt (Extension Mechanisms for DNS (EDNS(0))) to Internet Standard
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. 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: [dnsext] Last Call: draft-ietf-dnsext-rfc2671bis-edns0-09.txt (Extension Mechanisms for DNS (EDNS(0))) to Internet Standard
In message 56db6fe506a144d1183b9...@jck-hp8200.jck.com, John C Klensin writes : --On Sunday, September 30, 2012 07:53 -0700 The IESG iesg-secret...@ietf.org 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@ietf.org mailing lists by 2012-10-29. Exceptionally, comments may be sent to i...@ietf.org 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 fixedfields whose range has been or soon will be exhausted and does notallow requestors to advertise their capabilities to responders. Thisdocument describes backward compatible mechanisms for allowing theprotocol to grow. This document updates the EDNS(0) specification (and obsoletes RFC2671) based on feedback from deployment experience in severalimplementations. It also closes the IANA registry for extendedlabels created as part of RFC 2671 and obsoletes RFC 2673 (BinaryLabels in the Domain Name System) which depends on the existence ofextended 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
Re: [dnsext] Last Call: draft-ietf-dnsext-rfc2671bis-edns0-09.txt (Extension Mechanisms for DNS (EDNS(0))) to Internet Standard
--On Tuesday, October 02, 2012 12:22 +1000 Mark Andrews ma...@isc.org 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? (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? ... 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
Re: [dnsext] Last Call: draft-ietf-dnsext-rfc2671bis-edns0-09.txt (Extension Mechanisms for DNS (EDNS(0))) to Internet Standard
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. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
