- dns-wg - mailman.ripe.net

DNSSEC deployment on the reverse tree.
by Olaf M. Kolkman 07 Jul '05

07 Jul '05

[Apologies for duplicates] Dear Colleagues The RIPE NCC has been involved with the development of the DNSSEC protocol. Now that the protocol has become available, we plan to implement DNSSEC on our domains in the reverse DNS tree. The deployment of DNSSEC is the second and last phase of the Reverse DNS restructuring project. You can find more information about this project at: http://www.ripe.net/rs/reverse/dnssec/index.html To implement DNSSEC, we propose extending the policy for Policy for Reverse Address Delegation of IPv4 and IPv6 Address Space in the RIPE NCC Service Region. You can find the proposed policy at: http://www.ripe.net/rs/reverse/dnssec/draft-dnssec-policy.html. We welcome your feedback on this poposal before 1 August 2005. Please send your comments to the DNS Working Group Mailing List. We are also introducing two new procedures: "DNSSEC Key Maintenance Procedure" http://www.ripe.net/rs/reverse/dnssec/key-maintenance-procedure.html and "Procedure for Requesting DNSSEC Delegations" http://www.ripe.net/rs/reverse/dnssec/registry-procedure.html Your feedback on these drafts is also welcome, again please send this to the DNS Working Group Mailing List. As part of the "Procedure for Requesting DNSSEC Delegations" we plan to add a "ds-rdata:" attribute to DOMAIN objects. Regards Olaf M Kolkman New Projects, RIPE NCC.

3 6

Re: [dns-wg] Followup to IANA TLD delegation problem
by Marcel Schneider 23 Jun '05

23 Jun '05

On Friday, 10 Jun 2005, Doug Barton writes: Dear Doug Thanks for responding to Jim's questions. Reading your mail I still have difficulties understanding two issues: a) You state in [1] that after editing the root zone, VerSign experienced an "unexpected result". What exactly was the result what caused it ? Whould also appreciate if you could elaborate on how VerSign was able to fix this "unexpected result". b) When this "unexpected result" was regarded by IANA staff as temporary and as having minimal operational impact, why was AFNIC then sent this response to their application: "IANA is no longer adding additional examples of host names in delegation records where multiple host names point to the same IP address". The "no longer" suggests a policy change. Why did IANA not just say: "Folks we have a problem here, wait a moment until we've fixed it" ? Marcel > Thanks again for the opportunity to discuss these issues. I hope that the > group finds these answers satisfactory. We are of course happy to discuss > this in further detail if desired. > [1] What was the nature of the technical problem that prevented > multiple names in for an IP address and how was it resolved? > In November of 2004 AFNIC asked to have several hostnames added to the root > zone that resolved to the same IPv4 addresses as hostnames that already > existed. When VeriSign edited the root zone to include these new names, an > unexpected result occurred. In some of the TLDs that had the pre-existing > hostnames for these servers, the new hostnames appeared in the delegations > inappropriately. This problem was identified within several hours of the > zone going live by VeriSign staff, as well as at least one member of the > ccTLD community. The VeriSign and IANA staffs communicated immediately about > this issue, and the specific problem related to this request was fixed > manually by VeriSign in the next zone revision after it was identified. > Because in any pair of hostnames affected by this result the IPv4 address > was the same, the operational impact of this problem was minimal, if it was > identifiable at all. > [2] Why was there no announcement that this problem existed? > The specific problem applied only to new instances of duplicate names, it > did not affect existing duplicate names for which no change was in process. > The total number of these duplicate hostnames is very small relative to the > rest of the zone (less than 3%), and requests to modify domains which have > these hostnames in their delegations are rare. There were no instances of > such a request from November of 2004 through March of 2005, when AFNIC > submitted the request for the RE ccTLD. > Because the issue affected only a small number of TLDs and name server > operators, IANA staff chose to address the issue with those individuals > directly. Often TLD managers appreciate such specific cases being dealt with > on a personal level. > [3] Are safeguards now in place to prevent this sort of problem recurring? > Yes. VeriSign has informed us that the general problem which produced the > original unexpected result has now been corrected. Additionally, IANA staff > have enhanced efforts to monitor the "live" root zone from several different > servers, and use that data to proactively monitor the results of change > requests. > [4] What procedures does IANA (or ICANN?) have to make sure that changes > to the TLD delegation process or problems with that process are properly > communicated to its stakeholders? > The procedure that IANA uses to communicate changes in the TLD delegation > process follows the typical ICANN formula of involving key stakeholders at > early stages, opening proposals up for public comment, incorporating > appropriate comments into the final version, and posting the procedure for > its stakeholders. A relevant example of this process is the "Delegation Data > Procedure," which is posted at > http://www.iana.org/procedures/delegation-data.html. > Specific problems in the root management process are evaluated on a case by > case basis. When necessary, there is a mailing list composed of the contact > addresses for each of the TLD managers that can be utilized for any issue of > wide interest to the TLD manager community. As noted above, cases which > affect one, or a few TLDs are often dealt with on a one-to-one basis, with > the appreciation of the relevant TLD manager(s). > [5] Were those procedures followed for this incident? If not, why not? > The procedure for communicating changes to the TLD delegation process was > not followed in this specific case because there was no formal change of > process. > The specific problem which produced the delay in processing AFNIC's request > for RE was always understood to be temporary. As discussed above, rather > than widely disseminate the information about this issue to the TLD manager > community, IANA staff chose to communicate directly with those affected by > the issue. > ICANN's goal, as always, is to cooperate with the TLD managers in > implementing the changes they feel are appropriate for their TLDs, while > also maintaining the stability of the DNS. We regret if our cautious > handling of this particular request, or the timing of our responses to the > group's reasonable questions, has caused any undue confusion in the DNS > community about ICANN's dedication to that goal. We welcome comment and > discussion on these topics. > I am enclosing below some information about the current (at this writing, > 2005061000) root zone that may be relevant to this discussion. The first > part is the complete list of IPv4 addresses that have multiple hostnames > associated. There are no IPv6 addresses with multiple hostnames. The second > part is a compilation of statistics about the current zone. > Regards, > Doug > 128.112.129.15: dns.princeton.edu c.ext.nic.fr > 192.134.0.49: c.nic.fr ns3.nic.fr > 192.36.144.116: slave.sth.netnod.se slave1.sth.netnod.se > 192.93.0.1: a.nic.fr ns1.nic.fr > 192.93.0.4: b.nic.fr ns2.nic.fr > 193.176.144.6: e.ext.nic.fr ns3.domain-registry.nl > 193.51.208.13: dns.inria.fr a.ext.nic.fr > 204.152.184.64: ns-ext.vix.com ns-ext.isc.org > 204.74.112.1: tld1.basicfusion.net tld1.ultradns.net ud1.ns.net.ua > 204.74.113.1: tld2.basicfusion.net tld2.ultradns.net > Statistics > ========== > Number of gTLDs: 15 > Number of ccTLDs: 245 > Total number of TLDs: 260 > Number of IPv4 hosts: 798 > Number of IPv4 addresses: 798 > Number of IPv6 hosts: 40 > Number of IPv6 addresses: 41 > TLDs with IPv6 glue: 50 > Total TLD name server hosts: 797 > -- > Doug Barton > General Manager, The Internet Assigned Numbers Authority

5 5

Re: [dns-wg] Followup to IANA TLD delegation problem
by Doug Barton 16 Jun '05

16 Jun '05

Jim, Thanks again for the opportunity to discuss these issues. I hope that the group finds these answers satisfactory. We are of course happy to discuss this in further detail if desired. [1] What was the nature of the technical problem that prevented multiple names in for an IP address and how was it resolved? In November of 2004 AFNIC asked to have several hostnames added to the root zone that resolved to the same IPv4 addresses as hostnames that already existed. When VeriSign edited the root zone to include these new names, an unexpected result occurred. In some of the TLDs that had the pre-existing hostnames for these servers, the new hostnames appeared in the delegations inappropriately. This problem was identified within several hours of the zone going live by VeriSign staff, as well as at least one member of the ccTLD community. The VeriSign and IANA staffs communicated immediately about this issue, and the specific problem related to this request was fixed manually by VeriSign in the next zone revision after it was identified. Because in any pair of hostnames affected by this result the IPv4 address was the same, the operational impact of this problem was minimal, if it was identifiable at all. [2] Why was there no announcement that this problem existed? The specific problem applied only to new instances of duplicate names, it did not affect existing duplicate names for which no change was in process. The total number of these duplicate hostnames is very small relative to the rest of the zone (less than 3%), and requests to modify domains which have these hostnames in their delegations are rare. There were no instances of such a request from November of 2004 through March of 2005, when AFNIC submitted the request for the RE ccTLD. Because the issue affected only a small number of TLDs and name server operators, IANA staff chose to address the issue with those individuals directly. Often TLD managers appreciate such specific cases being dealt with on a personal level. [3] Are safeguards now in place to prevent this sort of problem recurring? Yes. VeriSign has informed us that the general problem which produced the original unexpected result has now been corrected. Additionally, IANA staff have enhanced efforts to monitor the "live" root zone from several different servers, and use that data to proactively monitor the results of change requests. [4] What procedures does IANA (or ICANN?) have to make sure that changes to the TLD delegation process or problems with that process are properly communicated to its stakeholders? The procedure that IANA uses to communicate changes in the TLD delegation process follows the typical ICANN formula of involving key stakeholders at early stages, opening proposals up for public comment, incorporating appropriate comments into the final version, and posting the procedure for its stakeholders. A relevant example of this process is the "Delegation Data Procedure," which is posted at http://www.iana.org/procedures/delegation-data.html. Specific problems in the root management process are evaluated on a case by case basis. When necessary, there is a mailing list composed of the contact addresses for each of the TLD managers that can be utilized for any issue of wide interest to the TLD manager community. As noted above, cases which affect one, or a few TLDs are often dealt with on a one-to-one basis, with the appreciation of the relevant TLD manager(s). [5] Were those procedures followed for this incident? If not, why not? The procedure for communicating changes to the TLD delegation process was not followed in this specific case because there was no formal change of process. The specific problem which produced the delay in processing AFNIC's request for RE was always understood to be temporary. As discussed above, rather than widely disseminate the information about this issue to the TLD manager community, IANA staff chose to communicate directly with those affected by the issue. ICANN's goal, as always, is to cooperate with the TLD managers in implementing the changes they feel are appropriate for their TLDs, while also maintaining the stability of the DNS. We regret if our cautious handling of this particular request, or the timing of our responses to the group's reasonable questions, has caused any undue confusion in the DNS community about ICANN's dedication to that goal. We welcome comment and discussion on these topics. I am enclosing below some information about the current (at this writing, 2005061000) root zone that may be relevant to this discussion. The first part is the complete list of IPv4 addresses that have multiple hostnames associated. There are no IPv6 addresses with multiple hostnames. The second part is a compilation of statistics about the current zone. Regards, Doug 128.112.129.15: dns.princeton.edu c.ext.nic.fr 192.134.0.49: c.nic.fr ns3.nic.fr 192.36.144.116: slave.sth.netnod.se slave1.sth.netnod.se 192.93.0.1: a.nic.fr ns1.nic.fr 192.93.0.4: b.nic.fr ns2.nic.fr 193.176.144.6: e.ext.nic.fr ns3.domain-registry.nl 193.51.208.13: dns.inria.fr a.ext.nic.fr 204.152.184.64: ns-ext.vix.com ns-ext.isc.org 204.74.112.1: tld1.basicfusion.net tld1.ultradns.net ud1.ns.net.ua 204.74.113.1: tld2.basicfusion.net tld2.ultradns.net Statistics ========== Number of gTLDs: 15 Number of ccTLDs: 245 Total number of TLDs: 260 Number of IPv4 hosts: 798 Number of IPv4 addresses: 798 Number of IPv6 hosts: 40 Number of IPv6 addresses: 41 TLDs with IPv6 glue: 50 Total TLD name server hosts: 797 -- Doug Barton General Manager, The Internet Assigned Numbers Authority

4 3

[Fwd: [centr-fm] Re: IANA TLD delegation issue]
by Kim Davies 13 Jun '05

13 Jun '05

Dear all, Olivier Guillard of AFNIC has described in the attached document the details of their attempts to redelegate their domains. It is a useful summary of the issue as they experienced it. kim -- Kim Davies, Council of European National Top Level Domain Registries Avenue Louise 327, B-1050 Brussels; Tel. +32 2 627 5550

10 31

Re: [dns-wg] Followup to IANA TLD delegation problem
by Jim Reid 08 Jun '05

08 Jun '05

>>>>> "Doug" == Doug Barton <doug.barton(a)icann.org> writes: Doug> Jim, We're happy to provide answers to these Doug> questions. Given that Monday is a holiday in the US, may I Doug> suggest that we will provide answers to the questions listed Doug> on Tuesday 31 May unless you or the WG indicate that more Doug> time is needed for you to formulate the list? Hi Doug. You'll have seen that there's been no detailed discussion in the last week or so on the mailing list about this issue. Most of the comments have seemed to echo the questions that were in my earlier mail. Assuming that you're back from paternity leave, I think it would now be helpful for these questions to be answered. This would allow us to finally resolve this issue and hopefully prevent it flaring up again in some other forum. Here are those questions once again: [1] What was the nature of the technical problem that prevented multiple names in for an IP address and how was it resolved? [2] Why was there no announcement that this problem existed? [3] Are safeguards now in place to prevent this sort of problem recurring? [4] What procedures does IANA (or ICANN?) have to make sure that changes to the TLD delegation process or problems with that process are properly communicated to its stakeholders? [5] Were those procedures followed for this incident? If not, why not?

2 1

Re: [dns-wg] Followup to IANA TLD delegation problem
by Jim Reid 31 May '05

31 May '05

>>>>> "Olivier" == Olivier Guillard / AFNIC <Olivier.Guillard(a)nic.fr> writes: Olivier> It is not perfectly clear for me what kind of Olivier> contribution you are waiting for to help moving forward, Olivier> and the kind of actions you see as conceivable to be Olivier> undertaken by the dns-wg ? My apologies for any confusion Olivier. My earlier mail was intended to provoke a discussion on the list. This discussion would hopefully allow the WG to reach consensus on: (a) if there were outstanding issues along the lines of the questions I posed; and (b) what the WG felt the next steps to resolve those issues could be. The response so far seems to be that further clarification is required but it's not critical. So if that's the consensus of the WG, the promised response from Doug could well be enough to close this issue. It's really up to the WG to decide what happens. If nobody cares, we just let things drop. If it's felt to be *really* important, then the WG could make another formal communication to ICANN/IANA. If the consensus is somewhere in between these two extremes, it may well be enough to wait for Doug's reply to my questions. As WG chair, I'd just like to find out what the WG's position is.

2 1

Re: [dns-wg] Followup to IANA TLD delegation problem
by Marcel Schneider 30 May '05

30 May '05

On Monday, 30 May 2005, Olivier Guillard / AFNIC writes: Dear all > as one of those that was looking for a path to operationaly > circumvent this new IANA policy, may I thank the dns-wg that > have clearly stated with others that "there is no technical > reason in the DNS protocols preventing this practice (aka: > "use different [NS] names for the same address"). To support Olivier's point: we also were relieved to hear from Doug Barton that no such policy was introduced. My question to Jim and maybe Jaap is: how did you became aware that ICANN/ IANA would or already has introduced such measures ? Unfortunately we at SWITCH do not hear the grass growing and were catched by surprise. It is important that we all fully understand the issue to learn from it. Marcel > The questions you raise now are very valid : >> [1] What was the nature of the technical problem that prevented >> multiple names in for an IP address and how was it resolved? >> >> [2] Why was there no announcement that this problem existed? >> >> [3] Are safeguards now in place to prevent this sort of problem >> recurring? >> >> [4] What procedures does IANA (or ICANN?) have to make sure that >> changes to the TLD delegation process or problems with that process >> are properly communicated to its stakeholders? >> >> [5] Were those procedures followed for this incident? If not, why not? > BTW, above the specific multinamming issue, they are now among the > core ones that need to be taken seriously by the DNS community in > my view. > I have looked in the dns-wg charter : > http://www.ripe.net/ripe/wg/dns/index.html > It is not perfectly clear for me what kind of contribution you are > waiting for to help moving forward, and the kind of actions you see > as conceivable to be undertaken by the dns-wg ? > Thanks, > Olivier > le mardi 24 mai à 11 H 47 , Jim Reid a ecrit : >> You'll all have seen the response from Doug Barton confirming that the >> technical problem has been fixed. It is now permitted to have multiple >> names for the same IP address in a TLD delegation from the root. That >> particular aspect of the discussion should be considered closed IMO >> because the problem has been resolved. However, there are some other >> things that I'd like the WG to consider and discuss. These concern the >> process and transparency issues that have been highlighted by this >> problem. >> >> I wonder if the WG would like to pursue these? >> >> In particular, I'd like the WG to consider if we should pursue answers >> to the following questions: >> >> [1] What was the nature of the technical problem that prevented >> multiple names in for an IP address and how was it resolved? >> >> [2] Why was there no announcement that this problem existed? >> >> [3] Are safeguards now in place to prevent this sort of problem >> recurring? >> >> [4] What procedures does IANA (or ICANN?) have to make sure that >> changes to the TLD delegation process or problems with that process >> are properly communicated to its stakeholders? >> >> [5] Were those procedures followed for this incident? If not, why not? >> >> If anyone here has more questions about this incident, please post >> them. If there's consensus in the WG that this matter needs further >> action, then we need to decide what the next steps, if any, should be. >> I'd welcome a discussion and comments. >> >> It's now over to you, the list members.... > -- > Olivier

1 0

Followup to IANA TLD delegation problem
by Jim Reid 30 May '05

30 May '05

You'll all have seen the response from Doug Barton confirming that the technical problem has been fixed. It is now permitted to have multiple names for the same IP address in a TLD delegation from the root. That particular aspect of the discussion should be considered closed IMO because the problem has been resolved. However, there are some other things that I'd like the WG to consider and discuss. These concern the process and transparency issues that have been highlighted by this problem. I wonder if the WG would like to pursue these? In particular, I'd like the WG to consider if we should pursue answers to the following questions: [1] What was the nature of the technical problem that prevented multiple names in for an IP address and how was it resolved? [2] Why was there no announcement that this problem existed? [3] Are safeguards now in place to prevent this sort of problem recurring? [4] What procedures does IANA (or ICANN?) have to make sure that changes to the TLD delegation process or problems with that process are properly communicated to its stakeholders? [5] Were those procedures followed for this incident? If not, why not? If anyone here has more questions about this incident, please post them. If there's consensus in the WG that this matter needs further action, then we need to decide what the next steps, if any, should be. I'd welcome a discussion and comments. It's now over to you, the list members....

7 6

Fwd: Questions on IANA TLD Operations
by Jim Reid 22 May '05

22 May '05

Here's the latest response from Doug. He confirms that IANA does permit multiple names for the same IP address for delegations in the root zone. I trust we can now consider this matter closed. Begin forwarded message: > From: Doug Barton <doug.barton(a)icann.org> > Date: May 21, 2005 20:53:13 BST > To: Jim Reid <jim(a)rfc1035.com> > Cc: iana(a)iana.org, Daniel <dfk(a)ripe.net>, Mohsen Souissi > <Mohsen.Souissi(a)nic.fr>, Jaap Akkerhuis <jaap(a)nlnetlabs.nl>, "Olaf M. > Kolkman" <olaf(a)ripe.net>, Lars-Johan Liman <liman(a)autonomica.se>, > Barbara Roseman <barbara.roseman(a)icann.org>, Peter Koch <pk(a)denic.de>, > Olivier Guillard <Olivier.Guillard(a)nic.fr>, philippe.lubrano(a)nic.fr > Subject: Re: Questions on IANA TLD Operations > > On Sat, 21 May 2005, Jim Reid wrote: > >> On May 21, 2005, at 04:09, Doug Barton wrote: >> >>> Thank you for raising this issue, my response is below. Please let >>> me know if you intend to forward this to the WG. Otherwise I am >>> happy to do so. >> >> Doug, many thanks for the timely reply. It was unfortunate that you >> were unable to be in Stockholm when this issue was raised at the WG. >> >> However I have to say that your reply leaves me as confused as I was >> when we sent the email to yourself and Barbara. Perhaps I've not had >> enough caffeine today to get the neurons firing. Your mail says "the >> problem is now fixed" without clarifying which problem you are >> referring to. One interpretation of your remarks could be that the >> problem with the .fr delegation has been resolved because AFNIC has >> applied the workaround you suggested. That interpretation of course >> leaves the questions we asked unanswered. Could you please give me a >> clear and unequivocal answer to this question: "Are TLDs permitted to >> register a hostname for their delegation when there is another >> hostname in the root zone for the same IP address?" Thanks. > > Yes. I do not know how to make it more unequivocal than that. :) > > I'm sorry that you found my answer confusing. One of the reasons it > took so long to produce (in addition to the fact that until Monday I > am technically still on leave) is that I had several people review it > to make sure that it was clear. I am sensitive to your point that > English is not the first language for many of the RIPE community, and > I appreciate your asking for clarification. > >> As far as forwarding your reply to the WG list is concerned, I think >> this should be my responsibility. > > That's totally appropriate, and I see that you have already done that, > thank you. My only concern is that given the fact that this issue was > raised in the WG, I want to be sure that they are informed of the > response. > > Regards, > > Doug > > -- > Doug Barton > General Manager, The Internet Assigned Numbers Authority >

1 0

Fwd: Questions on IANA TLD Operations
by Jim Reid 22 May '05

22 May '05

Here is the response we received from Doug Barton to the questions that we asked. I'm still confused. It's not clear to me what problem has been fixed or if IANA will now permit TLD delegations to include hostnames that have the same IP address as existing hostnames in the root zone. I've asked Doug for clarification: a clear statement whether this is or isn't permitted. I'll keep you informed of developments. Stay tuned.... Begin forwarded message: > From: Doug Barton <doug.barton(a)icann.org> > Date: May 21, 2005 04:09:03 BST > To: Jim Reid <jim(a)rfc1035.com> > Cc: Barbara Roseman <barbara.roseman(a)iana.org>, iana(a)iana.org, Daniel > <dfk(a)ripe.net>, Mohsen Souissi <Mohsen.Souissi(a)nic.fr>, Jaap Akkerhuis > <jaap(a)nlnetlabs.nl>, "Olaf M. Kolkman" <olaf(a)ripe.net>, Lars-Johan > Liman <liman(a)autonomica.se>, Peter Koch <pk(a)denic.de>, Olivier > Guillard <Olivier.Guillard(a)nic.fr>, philippe.lubrano(a)nic.fr > Subject: Re: Questions on IANA TLD Operations > > Jim, > > Thank you for raising this issue, my response is below. Please let me > know if you intend to forward this to the WG. Otherwise I am happy to > do so. > > In November of 2004 IANA received a request from AFNIC to add new > hostnames > for IP addresses of name servers that already existed in the root zone. > While there were a few examples of this already in the zone, this type > of > request is rare, and produced an unexpected result. ICANN has been > informed that this problem is now permanently fixed. > > Because at the time AFNIC submitted the recent request for > modifications to the RE ccTLD IANA had not yet been informed that the > problem was fixed, we asked them to choose a method of reaching their > operational goals other than adding new instances of the hostnames > that resolve to the same IP address. Because the problem is now fixed, > this will not be necessary in the future. > > I'm sorry that I did not get a chance to discuss these issues with you > in > person at the Stockholm meeting, as you noted I was called home > suddenly for > personal reasons. I do appreciate this opportunity to explain the > issues > involved, and I look forward to discussing it with you further if you > so > desire. > > Kind Regards, > > Doug > > -- > Doug Barton > General Manager, The Internet Assigned Numbers Authority > > > Jim Reid wrote: >> Apologies in advance for the cast of thousands on this message... >> I'm sending this on behalf of the co-chairs of the RIPE DNS Working >> Group in response to a discussion during RIPE50 last week. >> Dear Colleagues, >> This note follows a discussion at the DNS Working Group during last >> week's RIPE meeting. Doug was unable to take part in this discussion >> because he was called away early. Therefore we have sent you this >> message so that we can clear up any possible misunderstandings and >> hopefully avoid invoking more formal mechanisms. >> The RIPE DNS Working Group is concerned about some aspects of the >> current practice regarding IANA TLD operations. In particular the >> problems encountered by AFNIC last month are unsettling. >> It is our understanding that IANA has recently stopped accepting >> certain updates to the DNS root zone. The current practice now appears >> to require each particular network address used in glue address RRs to >> have one unique DNS name. This requirement is new: multiple names >> already exist in the root zone for some name server addresses. There >> is no technical reason in the DNS protocols preventing this practice. >> Important technical and operational goals can require TLD operators to >> use different names for the same address. The most obvious of these is >> more efficient name compression to make room for additional data in >> responses. Multiple names for the same address can reduce the amount >> of co-ordination required in case of name server address changes. >> We do not understand why this requirement has been introduced or the >> process by which it was agreed. The RIPE DNS Working Group is >> disappointed that this change appears to have been carried out by IANA >> without prior consultation or discussion. We would like to know >> rationale for this policy and the mechanism which led to its >> introduction. We'd appreciate any clarifications from you before >> Friday, >> May 20th. >> Regards >> ..... >> chairs RIPE DNS WG >

1 0