From anandb at ripe.net Thu Nov 13 15:54:54 2014 From: anandb at ripe.net (Anand Buddhdev) Date: Thu, 13 Nov 2014 15:54:54 +0100 Subject: [dns-wg] RIPE NCC DNSSEC trust anchors Message-ID: <5464C63E.2010104@ripe.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear colleagues, Most of the zones that the RIPE NCC signs with DNSSEC have trust anchors in their parent zones, with the exception of these three zones: 151.76.62.in-addr.arpa ripe.int ripen.cc We have been publishing trust anchors for these three zones on our website, as well as in the ISC DLV trust anchor repository (TAR): https://dlv.isc.org On Tuesday, 11 November 2014, we rolled our DNSSEC Key Signing Keys and added the new trust anchors for these three zones to the ISC DLV TAR. Because we believe manual configuration of trust anchors is very rare these days, we are taking this opportunity to stop publishing trust anchors for these three zones on our website. The trust anchors remain available via the ISC DLV TAR. Of course, as soon as we are able to publish DS records for these zones in their parents, we will do so and withdraw them from the ISC DLV TAR, as we have done for all our other zones. If you have any questions or concerns, please send email to dns at ripe.net. Regards, Anand Buddhdev Senior Engineer RIPE NCC -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlRkxj4ACgkQi+U8Q0SwlCvWtQCgiCxJt53Ala7tTYXzzXW6787w GPcAn0a/u+aRB8BlpTT5cp5QomFo/LSB =ZAsP -----END PGP SIGNATURE----- From Woeber at CC.UniVie.ac.at Thu Nov 13 16:18:01 2014 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Thu, 13 Nov 2014 16:18:01 +0100 Subject: [dns-wg] RIPE NCC DNSSEC trust anchors In-Reply-To: <5464C63E.2010104@ripe.net> References: <5464C63E.2010104@ripe.net> Message-ID: <5464CBA9.7090909@CC.UniVie.ac.at> Well, this may be seen as a stupid question from a DNS DAU, but can you explain what ripe.int (an international treaty organisation?) and ripen.cc are used for? Thanks, Wilfried Anand Buddhdev wrote: > Dear colleagues, > > Most of the zones that the RIPE NCC signs with DNSSEC have trust anchors > in their parent zones, with the exception of these three zones: > > 151.76.62.in-addr.arpa > ripe.int > ripen.cc > > We have been publishing trust anchors for these three zones on our > website, as well as in the ISC DLV trust anchor repository (TAR): > https://dlv.isc.org > > On Tuesday, 11 November 2014, we rolled our DNSSEC Key Signing Keys > and added the new trust anchors for these three zones to the ISC > DLV TAR. Because we believe manual configuration of trust anchors is > very rare these days, we are taking this opportunity to stop publishing > trust anchors for these three zones on our website. The trust anchors > remain available via the ISC DLV TAR. Of course, as soon as we are > able to publish DS records for these zones in their parents, we will > do so and withdraw them from the ISC DLV TAR, as we have done for all > our other zones. > > If you have any questions or concerns, please send email to dns at ripe.net. > > Regards, > > Anand Buddhdev > Senior Engineer > RIPE NCC From ripe-wgs.cs at schiefner.de Thu Nov 13 16:57:54 2014 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Thu, 13 Nov 2014 16:57:54 +0100 Subject: [dns-wg] RIPE NCC DNSSEC trust anchors In-Reply-To: <5464CBA9.7090909@CC.UniVie.ac.at> References: <5464C63E.2010104@ripe.net> <5464CBA9.7090909@CC.UniVie.ac.at> Message-ID: <5464D502.7070302@schiefner.de> Hi Anand, On 13.11.2014 16:18, Wilfried Woeber wrote: > Well, this may be seen as a stupid question from a DNS DAU, > > but can you explain what ripe.int (an international treaty organisation?) > and ripen.cc are used for? I'd like to second Wilfried's question at least for the .int part. Thanks, -C. From jim at rfc1035.com Thu Nov 13 17:03:03 2014 From: jim at rfc1035.com (Jim Reid) Date: Thu, 13 Nov 2014 16:03:03 +0000 Subject: [dns-wg] RIPE NCC DNSSEC trust anchors In-Reply-To: <5464C63E.2010104@ripe.net> References: <5464C63E.2010104@ripe.net> Message-ID: On 13 Nov 2014, at 14:54, Anand Buddhdev wrote: > Signed PGP part > Dear colleagues, > > Most of the zones that the RIPE NCC signs with DNSSEC have trust anchors > in their parent zones, with the exception of these three zones: > > 151.76.62.in-addr.arpa > ripe.int > ripen.cc > > We have been publishing trust anchors for these three zones on our > website, as well as in the ISC DLV trust anchor repository (TAR): > https://dlv.isc.org > > On Tuesday, 11 November 2014, we rolled our DNSSEC Key Signing Keys > and added the new trust anchors for these three zones to the ISC > DLV TAR. Because we believe manual configuration of trust anchors is > very rare these days, we are taking this opportunity to stop publishing > trust anchors for these three zones on our website. The trust anchors > remain available via the ISC DLV TAR. Of course, as soon as we are > able to publish DS records for these zones in their parents, we will > do so and withdraw them from the ISC DLV TAR, as we have done for all > our other zones. Anand, I am confused. 62/8 is under RIPE NCC control. There are DS records for 62.in-addr.arpa which presumably got put there by the NCC. So why does anything underneath that domain have to be in DLV? I would very much like to see a timetable and plan for the removal of RIPE NCC managed zones from DLV. Is there a worthwhile reason for any NCC-managed reverse zones and keying material to remain there? I can't think of one. As for the other two domain names, do you have any statistics on how often they are used/looked up and why? And of those lookups, how many result in DLV-flavour validation? How often do URLs containing these two domain names appear in web content or whatever? ie Does validation of these two domains actually matter to anything? Neither of these TLDs seem appropriate for the NCC. IIRC ripen.cc was a botched experiment some years ago that was quietly buried. [Apparently URLs with a ripen.cc hostname were shorter than those which used ripe.net. Go figure.] It would seem the only reason for holding on to these two domain names would be for defensive registrations and/or to put an HTTP redirect to ripe.net. Either way, there doesn't seem much point in signing these zones and far less populating DLV with DS records for them. Maybe I've missed something. I appreciate your understandable need for caution here Anand and to avoid surprises. However, there hasn't been a need to use DLV for NCC-managed zones for a few years now. So I think it's about time to pull the plug on the NCC's DLV involvement forever. After giving everyone sufficient notice of course. I hope your email is the start of that process Of course what happens to DLV once the NCC's stuff is removed remains a decision for ISC. My views on that are well known. From pk at DENIC.DE Thu Nov 13 18:38:37 2014 From: pk at DENIC.DE (Peter Koch) Date: Thu, 13 Nov 2014 18:38:37 +0100 Subject: [dns-wg] RIPE NCC DNSSEC trust anchors In-Reply-To: <5464C63E.2010104@ripe.net> References: <5464C63E.2010104@ripe.net> Message-ID: <20141113173837.GP26226@x28.adm.denic.de> Anand, all, On Thu, Nov 13, 2014 at 03:54:54PM +0100, Anand Buddhdev wrote: > 151.76.62.in-addr.arpa > ripe.int > ripen.cc > On Tuesday, 11 November 2014, we rolled our DNSSEC Key Signing Keys > and added the new trust anchors for these three zones to the ISC > DLV TAR. Because we believe manual configuration of trust anchors is > very rare these days, we are taking this opportunity to stop publishing > trust anchors for these three zones on our website. The trust anchors > remain available via the ISC DLV TAR. Of course, as soon as we are Thanks for this note. I'd rather not see the RIPE NCC further endorse the DLV technology and service by continuing to submit key material there. DLV was meant as a temporary deployment aid and might have been a good idea at its time. Nowadays, I consider it detrimental to deployment because it complicates matters for everybody deciding to actually validate (getting those figures up is the real challenge). Manually configured trust anchors aren't the ultimate wisdom, either, so with regard to the three zones above I wonder a) what is the actual benefit of extra steps for publishing the KSK out of band (continued signing obviously stremlines processes)? b) what steps could be taken to get the TA published the "natural" way? This is probably most interesting for the INT TLD, given all the current transition debate. Regards, Peter (no hat) From randy at psg.com Thu Nov 13 18:44:37 2014 From: randy at psg.com (Randy Bush) Date: Thu, 13 Nov 2014 07:44:37 -1000 Subject: [dns-wg] RIPE NCC DNSSEC trust anchors In-Reply-To: <20141113173837.GP26226@x28.adm.denic.de> References: <5464C63E.2010104@ripe.net> <20141113173837.GP26226@x28.adm.denic.de> Message-ID: > I'd rather not see the RIPE NCC further endorse the DLV technology and > service by continuing to submit key material there. thank you > DLV was meant as a temporary deployment aid and might have been a good > idea at its time. or not randy From bmanning at isi.edu Thu Nov 13 18:55:00 2014 From: bmanning at isi.edu (manning bill) Date: Thu, 13 Nov 2014 09:55:00 -0800 Subject: [dns-wg] RIPE NCC DNSSEC trust anchors In-Reply-To: <5464CBA9.7090909@CC.UniVie.ac.at> References: <5464C63E.2010104@ripe.net> <5464CBA9.7090909@CC.UniVie.ac.at> Message-ID: once, long ago, there was a serious and aggressive move to remove .arpa we moved everything into .int and included the rirs as organizations responsible for the numbers. then it was pointed out that replacing all the resolver libraries might be problematic and DNAME had not been invented? then the IAB decided to repurpose .arpa (changed the name) and ICANN took over .int ? but they didn?t do a real good job of cleaning up. so we still have .arpa and .int is strictly treaty orgs (or should be). i guess one could argue RIPE is an offshoot of a treaty org (the EU) /bill PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 13November2014Thursday, at 7:18, Wilfried Woeber wrote: > .int From dougb at dougbarton.us Thu Nov 13 19:05:55 2014 From: dougb at dougbarton.us (Doug Barton) Date: Thu, 13 Nov 2014 10:05:55 -0800 Subject: [dns-wg] RIPE NCC DNSSEC trust anchors In-Reply-To: <5464C63E.2010104@ripe.net> References: <5464C63E.2010104@ripe.net> Message-ID: <5464F303.5090704@dougbarton.us> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 11/13/14 6:54 AM, Anand Buddhdev wrote: | Dear colleagues, | | Most of the zones that the RIPE NCC signs with DNSSEC have trust | anchors in their parent zones, with the exception of these three | zones: | | 151.76.62.in-addr.arpa ripe.int ripen.cc As others have already pointed out, I would love to see explanations of why the first and third zones cannot have proper trust anchors. The NCC should simply release ripe.int, as the historical reasons for it no longer apply. (FWIW, same goes for apnic.int. None of the other RIRs have similar domains.) Doug -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJUZPMDAAoJEFzGhvEaGryE3PQIAL1pP7xmGW69C6AC9VzJbupZ 068Dau7lR9RiqXpPPe+sZdpMwXs3Q1Bf+aa8rZ6CNcQw/fTuGYtWd9f9x04DhVgo dIvNctoxSf0PHbGtCqJ/9pb8a+r29wkY67JwKgNy30x5SGg/Z3yMoit49ftD3DqI bMfhWL1037J6YuXz7UnaRWe52OhdbPDVMVO1J9jEV8dWqFcO1DDiP2ATWG3YQQ/l mDSxo7WG9Oja9mgk1zMjldc0NJo1XqmrJRnsy/k6hEkG/F+QJdIWMNH8VDqZC3wB 6l54wvljRgVEbNeZc5ToVGDoWY+nsQ3wJvA+GDkLNjpdzwa1TAXOeoJMP1UT/VM= =vmmW -----END PGP SIGNATURE----- From jim at rfc1035.com Thu Nov 13 20:00:14 2014 From: jim at rfc1035.com (Jim Reid) Date: Thu, 13 Nov 2014 19:00:14 +0000 Subject: [dns-wg] RIPE NCC DNSSEC trust anchors In-Reply-To: <20141113173837.GP26226@x28.adm.denic.de> References: <5464C63E.2010104@ripe.net> <20141113173837.GP26226@x28.adm.denic.de> Message-ID: <1691084F-8A5B-452E-983D-D1CEC7A369A3@rfc1035.com> On 13 Nov 2014, at 17:38, Peter Koch wrote: > I'd rather not see the RIPE NCC further endorse the DLV technology and service by continuing to submit key material there. +100 What's this? Peter and myself in agreement? Something is wrong. :-) From k13 at nikhef.nl Thu Nov 13 21:12:35 2014 From: k13 at nikhef.nl (Rob Blokzijl) Date: Thu, 13 Nov 2014 21:12:35 +0100 (MET) Subject: [dns-wg] RIPE NCC DNSSEC trust anchors In-Reply-To: References: <5464C63E.2010104@ripe.net> <5464CBA9.7090909@CC.UniVie.ac.at> Message-ID: > i guess one could argue RIPE is an offshoot of a treaty org (the EU) > > /bill No, it is not. Rob From bmanning at isi.edu Thu Nov 13 21:22:34 2014 From: bmanning at isi.edu (manning bill) Date: Thu, 13 Nov 2014 12:22:34 -0800 Subject: [dns-wg] RIPE NCC DNSSEC trust anchors In-Reply-To: References: <5464C63E.2010104@ripe.net> <5464CBA9.7090909@CC.UniVie.ac.at> Message-ID: <574888A4-9667-417B-9EF1-C218BAED7548@isi.edu> the EU is not a treaty based org? I thought that the Maastricht Treaty in 1993 created the EU. certainly RIPE existed before then (didm;t it emerge from RARE?)? which if memory serves, was an agreement between several organizations to work together. While that might not have engendered a formal, state-recognized treaty, it was an agreement? There. I have argued. Lets move on /bill PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 13November2014Thursday, at 12:12, Rob Blokzijl wrote: >> i guess one could argue RIPE is an offshoot of a treaty org (the EU) >> >> /bill > > No, it is not. > > Rob From drc at virtualized.org Thu Nov 13 21:28:32 2014 From: drc at virtualized.org (David Conrad) Date: Thu, 13 Nov 2014 10:28:32 -1000 Subject: [dns-wg] RIPE NCC DNSSEC trust anchors In-Reply-To: <5464F303.5090704@dougbarton.us> References: <5464C63E.2010104@ripe.net> <5464F303.5090704@dougbarton.us> Message-ID: On Nov 13, 2014, at 7:44 AM, Randy Bush wrote: >> I'd rather not see the RIPE NCC further endorse the DLV technology and >> service by continuing to submit key material there. > > thank you > >> DLV was meant as a temporary deployment aid and might have been a good >> idea at its time. > > or not > > randy > +1 On Nov 13, 2014, at 8:05 AM, Doug Barton wrote: > The NCC should simply release ripe.int, as the historical reasons for > it no longer apply. (FWIW, same goes for apnic.int. None of the other > RIRs have similar domains.) +1 Regards, -drc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From pk at DENIC.DE Thu Nov 13 21:50:24 2014 From: pk at DENIC.DE (Peter Koch) Date: Thu, 13 Nov 2014 21:50:24 +0100 Subject: [dns-wg] {Use of} the INT TLD {by the NCC and others} [Re: RIPE NCC DNSSEC trust anchors] In-Reply-To: References: <5464C63E.2010104@ripe.net> <5464F303.5090704@dougbarton.us> Message-ID: <20141113205024.GV26226@x28.adm.denic.de> On Thu, Nov 13, 2014 at 10:28:32AM -1000, David Conrad wrote: > On Nov 13, 2014, at 8:05 AM, Doug Barton wrote: > > The NCC should simply release ripe.int, as the historical reasons for > > it no longer apply. (FWIW, same goes for apnic.int. None of the other > > RIRs have similar domains.) > > +1 this might be the exact wrong point in time. The NCC likely does not fulfill the eligibility criterie laid out in , but obviously the registrations in INT benefit from a genaral protection of confidence. Also, the 'policy' document linked above does not provide for a revocation mechanism. So, there is a registrant in INT interested in having key material published. What does it take to get INT sigend? What is the governing body? The 'policy' document bases itself on RFC 1591 but also says "The IANA no longer _grants_ .int domain names [...]". While this particular issue is out of scope, the text may be read as if "the IANA" was acting with its own authority rather than being a registry operator bound by some policy set by the competent body. So, again: who is to be convinced to make INT signed? -Peter From jim at rfc1035.com Thu Nov 13 21:55:42 2014 From: jim at rfc1035.com (Jim Reid) Date: Thu, 13 Nov 2014 20:55:42 +0000 Subject: [dns-wg] oversight of .int In-Reply-To: <20141113205024.GV26226@x28.adm.denic.de> References: <5464C63E.2010104@ripe.net> <5464F303.5090704@dougbarton.us> <20141113205024.GV26226@x28.adm.denic.de> Message-ID: <2BA88DE2-6492-49A2-83BB-BEB683CE069B@rfc1035.com> On 13 Nov 2014, at 20:50, Peter Koch wrote: > So, again: who is to be convinced to make INT signed? Runs away screaming... The politics around .int and its oversight are... well... interesting. It might be inadvisable to dive into that while the IANA arrangements are in flux. From drc at virtualized.org Thu Nov 13 22:21:00 2014 From: drc at virtualized.org (David Conrad) Date: Thu, 13 Nov 2014 11:21:00 -1000 Subject: [dns-wg] {Use of} the INT TLD {by the NCC and others} [Re: RIPE NCC DNSSEC trust anchors] In-Reply-To: <20141113205024.GV26226@x28.adm.denic.de> References: <5464C63E.2010104@ripe.net> <5464F303.5090704@dougbarton.us> <20141113205024.GV26226@x28.adm.denic.de> Message-ID: Peter, On Nov 13, 2014, at 10:50 AM, Peter Koch wrote: > On Thu, Nov 13, 2014 at 10:28:32AM -1000, David Conrad wrote: > >> On Nov 13, 2014, at 8:05 AM, Doug Barton wrote: >>> The NCC should simply release ripe.int, as the historical reasons for >>> it no longer apply. (FWIW, same goes for apnic.int. None of the other >>> RIRs have similar domains.) >> >> +1 > > this might be the exact wrong point in time. Or, given the IANA Functions transition, the exact right point in time if people want to avoid a pointless political food fight. > The NCC likely does not fulfill > the eligibility criterie laid out in , > but obviously the registrations in INT benefit from a genaral protection > of confidence. What's a "general protection of confidence"? > Also, the 'policy' document linked above does not provide > for a revocation mechanism. If an entity does not meet the documented policy criteria, then it should not be in the zone. However, IANA does not unilaterally remove zones. Traditionally, the entity simply says "please remove my entry". Are you recommending RIPE knowingly and intentionally violate a documented policy? > So, there is a registrant in INT interested in having key material published. > What does it take to get INT signed? Currently, .INT is part of the IANA Functions contract. My understanding (which is NOT authoritative) is that efforts are underway to get .INT signed, but that it requires approval by NTIA. > What is the governing body? As mentioned, management of .INT is part of the IANA Functions contract, specifically section C.2.9.4 of http://www.ntia.doc.gov/files/ntia/publications/sf_26_pg_1-2-final_award_and_sacs.pdf. > The 'policy' > document bases itself on RFC 1591 but also says "The IANA no longer _grants_ > .int domain names [...]". Um, yeah. 1591 also says "Second level names in INT are registered by the PVM at ISI.EDU." Good luck with that. I personally find the cherry picking of RFC 1591 quite fascinating. The Internet has changed a bit since 1994 and it has never been clear to me that relying on that document in contravention to existing evolved policies makes a lot of sense. > While this particular issue is out of scope, the > text may be read as if "the IANA" was acting with its own authority rather > than being a registry operator bound by some policy set by the competent body. It may be read that way, but doing so would simply be wrong. My understanding is that the policy used for .INT registrations was created by Mike St. Johns when he was at DARPA. The fact that there are historical anomalies (e.g., tpc.int, ripe.int, apnic.int, ymca.int, etc), are, in my personal view, things that should be cleaned up, not things that should be used to stir up the political muck. > So, again: who is to be convinced to make INT signed? Until the IANA Functions transition, NTIA. After the transition: that's an interesting question. Can we just ask for RIPE.INT to be dropped from the .INT zone? Does RIPE actually use it for anything other than a redirect to RIPE.NET? Regards, -drc (ICANN CTO, but speaking only for myself. Really.) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From kim.davies at icann.org Thu Nov 13 22:56:47 2014 From: kim.davies at icann.org (Kim Davies) Date: Thu, 13 Nov 2014 21:56:47 +0000 Subject: [dns-wg] {Use of} the INT TLD {by the NCC and others} [Re: RIPE NCC DNSSEC trust anchors] In-Reply-To: <20141113205024.GV26226@x28.adm.denic.de> References: <5464C63E.2010104@ripe.net> <5464F303.5090704@dougbarton.us> <20141113205024.GV26226@x28.adm.denic.de> Message-ID: Hi Peter, > So, there is a registrant in INT interested in having key material published. > What does it take to get INT sigend? It is our desire to sign .INT and we are working on making it happen. It is the only zone we manage that isn?t signed and we are keen to reach 100%. There is probably not a lot more I can say beyond that at this time. kim From nick at foobar.org Thu Nov 13 23:07:56 2014 From: nick at foobar.org (Nick Hilliard) Date: Thu, 13 Nov 2014 22:07:56 +0000 Subject: [dns-wg] {Use of} the INT TLD {by the NCC and others} [Re: RIPE NCC DNSSEC trust anchors] In-Reply-To: References: <5464C63E.2010104@ripe.net> <5464F303.5090704@dougbarton.us> <20141113205024.GV26226@x28.adm.denic.de> Message-ID: <54652BBC.8060700@foobar.org> On 13/11/2014 21:21, David Conrad wrote: > Can we just ask for RIPE.INT to be dropped from the .INT zone? there isn't enough bikeshed in the universe to handle a suggestion like this. Nick From barbara.roseman at icann.org Thu Nov 13 23:22:35 2014 From: barbara.roseman at icann.org (Barbara Roseman) Date: Thu, 13 Nov 2014 22:22:35 +0000 Subject: [dns-wg] {Use of} the INT TLD {by the NCC and others} [Re: RIPE NCC DNSSEC trust anchors] In-Reply-To: <20141113205024.GV26226@x28.adm.denic.de> References: <5464C63E.2010104@ripe.net> <5464F303.5090704@dougbarton.us> , <20141113205024.GV26226@x28.adm.denic.de> Message-ID: <31B785EB-6C4F-49C1-83A7-D99D866EFF12@icann.org> ICANN inherited a number of INT registrations when it assumed management of the zone. Since 2005, at least, and probably since 1998, only treaty-based organizations who meet the other criteria have been given registrations, to the best of my knowledge. I believe that ICANN uses an outside expert who has experience with UN treaty organizations to evaluate the requests for .INT registrations. -Barb Sent from my mobile. > On Nov 13, 2014, at 10:51 AM, Peter Koch wrote: > >> On Thu, Nov 13, 2014 at 10:28:32AM -1000, David Conrad wrote: >> >>> On Nov 13, 2014, at 8:05 AM, Doug Barton wrote: >>> The NCC should simply release ripe.int, as the historical reasons for >>> it no longer apply. (FWIW, same goes for apnic.int. None of the other >>> RIRs have similar domains.) >> >> +1 > > this might be the exact wrong point in time. The NCC likely does not fulfill > the eligibility criterie laid out in , > but obviously the registrations in INT benefit from a genaral protection > of confidence. Also, the 'policy' document linked above does not provide > for a revocation mechanism. > > So, there is a registrant in INT interested in having key material published. > What does it take to get INT sigend? What is the governing body? The 'policy' > document bases itself on RFC 1591 but also says "The IANA no longer _grants_ > .int domain names [...]". While this particular issue is out of scope, the > text may be read as if "the IANA" was acting with its own authority rather > than being a registry operator bound by some policy set by the competent body. > So, again: who is to be convinced to make INT signed? > > -Peter > From dougb at dougbarton.us Thu Nov 13 23:22:46 2014 From: dougb at dougbarton.us (Doug Barton) Date: Thu, 13 Nov 2014 14:22:46 -0800 Subject: [dns-wg] {Use of} the INT TLD {by the NCC and others} [Re: RIPE NCC DNSSEC trust anchors] In-Reply-To: <54652BBC.8060700@foobar.org> References: <5464C63E.2010104@ripe.net> <5464F303.5090704@dougbarton.us> <20141113205024.GV26226@x28.adm.denic.de> <54652BBC.8060700@foobar.org> Message-ID: <54652F36.9000509@dougbarton.us> On 11/13/14 2:07 PM, Nick Hilliard wrote: > On 13/11/2014 21:21, David Conrad wrote: >> Can we just ask for RIPE.INT to be dropped from the .INT zone? > > there isn't enough bikeshed in the universe to handle a suggestion like this. Nick, But that's just the point, it doesn't have to be a bikeshed. RIPE and APNIC can simply ask ICANN to un-delegate the names, and then we're done. And regarding Peter's point, this is the *perfect* time for them to do so. It helps reinforce the point that the bottom-up stakeholder model works, because people of good will are willing and able to do the right thing. There is no reason for those names to exist now, in spite of the historical reasons that they were created in the past. The only way this turns into a bikeshed is if RIPE and APNIC don't agree to do the right thing and drop the names. Doug PS, I'm not sure you're using the term 'bikeshed' in the right context there. Have a look at http://en.wikipedia.org/wiki/Parkinson%27s_law_of_triviality From dougb at dougbarton.us Thu Nov 13 23:32:18 2014 From: dougb at dougbarton.us (Doug Barton) Date: Thu, 13 Nov 2014 14:32:18 -0800 Subject: [dns-wg] {Use of} the INT TLD {by the NCC and others} [Re: RIPE NCC DNSSEC trust anchors] In-Reply-To: <31B785EB-6C4F-49C1-83A7-D99D866EFF12@icann.org> References: <5464C63E.2010104@ripe.net> <5464F303.5090704@dougbarton.us> , <20141113205024.GV26226@x28.adm.denic.de> <31B785EB-6C4F-49C1-83A7-D99D866EFF12@icann.org> Message-ID: <54653172.3010101@dougbarton.us> On 11/13/14 2:22 PM, Barbara Roseman wrote: > ICANN inherited a number of INT registrations when it assumed management of the zone. Since 2005, at least, and probably since 1998, only treaty-based organizations who meet the other criteria have been given registrations, to the best of my knowledge. I believe that ICANN uses an outside expert who has experience with UN treaty organizations to evaluate the requests for .INT registrations. FWIW, that policy definitely predates 2003, although I can't speak authoritatively as to how long it was in place before I joined the staff. Doug From kim.davies at icann.org Thu Nov 13 23:47:12 2014 From: kim.davies at icann.org (Kim Davies) Date: Thu, 13 Nov 2014 22:47:12 +0000 Subject: [dns-wg] {Use of} the INT TLD {by the NCC and others} [Re: RIPE NCC DNSSEC trust anchors] In-Reply-To: <54653172.3010101@dougbarton.us> References: <5464C63E.2010104@ripe.net> <5464F303.5090704@dougbarton.us> <,> <20141113205024.GV26226@x28.adm.denic.de> <31B785EB-6C4F-49C1-83A7-D99D866EFF12@icann.org> <54653172.3010101@dougbarton.us> Message-ID: > On Nov 13, 2014, at 2:32 PM, Doug Barton wrote: > > On 11/13/14 2:22 PM, Barbara Roseman wrote: >> ICANN inherited a number of INT registrations when it assumed management of the zone. Since 2005, at least, and probably since 1998, only treaty-based organizations who meet the other criteria have been given registrations, to the best of my knowledge. I believe that ICANN uses an outside expert who has experience with UN treaty organizations to evaluate the requests for .INT registrations. > > FWIW, that policy definitely predates 2003, although I can't speak authoritatively as to how long it was in place before I joined the staff. .INT was historically slated for dual purposes, intergovernmental treaty organisations and ?international databases?. I believe the point of departure was the formalisation of .ARPA for the latter purpose, as documented in RFC 3712 in 2001. IAB produced guidance that infrastructure domains no longer be housed in .INT, see https://web.archive.org/web/20021005001140/http://www.iab.org/iab/DOCUMENTS/iab-arpa-stmt.txt Since then new .INT registrations have been limited to intergovernmental treaty organisations, but existing registrations like this (and others, the tpc.int gateway from RFC 1529 comes to mind as another example, as does sol.int for interplanetary Internet) were grandfathered. kim From bmanning at isi.edu Fri Nov 14 00:14:49 2014 From: bmanning at isi.edu (manning bill) Date: Thu, 13 Nov 2014 15:14:49 -0800 Subject: [dns-wg] {Use of} the INT TLD {by the NCC and others} [Re: RIPE NCC DNSSEC trust anchors] In-Reply-To: <54653172.3010101@dougbarton.us> References: <5464C63E.2010104@ripe.net> <5464F303.5090704@dougbarton.us> , <20141113205024.GV26226@x28.adm.denic.de> <31B785EB-6C4F-49C1-83A7-D99D866EFF12@icann.org> <54653172.3010101@dougbarton.us> Message-ID: <8A8F0978-72E2-40C9-A1F0-1E438601020D@isi.edu> i could , since i managed .INT after pvm and before it was given to ICANN /bill PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 13November2014Thursday, at 14:32, Doug Barton wrote: > On 11/13/14 2:22 PM, Barbara Roseman wrote: >> ICANN inherited a number of INT registrations when it assumed management of the zone. Since 2005, at least, and probably since 1998, only treaty-based organizations who meet the other criteria have been given registrations, to the best of my knowledge. I believe that ICANN uses an outside expert who has experience with UN treaty organizations to evaluate the requests for .INT registrations. > > FWIW, that policy definitely predates 2003, although I can't speak authoritatively as to how long it was in place before I joined the staff. > > Doug > > From pk at DENIC.DE Fri Nov 14 10:46:57 2014 From: pk at DENIC.DE (Peter Koch) Date: Fri, 14 Nov 2014 10:46:57 +0100 Subject: [dns-wg] {Use of} the INT TLD {by the NCC and others} [Re: RIPE NCC DNSSEC trust anchors] In-Reply-To: References: <5464C63E.2010104@ripe.net> <5464F303.5090704@dougbarton.us> <20141113205024.GV26226@x28.adm.denic.de> Message-ID: <20141114094657.GB26226@x28.adm.denic.de> Hi David, On Thu, Nov 13, 2014 at 11:21:00AM -1000, David Conrad wrote: > Or, given the IANA Functions transition, the exact right point in time if people want to avoid a pointless political food fight. well, we hopefully agree that 'unasking' the questions isn't the right thing to do. Whether ripe.int is OK to continue to exist is a detail that only triggered the subsequent questions, that being the 'registration policy' for the INT TLD and the governing body for other decisions (like the deployment of DNSSEC, the DPS, choice of name server operators). We don't need responses instatntly (although you, Kim, and Barbara were helpful in providing those), but the questions need to be listed. > What's a "general protection of confidence"? That's my, apparently failed, attempt to translate a legalese clause from my mother tongue into English legalese with the help of this Internet. It should have described a general priciple that anyone is entitled to maintain their status, provided they got there bona fide and before rules existed. > > Also, the 'policy' document linked above does not provide > > for a revocation mechanism. > If an entity does not meet the documented policy criteria, then it should not be in the zone. However, IANA does not unilaterally remove zones. Traditionally, the entity simply says "please remove my entry". Are you recommending RIPE knowingly and intentionally violate a documented policy? Even if the NCC (or any other entity) did (or "do") not fulfill today's eligibility criteria, the current policy does not include a revocation clause (see above). Even if it did, the policy at the time of registration would prevail and unless that had had a clause submitting the registrant to future changes, there'd be no handle. So, my response to the question is "no", because there is no "documented policy" to "knowingly and intentionally violate". Whether the registrant gives up the domain name is a different issue. > As mentioned, management of .INT is part of the IANA Functions contract, specifically section C.2.9.4 of http://www.ntia.doc.gov/files/ntia/publications/sf_26_pg_1-2-final_award_and_sacs.pdf. Thanks. > Um, yeah. 1591 also says "Second level names in INT are registered by the PVM at ISI.EDU." Good luck with that. I personally find the cherry picking of RFC 1591 quite fascinating. The Internet has changed a bit since 1994 and it has never been clear to me that relying on that document in contravention to existing evolved policies makes a lot of sense. For obvious reasons I will refrain from a discussion re: the applicability of RFC 1591 in the general case. For the INT TLD I do not see any cherry picking in action. I had only quoted from the IANA's website. > Until the IANA Functions transition, NTIA. After the transition: that's an interesting question. Thanks, that was one important point to raise. Regards, Peter From dot at dotat.at Fri Nov 14 11:19:13 2014 From: dot at dotat.at (Tony Finch) Date: Fri, 14 Nov 2014 10:19:13 +0000 Subject: [dns-wg] RIPE NCC DNSSEC trust anchors In-Reply-To: <20141113173837.GP26226@x28.adm.denic.de> References: <5464C63E.2010104@ripe.net> <20141113173837.GP26226@x28.adm.denic.de> Message-ID: Peter Koch wrote: > > I'd rather not see the RIPE NCC further endorse the DLV technology and > service by continuing to submit key material there. DLV was meant as a > temporary deployment aid and might have been a good idea at its time. We would like to stop using the DLV but some of our reverse zones cannot be validated without it because JANET has only signed ac.uk. Tony. -- f.anthony.n.finch http://dotat.at/ Rockall, Malin: Cyclonic 7 to severe gale 9, becoming southeast 6 to gale 8. Rough or very rough. Rain at first, then thundery showers. Moderate or poor, becoming mainly good. From jim at rfc1035.com Fri Nov 14 11:59:50 2014 From: jim at rfc1035.com (Jim Reid) Date: Fri, 14 Nov 2014 10:59:50 +0000 Subject: [dns-wg] RIPE NCC DNSSEC trust anchors In-Reply-To: References: <5464C63E.2010104@ripe.net> <20141113173837.GP26226@x28.adm.denic.de> Message-ID: <93CD1EF6-210D-4A2A-B767-5F5508880B21@rfc1035.com> On 14 Nov 2014, at 10:19, Tony Finch wrote: > Peter Koch wrote: >> >> I'd rather not see the RIPE NCC further endorse the DLV technology and >> service by continuing to submit key material there. DLV was meant as a >> temporary deployment aid and might have been a good idea at its time. > > We would like to stop using the DLV but some of our reverse zones cannot > be validated without it because JANET has only signed ac.uk. Although you know I very much want to see DLV killed, that is not the matter at hand. What we are discussing is the NCC's use of DLV for stuff that either has no reason to be there or for domain names that have little or no relevance/use to the NCC and the community. I would like to keep the focus on that. In that context, Peter's comments go to the heart of the matter. There's a meta-issue too. Some years ago, long before the root was signed, the NCC shoved stuff into DLV as a short-term kludge. It's continuing to do that even though there seems to be no good reason for doing that any more. So have the NCC reviewed its processes for DLV population or assessed whether this activity is necessary or worthwhile? If you wish to continue discussing DLV's worth and relevance to the local problem you mentioned, go ahead. But please do so on another thread. From bmanning at isi.edu Fri Nov 14 18:14:52 2014 From: bmanning at isi.edu (manning bill) Date: Fri, 14 Nov 2014 09:14:52 -0800 Subject: [dns-wg] RIPE NCC DNSSEC trust anchors In-Reply-To: <93CD1EF6-210D-4A2A-B767-5F5508880B21@rfc1035.com> References: <5464C63E.2010104@ripe.net> <20141113173837.GP26226@x28.adm.denic.de> <93CD1EF6-210D-4A2A-B767-5F5508880B21@rfc1035.com> Message-ID: Paul Mockapetris (pvm) == Original maintainer of .INT, Bill Manning (wcm) == second maintainer of .INT, ICANN == Current Maintainer of .INT. DLV == DNS Lookaside Validation, a kludge to deal with islands of trust, published by Sam Weiler and productized by Internet Systems (nee Software) Consortia I think you have the NCC & RIPE & JANET acronyms ? Now can you tell me what a PSL is? /bill PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 14November2014Friday, at 2:59, Jim Reid wrote: > On 14 Nov 2014, at 10:19, Tony Finch wrote: > >> Peter Koch wrote: >>> >>> I'd rather not see the RIPE NCC further endorse the DLV technology and >>> service by continuing to submit key material there. DLV was meant as a >>> temporary deployment aid and might have been a good idea at its time. >> >> We would like to stop using the DLV but some of our reverse zones cannot >> be validated without it because JANET has only signed ac.uk. > > Although you know I very much want to see DLV killed, that is not the matter at hand. What we are discussing is the NCC's use of DLV for stuff that either has no reason to be there or for domain names that have little or no relevance/use to the NCC and the community. I would like to keep the focus on that. In that context, Peter's comments go to the heart of the matter. > > There's a meta-issue too. Some years ago, long before the root was signed, the NCC shoved stuff into DLV as a short-term kludge. It's continuing to do that even though there seems to be no good reason for doing that any more. So have the NCC reviewed its processes for DLV population or assessed whether this activity is necessary or worthwhile? > > If you wish to continue discussing DLV's worth and relevance to the local problem you mentioned, go ahead. But please do so on another thread. > > From romeo.zwart at ripe.net Mon Nov 17 16:49:42 2014 From: romeo.zwart at ripe.net (Romeo Zwart) Date: Mon, 17 Nov 2014 16:49:42 +0100 Subject: [dns-wg] RIPE NCC DNSSEC trust anchors In-Reply-To: <5465D491.6070606@ripe.net> References: <5465D491.6070606@ripe.net> Message-ID: <546A1916.6090909@ripe.net> Dear Collegues, Our message from last Thursday (see https://www.ripe.net/ripe/mail/archives/dns-wg/2014-November/002981.html) has stirred a significant amount of discussion. Trying to summarize the responses on the mailing list, I came to the below list of topics: /1 Why does any zone under 62.in-addr.arpa have to be in the DLV? Since 62/8 is under RIPE NCC control, it can be properly signed. /2 Why does RIPE NCC still submit key material to the DLV? RIPE NCC should no longer endorse out-of-band mechanisms for key publication. /3 Discussion around the current use of ripe.int. /4 Discussion around the current use of ripen.cc. I will try to answer each of these point separately. 1/ While the RIPE NCC controls 62/8, the delegations under it are not necessarily under our control. Specifically the /24 mentioned in the original post is part of 62.76/16, which is delegated to the Russian Institute for Public Networks (RIPN). RIPN does not sign its zones, therefore we have been using an out of band mechanism. 2/ The RIPE NCC has been publishing this key material out of band for historical reasons. If there is a consensus in the WG that this is no longer needed, or even undesirable, we are happy to phase out the use of the DLV. 3/ RIPE NCC has been assigned ripe.int in the early 2000's. We are currently not using ripe.int, other than by redirecting to ripe.net. If the community advises the RIPE NCC to request IANA to sign .int, we can spend some effort on this, but we'd like to follow up on this separately. 4/ Ripen.cc is a historical artifact. RIPE NCC is not currently using it and we are not planning any future use. Releasing the domain is an operational decision that we may take in the future. Kind regards, Romeo Zwart RIPE NCC From drc at virtualized.org Mon Nov 17 17:56:48 2014 From: drc at virtualized.org (David Conrad) Date: Mon, 17 Nov 2014 08:56:48 -0800 Subject: [dns-wg] RIPE NCC DNSSEC trust anchors In-Reply-To: <546A1916.6090909@ripe.net> References: <5465D491.6070606@ripe.net> <546A1916.6090909@ripe.net> Message-ID: <3AFEAD52-7A33-4B8E-9937-5ED1AFEE4DA0@virtualized.org> Romeo, On Nov 17, 2014, at 7:49 AM, Romeo Zwart wrote: > 2/ The RIPE NCC has been publishing this key material out of band for > historical reasons. If there is a consensus in the WG that this is no > longer needed, or even undesirable, we are happy to phase out the use of > the DLV. Yay! > 3/ RIPE NCC has been assigned ripe.int in the early 2000's. We are > currently not using ripe.int, other than by redirecting to ripe.net. If > the community advises the RIPE NCC to request IANA to sign .int, we can > spend some effort on this, but we'd like to follow up on this separately. Since .INT is currently not signed and RIPE is not using RIPE.INT, signing RIPE.INT would seem to be a bit ... silly (particularly in the light of #2). Since RIPE is not using RIPE.INT and that registration is out of (current) policy with respect to registrants in that domain, is there any reason why RIPE-NCC doesn't simply request RIPE.INT to be removed from the INT zone? Regards, -drc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From pawal at blipp.com Mon Nov 17 22:03:43 2014 From: pawal at blipp.com (Patrik Wallstrom) Date: Mon, 17 Nov 2014 22:03:43 +0100 Subject: [dns-wg] RIPE NCC DNSSEC trust anchors In-Reply-To: <3AFEAD52-7A33-4B8E-9937-5ED1AFEE4DA0@virtualized.org> References: <5465D491.6070606@ripe.net> <546A1916.6090909@ripe.net> <3AFEAD52-7A33-4B8E-9937-5ED1AFEE4DA0@virtualized.org> Message-ID: <20141117210343.GB27331@vic20.blipp.com> Hi all, On Mon, 17 Nov 2014, David Conrad wrote: > Romeo, > > On Nov 17, 2014, at 7:49 AM, Romeo Zwart wrote: > > 2/ The RIPE NCC has been publishing this key material out of band for > > historical reasons. If there is a consensus in the WG that this is no > > longer needed, or even undesirable, we are happy to phase out the use of > > the DLV. > > Yay! > > > 3/ RIPE NCC has been assigned ripe.int in the early 2000's. We are > > currently not using ripe.int, other than by redirecting to ripe.net. If > > the community advises the RIPE NCC to request IANA to sign .int, we can > > spend some effort on this, but we'd like to follow up on this separately. > > Since .INT is currently not signed and RIPE is not using RIPE.INT, > signing RIPE.INT would seem to be a bit ... silly (particularly in > the light of #2). > > Since RIPE is not using RIPE.INT and that registration is out of > (current) policy with respect to registrants in that domain, is > there any reason why RIPE-NCC doesn't simply request RIPE.INT to be > removed from the INT zone? Is there any available statistics on how many HTTP clients that reaches ripe.int and then fetches ripe.net instead? From romeo.zwart at ripe.net Tue Nov 18 09:22:02 2014 From: romeo.zwart at ripe.net (Romeo Zwart) Date: Tue, 18 Nov 2014 09:22:02 +0100 Subject: [dns-wg] RIPE NCC DNSSEC trust anchors In-Reply-To: <3AFEAD52-7A33-4B8E-9937-5ED1AFEE4DA0@virtualized.org> References: <5465D491.6070606@ripe.net> <546A1916.6090909@ripe.net> <3AFEAD52-7A33-4B8E-9937-5ED1AFEE4DA0@virtualized.org> Message-ID: <546B01AA.6020008@ripe.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi David, On 14/11/17 17:56 , David Conrad wrote: > Romeo, > > On Nov 17, 2014, at 7:49 AM, Romeo Zwart > wrote: >> 2/ The RIPE NCC has been publishing this key material out of band >> for historical reasons. If there is a consensus in the WG that >> this is no longer needed, or even undesirable, we are happy to >> phase out the use of the DLV. > > Yay! > >> 3/ RIPE NCC has been assigned ripe.int in the early 2000's. We >> are currently not using ripe.int, other than by redirecting to >> ripe.net. If the community advises the RIPE NCC to request IANA >> to sign .int, we can spend some effort on this, but we'd like to >> follow up on this separately. > > Since .INT is currently not signed and RIPE is not using RIPE.INT, > signing RIPE.INT would seem to be a bit ... silly (particularly in > the light of #2). There was an explicit suggestion on the list about using ripe.int as a 'lever' to get .int signed, hence my comment. > Since RIPE is not using RIPE.INT and that registration is out of > (current) policy with respect to registrants in that domain, is > there any reason why RIPE-NCC doesn't simply request RIPE.INT to be > removed from the INT zone? There will be a separate followup on this specific topic. Kind regards, Romeo > Regards, -drc > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlRrAaoACgkQGRL9suBV+erySgCeNcN71fH2JxJyflo+e+9o1Aj8 MHMAnRD5ieR/XPXe1NqHW2A2+/rpowYx =usf1 -----END PGP SIGNATURE----- From jim at rfc1035.com Tue Nov 18 10:54:24 2014 From: jim at rfc1035.com (Jim Reid) Date: Tue, 18 Nov 2014 09:54:24 +0000 Subject: [dns-wg] RIPE NCC DNSSEC trust anchors In-Reply-To: <546B01AA.6020008@ripe.net> References: <5465D491.6070606@ripe.net> <546A1916.6090909@ripe.net> <3AFEAD52-7A33-4B8E-9937-5ED1AFEE4DA0@virtualized.org> <546B01AA.6020008@ripe.net> Message-ID: On 18 Nov 2014, at 08:22, Romeo Zwart wrote: > There was an explicit suggestion on the list about using ripe.int as a > 'lever' to get .int signed, hence my comment. I think you are mistaken Romeo. Peter asked some meta issues on policy and procedural matters around the signing of .int: ie who is the governing body for the TLD and needs to be done to get them to sign it. He did not ask for the TLD to be signed. AFAICT nobody on the list has explicitly asked to get .int signed. Anyways, this is somewhat off-point. Although it would be good to know the answer to those questions, it belongs in another thread. Could we please return to the matter at hand: [1] What DNS/web/whatever traffic goes to ripen.cc? If it's low, can this be killed? When? [2] When was the utility of its DLV entry last assessed? What's the exit strategy for that? How often does its DLV name get validated and by whom/what? [3] What DNS/web/whatever traffic goes to ripe.int? If it's low, can this be killed? When? [4] When was the utility of its DLV entry last assessed? What's the exit strategy for that? How often does its DLV name get validated and by whom/what? [5] What's the NCC's overall exit strategy for DLV? FWIW I have still not seen any valid reason or meaningful daya explaining why the NCC still uses DLV. From jim at rfc1035.com Tue Nov 18 11:22:09 2014 From: jim at rfc1035.com (Jim Reid) Date: Tue, 18 Nov 2014 10:22:09 +0000 Subject: [dns-wg] RIPE NCC DNSSEC trust anchors In-Reply-To: <546A1916.6090909@ripe.net> References: <5465D491.6070606@ripe.net> <546A1916.6090909@ripe.net> Message-ID: <8711A77B-30F1-4124-80FE-23B744CCC42F@rfc1035.com> On 17 Nov 2014, at 15:49, Romeo Zwart wrote: > 1/ While the RIPE NCC controls 62/8, the delegations under it are not > necessarily under our control. Specifically the /24 mentioned in the > original post is part of 62.76/16, which is delegated to the Russian > Institute for Public Networks (RIPN). RIPN does not sign its zones, > therefore we have been using an out of band mechanism. Surely sticking this in DLV should be a decision for the holder of that /24 and not the NCC? Though it seems 62.76.151/24 supports an anycast instance of K. Hmmm... If that's the case, it opens even more questions. > 2/ The RIPE NCC has been publishing this key material out of band for > historical reasons. If there is a consensus in the WG that this is no > longer needed, or even undesirable, we are happy to phase out the use of > the DLV. Glad to hear that. Though the WG has still to decide about this. > 3/ RIPE NCC has been assigned ripe.int in the early 2000's. We are > currently not using ripe.int, other than by redirecting to ripe.net. If > the community advises the RIPE NCC to request IANA to sign .int, we can > spend some effort on this, but we'd like to follow up on this separately. I am not sure a request IANA to sign .int is worth doing any time soon. Signing .int will almost certainly be blocked by layer 9+ issues until long after the dust has settled on the NTIA-IANA transition. Besides, the few voices on this thread that have mentioned ripe.int appear to be asking for it to be removed, not for it to be signed in a signed TLD. I think the WG needs to reach consensus on what should be done here. > 4/ Ripen.cc is a historical artifact. RIPE NCC is not currently using it > and we are not planning any future use. Releasing the domain is an > operational decision that we may take in the future. Just kill it! IMO the domain should get removed from DLV as soon as it is prudent to do so: which probably means immediately. ripen.cc can die on its renewal date. Though these too should be consensus decisions for the WG. The NCC needs to have a procedure to review its DLV entries -- report to the WG once a year? -- and an exit strategy for the cruft^W names and keys it has there. It seems silly to be co-ordinating a key rollover for DLV material that probably isn't getting used for domain names that aren't getting used. From romeo.zwart at ripe.net Tue Nov 18 12:02:49 2014 From: romeo.zwart at ripe.net (Romeo Zwart) Date: Tue, 18 Nov 2014 12:02:49 +0100 Subject: [dns-wg] RIPE NCC DNSSEC trust anchors In-Reply-To: References: <5465D491.6070606@ripe.net> <546A1916.6090909@ripe.net> <3AFEAD52-7A33-4B8E-9937-5ED1AFEE4DA0@virtualized.org> <546B01AA.6020008@ripe.net> Message-ID: <546B2759.1000201@ripe.net> Hi Jim, On 14/11/18 10:54 , Jim Reid wrote: > On 18 Nov 2014, at 08:22, Romeo Zwart wrote: > >> There was an explicit suggestion on the list about using ripe.int as a >> 'lever' to get .int signed, hence my comment. > > I think you are mistaken Romeo. Peter asked some meta issues on policy and procedural matters around the signing of .int: ie who is the governing body for the TLD and needs to be done to get them to sign it. He did not ask for the TLD to be signed. AFAICT nobody on the list has explicitly asked to get .int signed. My wording was inaccurate. There indeed were questions on the list about procedure to have .int signed and that is what I intended to say. > Anyways, this is somewhat off-point. Although it would be good to know the answer to those questions, it belongs in another thread. We are in violent agreement here. > Could we please return to the matter at hand: I noticed that, meanwhile, you have read my other post. So, for the below questions, please see my previous post, where I tried to answer these points. As I tried to indicate, and you also pointed out yourself, there are some points here on which the WG should find consensus. We are happy to proceed when there is a clear working group direction. Kind regards, Romeo > [1] What DNS/web/whatever traffic goes to ripen.cc? If it's low, can this be killed? When? > > [2] When was the utility of its DLV entry last assessed? What's the exit strategy for that? How often does its DLV name get validated and by whom/what? > > [3] What DNS/web/whatever traffic goes to ripe.int? If it's low, can this be killed? When? > > [4] When was the utility of its DLV entry last assessed? What's the exit strategy for that? How often does its DLV name get validated and by whom/what? > > [5] What's the NCC's overall exit strategy for DLV? > > FWIW I have still not seen any valid reason or meaningful daya explaining why the NCC still uses DLV. > > > From niall.oreilly at ucd.ie Tue Nov 18 12:16:19 2014 From: niall.oreilly at ucd.ie (Niall O'Reilly) Date: Tue, 18 Nov 2014 11:16:19 +0000 Subject: [dns-wg] RIPE NCC DNSSEC trust anchors In-Reply-To: <8711A77B-30F1-4124-80FE-23B744CCC42F@rfc1035.com> References: <5465D491.6070606@ripe.net> <546A1916.6090909@ripe.net> <8711A77B-30F1-4124-80FE-23B744CCC42F@rfc1035.com> Message-ID: At Tue, 18 Nov 2014 10:22:09 +0000, Jim Reid wrote: > > On 17 Nov 2014, at 15:49, Romeo Zwart wrote: > > > 3/ RIPE NCC has been assigned ripe.int in the early 2000's. We are > > currently not using ripe.int, other than by redirecting to ripe.net. If > > the community advises the RIPE NCC to request IANA to sign .int, we can > > spend some effort on this, but we'd like to follow up on this separately. > > I am not sure a request IANA to sign .int is worth doing any time > soon. Signing .int will almost certainly be blocked by layer 9+ > issues until long after the dust has settled on the NTIA-IANA > transition. Besides, the few voices on this thread that have > mentioned ripe.int appear to be asking for it to be removed, not for > it to be signed in a signed TLD. I think the WG needs to reach > consensus on what should be done here. I'm reading that as a call from one of the co-chairs for (more) voices from the WG, so here's mine. Let's have RIPE.INT removed. > > 4/ Ripen.cc is a historical artifact. RIPE NCC is not currently using it > > and we are not planning any future use. Releasing the domain is an > > operational decision that we may take in the future. > > Just kill it! IMO the domain should get removed from DLV as soon as > it is prudent to do so: which probably means immediately. ripen.cc > can die on its renewal date. Though these too should be consensus > decisions for the WG. Let's have RIPEN.CC removed also. > The NCC needs to have a procedure to review its DLV entries -- > report to the WG once a year? Let's have this made part of the reporting routine. > -- and an exit strategy for the > cruft^W names and keys it has there. Let's have this too! ATB Niall From Woeber at CC.UniVie.ac.at Tue Nov 18 12:40:12 2014 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Tue, 18 Nov 2014 12:40:12 +0100 Subject: [dns-wg] RIPE NCC DNSSEC trust anchors In-Reply-To: References: <5465D491.6070606@ripe.net> <546A1916.6090909@ripe.net> <8711A77B-30F1-4124-80FE-23B744CCC42F@rfc1035.com> Message-ID: <546B301C.7000100@CC.UniVie.ac.at> Niall O'Reilly wrote: > At Tue, 18 Nov 2014 10:22:09 +0000, > Jim Reid wrote: > >>On 17 Nov 2014, at 15:49, Romeo Zwart wrote: >> >> >>>3/ RIPE NCC has been assigned ripe.int in the early 2000's. We are >>>currently not using ripe.int, other than by redirecting to ripe.net. If >>>the community advises the RIPE NCC to request IANA to sign .int, we can >>>spend some effort on this, but we'd like to follow up on this separately. >> >>I am not sure a request IANA to sign .int is worth doing any time >>soon. Signing .int will almost certainly be blocked by layer 9+ >>issues until long after the dust has settled on the NTIA-IANA >>transition. Besides, the few voices on this thread that have >>mentioned ripe.int appear to be asking for it to be removed, not for >>it to be signed in a signed TLD. I think the WG needs to reach >>consensus on what should be done here. > > > I'm reading that as a call from one of the co-chairs for (more) > voices from the WG, so here's mine. > > Let's have RIPE.INT removed. I do share this pov. The NCC is not a result of an international treaty and the RIPE Community is even less so :-) >>>4/ Ripen.cc is a historical artifact. RIPE NCC is not currently using it >>>and we are not planning any future use. Releasing the domain is an >>>operational decision that we may take in the future. >> >>Just kill it! IMO the domain should get removed from DLV as soon as >>it is prudent to do so: which probably means immediately. ripen.cc >>can die on its renewal date. Though these too should be consensus >>decisions for the WG. > > > Let's have RIPEN.CC removed also. Same here, and as soon as possible. Imho it is also an issue of corporate identity, but that's off topic here. >>The NCC needs to have a procedure to review its DLV entries -- >>report to the WG once a year? > > > Let's have this made part of the reporting routine. > > >>-- and an exit strategy for the >>cruft^W names and keys it has there. > > > Let's have this too! I don't have an opinion on this one, as I am mostly DNSsec illiterate :-/ Wilfried > ATB > Niall > > From Piotr.Strzyzewski at polsl.pl Tue Nov 18 12:49:03 2014 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Tue, 18 Nov 2014 12:49:03 +0100 Subject: [dns-wg] RIPE NCC DNSSEC trust anchors In-Reply-To: References: <5465D491.6070606@ripe.net> <546A1916.6090909@ripe.net> <8711A77B-30F1-4124-80FE-23B744CCC42F@rfc1035.com> Message-ID: <20141118114903.GC16270@hydra.ck.polsl.pl> On Tue, Nov 18, 2014 at 11:16:19AM +0000, Niall O'Reilly wrote: I use the simplest option. ;-) > > I am not sure a request IANA to sign .int is worth doing any time > > soon. Signing .int will almost certainly be blocked by layer 9+ > > issues until long after the dust has settled on the NTIA-IANA > > transition. Besides, the few voices on this thread that have > > mentioned ripe.int appear to be asking for it to be removed, not for > > it to be signed in a signed TLD. I think the WG needs to reach > > consensus on what should be done here. > > I'm reading that as a call from one of the co-chairs for (more) > voices from the WG, so here's mine. > > Let's have RIPE.INT removed. +1 > > > 4/ Ripen.cc is a historical artifact. RIPE NCC is not currently using it > > > and we are not planning any future use. Releasing the domain is an > > > operational decision that we may take in the future. > > > > Just kill it! IMO the domain should get removed from DLV as soon as > > it is prudent to do so: which probably means immediately. ripen.cc > > can die on its renewal date. Though these too should be consensus > > decisions for the WG. > > Let's have RIPEN.CC removed also. +1 Piotr -- gucio -> Piotr Strzy?ewski E-mail: Piotr.Strzyzewski at polsl.pl From gert at space.net Tue Nov 18 13:50:15 2014 From: gert at space.net (Gert Doering) Date: Tue, 18 Nov 2014 13:50:15 +0100 Subject: [dns-wg] RIPE NCC DNSSEC trust anchors In-Reply-To: References: <5465D491.6070606@ripe.net> <546A1916.6090909@ripe.net> <8711A77B-30F1-4124-80FE-23B744CCC42F@rfc1035.com> Message-ID: <20141118125015.GP28745@Space.Net> Hiya, On Tue, Nov 18, 2014 at 11:16:19AM +0000, Niall O'Reilly wrote: > Let's have RIPE.INT removed. +1 > Let's have RIPEN.CC removed also. +1 (I think I voiced my confusion about the existance of ripen.cc some years ago already, so my position is known :-) ) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From sander at steffann.nl Tue Nov 18 14:36:11 2014 From: sander at steffann.nl (Sander Steffann) Date: Tue, 18 Nov 2014 16:36:11 +0300 Subject: [dns-wg] RIPE NCC DNSSEC trust anchors In-Reply-To: <20141118114903.GC16270@hydra.ck.polsl.pl> References: <5465D491.6070606@ripe.net> <546A1916.6090909@ripe.net> <8711A77B-30F1-4124-80FE-23B744CCC42F@rfc1035.com> <20141118114903.GC16270@hydra.ck.polsl.pl> Message-ID: <9B134758-322D-4FDA-BCD7-AAF8FDD52B84@steffann.nl> >> Let's have RIPE.INT removed. > > +1 +1 >> Let's have RIPEN.CC removed also. > > +1 +? Cheers, Sander From nick at foobar.org Tue Nov 18 15:38:48 2014 From: nick at foobar.org (Nick Hilliard) Date: Tue, 18 Nov 2014 14:38:48 +0000 Subject: [dns-wg] RIPE NCC DNSSEC trust anchors In-Reply-To: References: <5465D491.6070606@ripe.net> <546A1916.6090909@ripe.net> <8711A77B-30F1-4124-80FE-23B744CCC42F@rfc1035.com> Message-ID: <546B59F8.5080008@foobar.org> On 18/11/2014 11:16, Niall O'Reilly wrote: > Let's have RIPE.INT removed. tbh, I see no reason to remove ripe.int. If ICANN has concerns about the delegation, then they should raise them formally with the RIPE NCC. If the "registration is out of (current) policy with respect to registrants in that domain", it's unclear why this is a RIPE NCC problem. The domain has been around since 2001 so if there's been a problem, why has it taken 13 years for people to get worked up about it? Please leave it alone. Nick From jorma at jmellin.net Tue Nov 18 15:50:19 2014 From: jorma at jmellin.net (Jorma Mellin) Date: Tue, 18 Nov 2014 16:50:19 +0200 Subject: [dns-wg] RIPE NCC DNSSEC trust anchors In-Reply-To: <546B59F8.5080008@foobar.org> References: <5465D491.6070606@ripe.net> <546A1916.6090909@ripe.net> <8711A77B-30F1-4124-80FE-23B744CCC42F@rfc1035.com> <546B59F8.5080008@foobar.org> Message-ID: <9B76C3AF-18FB-46B1-BF52-BA5374ACE949@jmellin.net> My 0.2c I remember the day when ripe.net -domain was unreachable because of failure to renew it. The hassle was pretty big, as it took a long time to convince the domain registry (at U.S) to understand that "yes, we really need this at european territory?. This was the primary reason to register .int as well. I have no clue have the situation changed about this but if not why to get rid of the backup? Jorma On 18 Nov 2014, at 16:38, Nick Hilliard wrote: > On 18/11/2014 11:16, Niall O'Reilly wrote: >> Let's have RIPE.INT removed. > > tbh, I see no reason to remove ripe.int. > > If ICANN has concerns about the delegation, then they should raise them > formally with the RIPE NCC. > > If the "registration is out of (current) policy with respect to registrants > in that domain", it's unclear why this is a RIPE NCC problem. The domain > has been around since 2001 so if there's been a problem, why has it taken > 13 years for people to get worked up about it? > > Please leave it alone. > > Nick > > From rhe at nosc.ja.net Tue Nov 18 15:59:23 2014 From: rhe at nosc.ja.net (Rob Evans) Date: Tue, 18 Nov 2014 14:59:23 +0000 Subject: [dns-wg] RIPE NCC DNSSEC trust anchors In-Reply-To: <9B134758-322D-4FDA-BCD7-AAF8FDD52B84@steffann.nl> References: <5465D491.6070606@ripe.net> <546A1916.6090909@ripe.net> <8711A77B-30F1-4124-80FE-23B744CCC42F@rfc1035.com> <20141118114903.GC16270@hydra.ck.polsl.pl> <9B134758-322D-4FDA-BCD7-AAF8FDD52B84@steffann.nl> Message-ID: <43C08580-C6A8-4881-B88B-DE8F88889521@nosc.ja.net> Hi, >>> Let's have RIPEN.CC removed also. >> >> +1 > > +? Isn't this really, as Romeo puts it, "an operational decision" for the RIPE NCC? If they want to sit on a domain that bears a resemblance to the company identity, I'll leave that up to them... Cheers, Rob From jim at rfc1035.com Tue Nov 18 16:22:00 2014 From: jim at rfc1035.com (Jim Reid) Date: Tue, 18 Nov 2014 15:22:00 +0000 Subject: [dns-wg] RIPE NCC DNSSEC trust anchors In-Reply-To: <43C08580-C6A8-4881-B88B-DE8F88889521@nosc.ja.net> References: <5465D491.6070606@ripe.net> <546A1916.6090909@ripe.net> <8711A77B-30F1-4124-80FE-23B744CCC42F@rfc1035.com> <20141118114903.GC16270@hydra.ck.polsl.pl> <9B134758-322D-4FDA-BCD7-AAF8FDD52B84@steffann.nl> <43C08580-C6A8-4881-B88B-DE8F88889521@nosc.ja.net> Message-ID: On 18 Nov 2014, at 14:59, Rob Evans wrote: > Isn't this really, as Romeo puts it, "an operational decision" for the RIPE NCC? Er no. It's a decision for the community which domain names it needs or wants to use to identify itself. After all the NCC should respond to the needs of the RIPE community and the NCC membership. It's an operational matter for the NCC how to register those domain names, which registrar(s) to use, provision the names, choose the name servers, etc, etc. YMMV. Nobody here knew about ripe.int until recently and it doesn't seem to be used. Since it does not appear to have community support -- for some definition of both community and support -- the case for retaining the domain is poor at best. From pk at DENIC.DE Tue Nov 18 16:26:25 2014 From: pk at DENIC.DE (Peter Koch) Date: Tue, 18 Nov 2014 16:26:25 +0100 Subject: [dns-wg] RIPE NCC DNSSEC trust anchors In-Reply-To: References: <5465D491.6070606@ripe.net> <546A1916.6090909@ripe.net> <8711A77B-30F1-4124-80FE-23B744CCC42F@rfc1035.com> Message-ID: <20141118152625.GU26226@x28.adm.denic.de> On Tue, Nov 18, 2014 at 11:16:19AM +0000, Niall O'Reilly wrote: > I'm reading that as a call from one of the co-chairs for (more) > voices from the WG, so here's mine. > > Let's have RIPE.INT removed. this isn't f*cebook. As a co-chair of this wg I doubt it is reasonable for the WG to micro manage the NCC in what domain names and which TLD(s) it uses. It is also not clear to me why the DNS WG would be formally competent w.r.t. the subject matter. > > > 4/ Ripen.cc is a historical artifact. RIPE NCC is not currently using it > > > and we are not planning any future use. Releasing the domain is an > > > operational decision that we may take in the future. > > > > Just kill it! IMO the domain should get removed from DLV as soon as > > it is prudent to do so: which probably means immediately. ripen.cc > > can die on its renewal date. Though these too should be consensus > > decisions for the WG. > > Let's have RIPEN.CC removed also. Again, I doubt that a voting is helpful here. No matter what, even if the NCC gave up on the use of "ripen.cc", releasing the domain name is probably a bad idea. Also, simply removing those domains without a signed parent doesn't ultimately help solving the DLV issue. Why can't a zone be signed (for reasons of symmetry or streamlined processes) without the TA being published? -Peter From jim at rfc1035.com Tue Nov 18 16:27:50 2014 From: jim at rfc1035.com (Jim Reid) Date: Tue, 18 Nov 2014 15:27:50 +0000 Subject: [dns-wg] RIPE NCC DNSSEC trust anchors In-Reply-To: <9B76C3AF-18FB-46B1-BF52-BA5374ACE949@jmellin.net> References: <5465D491.6070606@ripe.net> <546A1916.6090909@ripe.net> <8711A77B-30F1-4124-80FE-23B744CCC42F@rfc1035.com> <546B59F8.5080008@foobar.org> <9B76C3AF-18FB-46B1-BF52-BA5374ACE949@jmellin.net> Message-ID: <33444C59-33A6-4EBD-B15B-44E93C94D4D0@rfc1035.com> On 18 Nov 2014, at 14:50, Jorma Mellin wrote: > I remember the day when ripe.net -domain was unreachable because of > failure to renew it. The hassle was pretty big, as it took a long time to convince the domain registry (at U.S) to understand that "yes, we really need this at european territory?. This must have happened a *long* time ago and I am sure the NCC now has robust procedures in place to ensure domain names get renewed in good time. Though it might be worth asking about that. > This was the primary reason to register .int as well. The origins of ripe.int are unclear and it would be good to know why it was done. > I have no clue have the situation changed about this but if not why to get rid > of the backup? It's not a backup: gromit% dig ripe.int mx ... ;; ANSWER SECTION: ripe.int. 21600 IN MX 250 kaka.ripe.net. ripe.int. 21600 IN MX 200 koko.ripe.net. gromit% dig www.ripe.int ... ;; ANSWER SECTION: www.ripe.int. 21600 IN CNAME www.ripe.net. FWIW I have never seen a URL or email address containing has ripe.int. From jim at rfc1035.com Tue Nov 18 16:34:52 2014 From: jim at rfc1035.com (Jim Reid) Date: Tue, 18 Nov 2014 15:34:52 +0000 Subject: [dns-wg] RIPE NCC DNSSEC trust anchors In-Reply-To: <43C08580-C6A8-4881-B88B-DE8F88889521@nosc.ja.net> References: <5465D491.6070606@ripe.net> <546A1916.6090909@ripe.net> <8711A77B-30F1-4124-80FE-23B744CCC42F@rfc1035.com> <20141118114903.GC16270@hydra.ck.polsl.pl> <9B134758-322D-4FDA-BCD7-AAF8FDD52B84@steffann.nl> <43C08580-C6A8-4881-B88B-DE8F88889521@nosc.ja.net> Message-ID: <4BEDB92D-FD27-41CA-B342-C4752FC7020C@rfc1035.com> On 18 Nov 2014, at 14:59, Rob Evans wrote: > If they want to sit on a domain that bears a resemblance to the company identity, I'll leave that up to them... That way lies madness: ripe.$TLD-of-the-week. IMO one domain name is enough. If someone can make a convincing case to use more than that or why ripe.whatever can achieve something not possible with ripe.net, please speak up. From rhe at nosc.ja.net Tue Nov 18 16:51:52 2014 From: rhe at nosc.ja.net (Rob Evans) Date: Tue, 18 Nov 2014 15:51:52 +0000 Subject: [dns-wg] RIPE NCC DNSSEC trust anchors In-Reply-To: <4BEDB92D-FD27-41CA-B342-C4752FC7020C@rfc1035.com> References: <5465D491.6070606@ripe.net> <546A1916.6090909@ripe.net> <8711A77B-30F1-4124-80FE-23B744CCC42F@rfc1035.com> <20141118114903.GC16270@hydra.ck.polsl.pl> <9B134758-322D-4FDA-BCD7-AAF8FDD52B84@steffann.nl> <43C08580-C6A8-4881-B88B-DE8F88889521@nosc.ja.net> <4BEDB92D-FD27-41CA-B342-C4752FC7020C@rfc1035.com> Message-ID: <06ACB8B8-1BD8-48A2-97BA-9AA73F7CED18@nosc.ja.net> Hi Jim, >> If they want to sit on a domain that bears a resemblance to the company identity, I'll leave that up to them... > > That way lies madness: ripe.$TLD-of-the-week. I don't disagree, but my thoughts are along the lines of what Peter said. I certainly don't want the RIPE community to be associated with the ripen.cc domain, but if the RIPE NCC wants to use it (or at least reserve it), we might think it's a mistake, but it's the company's mistake to make unless we get into a level of micro-management that I think we, as a community, delegate to the Board. As you say, YMMV, E&OE, prices of domains can go down as well as up. Cheers, Rob From ripe-wgs.cs at schiefner.de Tue Nov 18 17:17:03 2014 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Tue, 18 Nov 2014 17:17:03 +0100 Subject: [dns-wg] RIPE NCC DNSSEC trust anchors In-Reply-To: <4BEDB92D-FD27-41CA-B342-C4752FC7020C@rfc1035.com> References: <5465D491.6070606@ripe.net> <546A1916.6090909@ripe.net> <8711A77B-30F1-4124-80FE-23B744CCC42F@rfc1035.com> <20141118114903.GC16270@hydra.ck.polsl.pl> <9B134758-322D-4FDA-BCD7-AAF8FDD52B84@steffann.nl> <43C08580-C6A8-4881-B88B-DE8F88889521@nosc.ja.net> <4BEDB92D-FD27-41CA-B342-C4752FC7020C@rfc1035.com> Message-ID: <546B70FF.9090104@schiefner.de> Hi Jim, On 18.11.2014 16:34, Jim Reid wrote: >On 18 Nov 2014, at 14:59, Rob Evans wrote: >> If they want to sit on a domain that bears a resemblance to the >> company identity, I'll leave that up to them... > > That way lies madness: ripe.$TLD-of-the-week. > > IMO one domain name is enough. If someone can make a convincing case > to use more than that or why ripe.whatever can achieve something not > possible with ripe.net, please speak up. I know at least one TLD that serves a completely orthogonal purpose to any "regular" TLD - and I am sure you know this one too. :-) I'd be almost immediately convinced if the NCC decided to register under this particular TLD - for the services that come with it. Cheers, -C. From jim at rfc1035.com Tue Nov 18 17:27:44 2014 From: jim at rfc1035.com (Jim Reid) Date: Tue, 18 Nov 2014 16:27:44 +0000 Subject: [dns-wg] RIPE NCC DNSSEC trust anchors In-Reply-To: <06ACB8B8-1BD8-48A2-97BA-9AA73F7CED18@nosc.ja.net> References: <5465D491.6070606@ripe.net> <546A1916.6090909@ripe.net> <8711A77B-30F1-4124-80FE-23B744CCC42F@rfc1035.com> <20141118114903.GC16270@hydra.ck.polsl.pl> <9B134758-322D-4FDA-BCD7-AAF8FDD52B84@steffann.nl> <43C08580-C6A8-4881-B88B-DE8F88889521@nosc.ja.net> <4BEDB92D-FD27-41CA-B342-C4752FC7020C@rfc1035.com> <06ACB8B8-1BD8-48A2-97BA-9AA73F7CED18@nosc.ja.net> Message-ID: On 18 Nov 2014, at 15:51, Rob Evans wrote: > I certainly don't want the RIPE community to be associated with theripen.cc domain, but if the RIPE NCC wants to use it (or at least reserve it), we might think it's a mistake, but it's the company's mistake to make unless we get into a level of micro-management that I think we, as a community, delegate to the Board. I'm sort of in agreement with that Rob. Experiments and trying new stuff with other name spaces are fine, provided there's a clear understanding of what's going on and why. There also needs to be a clear exit or migration strategy. Cruft can't be allowed to just stagnate indefinitely or accumulate even more cruft along the way. There should be clear milestones around future go/no go decisions. There should be some reporting about all of the above, either to the DNS or NCC Services WG - whatever of the two is most appropriate. None of that has been done for ripe.int, ripen.cc and their injection into DLV. Well OK, nothing apart from the accummulation of cruft. My key question the has yet to be answered remains "why is the NCC putting keying material into ripe.int into DLV when the domain does not appear to be used and the case for continued DLV registration is vague to non-existent?". I would like some hard data about that. That said, I think it is reasonable for the community to decide "ripe.foo is no longer used or needed. Please let it die.". From nick at foobar.org Tue Nov 18 17:38:36 2014 From: nick at foobar.org (Nick Hilliard) Date: Tue, 18 Nov 2014 16:38:36 +0000 Subject: [dns-wg] RIPE NCC DNSSEC trust anchors In-Reply-To: References: <5465D491.6070606@ripe.net> <546A1916.6090909@ripe.net> <8711A77B-30F1-4124-80FE-23B744CCC42F@rfc1035.com> <20141118114903.GC16270@hydra.ck.polsl.pl> <9B134758-322D-4FDA-BCD7-AAF8FDD52B84@steffann.nl> <43C08580-C6A8-4881-B88B-DE8F88889521@nosc.ja.net> <4BEDB92D-FD27-41CA-B342-C4752FC7020C@rfc1035.com> <06ACB8B8-1BD8-48A2-97BA-9AA73F7CED18@nosc.ja.net> Message-ID: <546B760C.8080505@foobar.org> On 18/11/2014 16:27, Jim Reid wrote: > That said, I think it is reasonable for the community to decide > "ripe.foo is no longer used or needed. Please let it die.". just as reasonable as if the ripe ncc management team (or board) were to decide that as this is purely an operational matter, that the decision would be theirs entirely. It's not helpful for the ripe community to micromanage the ncc. The entire thread about whether or not to delete ripe.int falls firmly into the category of micromanagement. Please can we let them get on with their jobs without interfering? Nick From Woeber at CC.UniVie.ac.at Tue Nov 18 18:21:05 2014 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Tue, 18 Nov 2014 18:21:05 +0100 Subject: [dns-wg] RIPE NCC DNSSEC trust anchors In-Reply-To: <546B59F8.5080008@foobar.org> References: <5465D491.6070606@ripe.net> <546A1916.6090909@ripe.net> <8711A77B-30F1-4124-80FE-23B744CCC42F@rfc1035.com> <546B59F8.5080008@foobar.org> Message-ID: <546B8001.7030207@CC.UniVie.ac.at> Nick Hilliard wrote: > On 18/11/2014 11:16, Niall O'Reilly wrote: > >> Let's have RIPE.INT removed. > > > tbh, I see no reason to remove ripe.int. [...] > Please leave it alone. In order to achieve or conserve - what? > Nick Wilfried From Piotr.Strzyzewski at polsl.pl Tue Nov 18 18:24:00 2014 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Tue, 18 Nov 2014 18:24:00 +0100 Subject: [dns-wg] RIPE NCC DNSSEC trust anchors In-Reply-To: <546B70FF.9090104@schiefner.de> References: <5465D491.6070606@ripe.net> <546A1916.6090909@ripe.net> <8711A77B-30F1-4124-80FE-23B744CCC42F@rfc1035.com> <20141118114903.GC16270@hydra.ck.polsl.pl> <9B134758-322D-4FDA-BCD7-AAF8FDD52B84@steffann.nl> <43C08580-C6A8-4881-B88B-DE8F88889521@nosc.ja.net> <4BEDB92D-FD27-41CA-B342-C4752FC7020C@rfc1035.com> <546B70FF.9090104@schiefner.de> Message-ID: <20141118172400.GA28735@hydra.ck.polsl.pl> On Tue, Nov 18, 2014 at 05:17:03PM +0100, Carsten Schiefner wrote: > On 18.11.2014 16:34, Jim Reid wrote: > >On 18 Nov 2014, at 14:59, Rob Evans wrote: > >> If they want to sit on a domain that bears a resemblance to the > >> company identity, I'll leave that up to them... > > > > That way lies madness: ripe.$TLD-of-the-week. > > > > IMO one domain name is enough. If someone can make a convincing case > > to use more than that or why ripe.whatever can achieve something not > > possible with ripe.net, please speak up. > > I know at least one TLD that serves a completely orthogonal purpose to > any "regular" TLD - and I am sure you know this one too. :-) > > I'd be almost immediately convinced if the NCC decided to register under > this particular TLD - for the services that come with it. I have always believed that this was a kind of an experiment with short links which was introduced during and then abandoned after the RIPE61 at ROME: http://www.ripe.net/ripe/mail/archives/ncc-announce/2010-October/000406.html https://twitter.com/RIPE_NCC/status/28388254627 Piotr -- gucio -> Piotr Strzy?ewski E-mail: Piotr.Strzyzewski at polsl.pl From Piotr.Strzyzewski at polsl.pl Tue Nov 18 18:37:08 2014 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Tue, 18 Nov 2014 18:37:08 +0100 Subject: [dns-wg] RIPE NCC DNSSEC trust anchors In-Reply-To: References: <5465D491.6070606@ripe.net> <546A1916.6090909@ripe.net> <8711A77B-30F1-4124-80FE-23B744CCC42F@rfc1035.com> <20141118114903.GC16270@hydra.ck.polsl.pl> <9B134758-322D-4FDA-BCD7-AAF8FDD52B84@steffann.nl> <43C08580-C6A8-4881-B88B-DE8F88889521@nosc.ja.net> Message-ID: <20141118173708.GB28735@hydra.ck.polsl.pl> On Tue, Nov 18, 2014 at 03:22:00PM +0000, Jim Reid wrote: Jim > Nobody here knew about ripe.int until recently and it doesn't seem to > be used. Years ago I gave a lecture about DNS system. Part of it, was showing some examples of domains from non-ccTLDs. ripe.int was the only one example I have had in my mind at this time. ;-) Piotr -- gucio -> Piotr Strzy?ewski E-mail: Piotr.Strzyzewski at polsl.pl From dougb at dougbarton.us Tue Nov 18 18:40:30 2014 From: dougb at dougbarton.us (Doug Barton) Date: Tue, 18 Nov 2014 09:40:30 -0800 Subject: [dns-wg] RIPE NCC DNSSEC trust anchors In-Reply-To: <546B59F8.5080008@foobar.org> References: <5465D491.6070606@ripe.net> <546A1916.6090909@ripe.net> <8711A77B-30F1-4124-80FE-23B744CCC42F@rfc1035.com> <546B59F8.5080008@foobar.org> Message-ID: <546B848E.30406@dougbarton.us> On 11/18/14 6:38 AM, Nick Hilliard wrote: > On 18/11/2014 11:16, Niall O'Reilly wrote: >> Let's have RIPE.INT removed. > > tbh, I see no reason to remove ripe.int. You don't find the fact that it's been out of scope for INT for over a decade to be compelling? We removed ip6.int for similar reasons, and that actually had a purpose at one point in the past. > If ICANN has concerns about the delegation, then they should raise them > formally with the RIPE NCC. It's been raised informally a non-zero number of times in the past. Why do you think that creating a kerfuffle over something simple is the right way to go? There seems to be a fairly large consensus that the domain should be removed, and Jim has asked some intelligent operational questions about its use that IMO should be answered. Doug From bmanning at isi.edu Tue Nov 18 18:42:31 2014 From: bmanning at isi.edu (manning bill) Date: Tue, 18 Nov 2014 09:42:31 -0800 Subject: [dns-wg] RIPE NCC DNSSEC trust anchors In-Reply-To: <20141118173708.GB28735@hydra.ck.polsl.pl> References: <5465D491.6070606@ripe.net> <546A1916.6090909@ripe.net> <8711A77B-30F1-4124-80FE-23B744CCC42F@rfc1035.com> <20141118114903.GC16270@hydra.ck.polsl.pl> <9B134758-322D-4FDA-BCD7-AAF8FDD52B84@steffann.nl> <43C08580-C6A8-4881-B88B-DE8F88889521@nosc.ja.net> <20141118173708.GB28735@hydra.ck.polsl.pl> Message-ID: <5A4DEB77-09A5-49C7-A46A-E34406C341EA@isi.edu> well some people knew about it. however when int was repurposed and went to ICANN, the rir delegations should have all been removed since the reason for existence was moot. that it has remained this long suggests a lack of care /bill PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 18November2014Tuesday, at 9:37, Piotr Strzyzewski wrote: > On Tue, Nov 18, 2014 at 03:22:00PM +0000, Jim Reid wrote: > > Jim > >> Nobody here knew about ripe.int until recently and it doesn't seem to >> be used. > > Years ago I gave a lecture about DNS system. Part of it, was showing > some examples of domains from non-ccTLDs. ripe.int was the only one > example I have had in my mind at this time. ;-) > > Piotr > > -- > gucio -> Piotr Strzy?ewski > E-mail: Piotr.Strzyzewski at polsl.pl > From jaap at NLnetLabs.nl Tue Nov 18 18:44:41 2014 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Tue, 18 Nov 2014 18:44:41 +0100 Subject: [dns-wg] RIPE NCC DNSSEC trust anchors In-Reply-To: <546B8001.7030207@CC.UniVie.ac.at> References: <5465D491.6070606@ripe.net> <546A1916.6090909@ripe.net> <8711A77B-30F1-4124-80FE-23B744CCC42F@rfc1035.com> <546B59F8.5080008@foobar.org> <546B8001.7030207@CC.UniVie.ac.at> Message-ID: <201411181744.sAIHiftE025095@bela.nlnetlabs.nl> Wilfried Woeber writes: > Nick Hilliard wrote: > > > On 18/11/2014 11:16, Niall O'Reilly wrote: > >> Let's have RIPE.INT > removed. > > > tbh, I see no reason to remove ripe.int. [...] > > Please leave it alone. > > In order to achieve or conserve - what? > Energy. jaap PS. The last time I looked, all contracts with (g)TLD registries has various names reserved, among them, RIPE. So, default RIPE.$TLD is reserved. I guess that is to stop delegations like ripe.org. From drc at virtualized.org Tue Nov 18 16:41:17 2014 From: drc at virtualized.org (David Conrad) Date: Tue, 18 Nov 2014 07:41:17 -0800 Subject: [dns-wg] ripe.int (was Re: RIPE NCC DNSSEC trust anchors) In-Reply-To: <546B59F8.5080008@foobar.org> References: <5465D491.6070606@ripe.net> <546A1916.6090909@ripe.net> <8711A77B-30F1-4124-80FE-23B744CCC42F@rfc1035.com> <546B59F8.5080008@foobar.org> Message-ID: <4F362493-24F8-4DD6-BCE2-FCAB155A2DBE@virtualized.org> Nick, On Nov 18, 2014, at 6:38 AM, Nick Hilliard wrote: > On 18/11/2014 11:16, Niall O'Reilly wrote: >> Let's have RIPE.INT removed. > tbh, I see no reason to remove ripe.int. I see no reason to keep it. > If ICANN has concerns about the delegation, then they should raise them > formally with the RIPE NCC. AFAIK, ICANN doesn't care. > If the "registration is out of (current) policy with respect to registrants > in that domain", it's unclear why this is a RIPE NCC problem. Because the current registry (which I'm guessing will probably change with the transition of the stewardship of the IANA functions contract) won't do anything to it unless the current registrant asks. > The domain > has been around since 2001 so if there's been a problem, why has it taken > 13 years for people to get worked up about it? No one is worked up and there isn't a problem per se, it is just pointless cruft left over from an earlier Internet. With the transition of the stewardship of the IANA functions contract, people are trying to figure out what to do with the .int registry. Given ICANN isn't supposed to be running a registry, it is likely the "owner" of the .int registry will change. Since RIPE does not really use the domain and is not a treaty organization, awkward political questions may be raised. Unless one enjoys pointless political discussions, I'm unclear what value there is in keeping the domain. > Please leave it alone. What purpose does it serve? Regards, -drc (ICANN CTO, but speaking for myself only. Really.) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From Woeber at CC.UniVie.ac.at Tue Nov 18 19:50:41 2014 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Tue, 18 Nov 2014 19:50:41 +0100 Subject: [dns-wg] RIPE NCC DNSSEC trust anchors In-Reply-To: <201411181744.sAIHiftE025095@bela.nlnetlabs.nl> References: <5465D491.6070606@ripe.net> <546A1916.6090909@ripe.net> <8711A77B-30F1-4124-80FE-23B744CCC42F@rfc1035.com> <546B59F8.5080008@foobar.org> <546B8001.7030207@CC.UniVie.ac.at> <201411181744.sAIHiftE025095@bela.nlnetlabs.nl> Message-ID: <546B9501.3000001@CC.UniVie.ac.at> Thanks, Jaap! Jaap Akkerhuis wrote: [...] > PS. The last time I looked, all contracts with (g)TLD registries > has various names reserved, among them, RIPE. So, default RIPE.$TLD > is reserved. I guess that is to stop delegations like ripe.org. Fair enough. So we'll pay for some 1000 or more RIPE.$new-gTLD reservations pretty soon now? Reality check, folks. -WW From jaap at NLnetLabs.nl Tue Nov 18 21:34:05 2014 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Tue, 18 Nov 2014 21:34:05 +0100 Subject: [dns-wg] RIPE NCC DNSSEC trust anchors In-Reply-To: <546B9501.3000001@CC.UniVie.ac.at> References: <5465D491.6070606@ripe.net> <546A1916.6090909@ripe.net> <8711A77B-30F1-4124-80FE-23B744CCC42F@rfc1035.com> <546B59F8.5080008@foobar.org> <546B8001.7030207@CC.UniVie.ac.at> <201411181744.sAIHiftE025095@bela.nlnetlabs.nl> <546B9501.3000001@CC.UniVie.ac.at> Message-ID: <201411182034.sAIKY5S1088041@bela.nlnetlabs.nl> Wilfried Woeber writes: > Thanks, Jaap! > > Jaap Akkerhuis wrote: > > [...] > > PS. The last time I looked, all contracts with (g)TLD registries > > has various names reserved, among them, RIPE. So, default RIPE.$TLD > > is reserved. I guess that is to stop delegations like ripe.org. > > Fair enough. > So we'll pay for some 1000 or more RIPE.$new-gTLD reservations pretty soon now? Nope. I think the idea to have this "verboten to delegate list" is that obe doesn't has to do defensive registratins. So the ICANN contracts protects RIPE for "abuse of ripe's domain label". jaap From lutz at iks-jena.de Tue Nov 18 22:38:02 2014 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Tue, 18 Nov 2014 21:38:02 +0000 (UTC) Subject: [dns-wg] RIPE NCC DNSSEC trust anchors References: <546B59F8.5080008@foobar.org> Message-ID: * Nick Hilliard wrote: > On 18/11/2014 11:16, Niall O'Reilly wrote: >> Let's have RIPE.INT removed. > > tbh, I see no reason to remove ripe.int. > > If ICANN has concerns about the delegation, then they should raise them > formally with the RIPE NCC. I second that. And for the DLV issue, I'd like to see any zone, which can't be validated straight from the root (following the DS chain), ahandles in the following way: 1) put the validation info in a DLV (i.e. ISC). 2) push as hard as possible to get the missing zones signed. 3) remove the DLV as soon as the DS chain is complete. And forget about ripen.cc. If you think, this is a geeky idea, apply for the community TLDs .NCC as well as .RIPE. From dougb at dougbarton.us Tue Nov 18 22:40:40 2014 From: dougb at dougbarton.us (Doug Barton) Date: Tue, 18 Nov 2014 13:40:40 -0800 Subject: [dns-wg] RIPE NCC DNSSEC trust anchors In-Reply-To: References: <546B59F8.5080008@foobar.org> Message-ID: <546BBCD8.4010004@dougbarton.us> On 11/18/14 1:38 PM, Lutz Donnerhacke wrote: > * Nick Hilliard wrote: >> >On 18/11/2014 11:16, Niall O'Reilly wrote: >>> >> Let's have RIPE.INT removed. >> > >> >tbh, I see no reason to remove ripe.int. >> > >> >If ICANN has concerns about the delegation, then they should raise them >> >formally with the RIPE NCC. > I second that. Why? What value does a formal request from ICANN have over the RIPE community simply doing the right thing with an old domain that no longer has relevance? Doug From drc at virtualized.org Tue Nov 18 23:16:39 2014 From: drc at virtualized.org (David Conrad) Date: Tue, 18 Nov 2014 14:16:39 -0800 Subject: [dns-wg] RIPE NCC DNSSEC trust anchors In-Reply-To: References: <546B59F8.5080008@foobar.org> Message-ID: Lutz, On Nov 18, 2014, at 1:38 PM, Lutz Donnerhacke wrote: >> If ICANN has concerns about the delegation, then they should raise them formally with the RIPE NCC. > I second that. As mentioned previously, AFAIK, ICANN doesn't have any concerns with ripe.int -- I doubt anyone who isn't on this mailing list from ICANN is even aware it exists. The question is about what happens in the future since .INT registry services is officially (rightly or wrongly) a service provided via the IANA Functions contract, it is likely ICANN won't be providing .INT registry services in the future (since ICANN's section II.2 of own bylaws state: "ICANN shall not act as a Domain Name System Registry [...]" so I'll be surprised if .INT is continued after the stewardship of the IANA functions contract is transitioned), and RIPE is not a treaty organization. This isn't a question for ICANN: it's a question for RIPE (or, if you prefer, RIPE-NCC) and whoever will be running .INT after the transition. I'm just suggesting that if RIPE (or, if you prefer, RIPE-NCC) see no significant value in RIPE.INT, to simply ask it be dropped prior to (I'm perhaps overly cynically guessing here) political silliness associated with the .INT zone. Regards, -drc (ICANN CTO, but speaking only for myself. Really.) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jim at rfc1035.com Tue Nov 25 13:09:25 2014 From: jim at rfc1035.com (Jim Reid) Date: Tue, 25 Nov 2014 12:09:25 +0000 Subject: [dns-wg] reminder about the WG Chair appointment process Message-ID: <0FF3EBE1-D991-4669-9086-3248FD0728FF@rfc1035.com> Colleagues, there's been very little response or discussion about the procedure which was proposed at the beginning of October. I think it's now time to start a "Last Call" on this. If anyone has any tweaks to he proposed text or counter proposals, please speak up now! It would be helpful if any changes are accompanied by suggested replacement text and an explanation. Simply saying "I don't like Clause Foo" is not helpful or productive: please say why you don't like that clause and provide replacement text. Since the PDP uses 4 weeks for its Last Call phase, let's do the same here. So if there are no changes or comments on the suggested text by the end of the year, it will be considered to be the agreed, final version of the procedure. [Well, until we revisit this in the future...] Assuming there is agreement on the final text by the end of the year, I will ask the WG for statements of support for that final text so that we can hopefully declare consensus early in the new year. The plan would then be for the procedure to start in good time for RIPE70. In case anyone cares, here's that proposed text again. # # $Id: appointment,v 1.6 2014/10/06 11:46:56 jim Exp $ # [1] The DNS WG will have N co-chairs. N will normally be 2 or 3, as determined by the WG. [2] A co-chair will serve a term of N years, where N is the number of co-chairs. Terms will be staggered so that one term expires every year. A co-chair cannot serve more than 2 consecutive terms. [3] The WG will be given adequate notice that a co-chair's term is ending and to invite applications for that position. Anyone can volunteer for appointment. [4] At the end of a co-chair's term, the WG will decide by consensus who is appointed to the available co-chair position. In the event of a tie, the consensus tied candidates will draw lots. [5] The WG may decide by consensus to remove a WG co-chair at any time. [6] Consensus will be determined on the DNS WG mailing list. The consensus judgement will be made by the serving WG co-chair(s) and will exclude the co-chair who is the subject of that consensus judgement. [7] Any appeal over a consensus decision will be heard by the RIPE Chair (or their deputy) whose decision shall be final. From nick at foobar.org Tue Nov 25 13:37:01 2014 From: nick at foobar.org (Nick Hilliard) Date: Tue, 25 Nov 2014 12:37:01 +0000 Subject: [dns-wg] reminder about the WG Chair appointment process In-Reply-To: <0FF3EBE1-D991-4669-9086-3248FD0728FF@rfc1035.com> References: <0FF3EBE1-D991-4669-9086-3248FD0728FF@rfc1035.com> Message-ID: <547477ED.2020906@foobar.org> On 25/11/2014 12:09, Jim Reid wrote: > In case anyone cares, here's that proposed text again. Jim, the proposal is non-deterministic. There's no discriminator in place to decide who gets to stand down if N changes and two chairs need to stand down at the same time, or if somehow the chair terms become synchronised. Drawing lots is fine but where, how, who, what? What happens if the WG goes to blazes and there's only one chair and that chair is subject of a mutiny? Maybe this isn't important and we can do the usual trick of sweeping it under the carpet and pretending that it doesn't exist / isn't a problem / oh look at the nice view out the window over there. Nick > > # > # $Id: appointment,v 1.6 2014/10/06 11:46:56 jim Exp $ > # > [1] The DNS WG will have N co-chairs. N will normally be 2 or 3, as > determined by the WG. > > [2] A co-chair will serve a term of N years, where N is the number > of co-chairs. Terms will be staggered so that one term expires every > year. A co-chair cannot serve more than 2 consecutive terms. > > [3] The WG will be given adequate notice that a co-chair's term is > ending and to invite applications for that position. Anyone can > volunteer for appointment. > > [4] At the end of a co-chair's term, the WG will decide by consensus > who is appointed to the available co-chair position. In the event of a > tie, the consensus tied candidates will draw lots. > > [5] The WG may decide by consensus to remove a WG co-chair at any time. > > [6] Consensus will be determined on the DNS WG mailing list. The consensus > judgement will be made by the serving WG co-chair(s) and will exclude the > co-chair who is the subject of that consensus judgement. > > [7] Any appeal over a consensus decision will be heard by the RIPE Chair > (or their deputy) whose decision shall be final. > From Michael.Daly at nominet.org.uk Tue Nov 25 14:51:05 2014 From: Michael.Daly at nominet.org.uk (Michael Daly) Date: Tue, 25 Nov 2014 13:51:05 +0000 Subject: [dns-wg] reminder about the WG Chair appointment process In-Reply-To: <547477ED.2020906@foobar.org> References: <0FF3EBE1-D991-4669-9086-3248FD0728FF@rfc1035.com> <547477ED.2020906@foobar.org> Message-ID: <001CC40F-5AA6-4201-8B96-09657145E65C@nominet.org.uk> > On 25 Nov 2014, at 12:37, Nick Hilliard wrote: > > On 25/11/2014 12:09, Jim Reid wrote: >> In case anyone cares, here's that proposed text again. > > Jim, the proposal is non-deterministic. There's no discriminator in place > to decide who gets to stand down if N changes and two chairs need to stand > down at the same time, or if somehow the chair terms become synchronised. > Drawing lots is fine but where, how, who, what? What happens if the WG > goes to blazes and there's only one chair and that chair is subject of a > mutiny? > > Maybe this isn't important and we can do the usual trick of sweeping it > under the carpet and pretending that it doesn't exist / isn't a problem / > oh look at the nice view out the window over there. > > Nick I agree that this is a (Small) flaw. However we can t actually plan for every eventuality and I think as a group of we are grown up enough to deal with this is a sensible way if it ever comes up.. - The proposal gets my support.. Michael > >> >> # >> # $Id: appointment,v 1.6 2014/10/06 11:46:56 jim Exp $ >> # >> [1] The DNS WG will have N co-chairs. N will normally be 2 or 3, as >> determined by the WG. >> >> [2] A co-chair will serve a term of N years, where N is the number >> of co-chairs. Terms will be staggered so that one term expires every >> year. A co-chair cannot serve more than 2 consecutive terms. >> >> [3] The WG will be given adequate notice that a co-chair's term is >> ending and to invite applications for that position. Anyone can >> volunteer for appointment. >> >> [4] At the end of a co-chair's term, the WG will decide by consensus >> who is appointed to the available co-chair position. In the event of a >> tie, the consensus tied candidates will draw lots. >> >> [5] The WG may decide by consensus to remove a WG co-chair at any time. >> >> [6] Consensus will be determined on the DNS WG mailing list. The consensus >> judgement will be made by the serving WG co-chair(s) and will exclude the >> co-chair who is the subject of that consensus judgement. >> >> [7] Any appeal over a consensus decision will be heard by the RIPE Chair >> (or their deputy) whose decision shall be final. >> > > From jim at rfc1035.com Tue Nov 25 15:42:32 2014 From: jim at rfc1035.com (Jim Reid) Date: Tue, 25 Nov 2014 14:42:32 +0000 Subject: [dns-wg] reminder about the WG Chair appointment process In-Reply-To: <547477ED.2020906@foobar.org> References: <0FF3EBE1-D991-4669-9086-3248FD0728FF@rfc1035.com> <547477ED.2020906@foobar.org> Message-ID: <21098E33-5E2E-4EDF-930C-A654A3F82C19@rfc1035.com> On 25 Nov 2014, at 12:37, Nick Hilliard wrote: > Jim, the proposal is non-deterministic. Nick, thanks for your comments. I'm both surprised and disappointed. Surprised because the mood of the room/WG appears to be the proposed text is "good enough". Nobody has advocated making radical surgery to it despite the proposed text being in circulation for almost two months now. I'm disappointed that you've not provided alternate text to address the concerns you raised. This is not helpful. > There's no discriminator in place > to decide who gets to stand down if N changes and two chairs need to stand > down at the same time, or if somehow the chair terms become synchronised. Just apply common sense. If we go from 3 to 2 WG co-chairs, the one that's next due to stand down does not get replaced and the remaining ones get their terms cut by one year. If we then go from 2 to 3, do the reverse: extend the current terms by a year and slot in a new co-chair appointment at the newly-created gap in the cycle. If a co-chair leaves mid-term, the replacement (if one) gets appointed for the remainder of that term and we carry on from there: no muss, no fuss. Says he making it up as he goes along.... :-) > Drawing lots is fine but where, how, who, what? In whatever place and format that the WG decides is resonable and appropriate: presumably at a webcasted session of the WG. A decision on that is implementation detail and since it may change from time to time, I think it's undesirable to have a rigid definition here. IMO RIPE should always operate with the minimum of rules so there's the maximum flexibility to deal with issues in the most pragmatic way whenever they pop up. This is what differentiates our community from ICANN. Or the ITU. It would be great shame if that got lost. It would be even worse if we deliberately chose to follow the models used by those institutions. > What happens if the WG goes to blazes and there's only one chair and that chair is subject of a mutiny? If that ever happens, bring in Bijal to kill the WG. :-) The WG would clearly be irreedemably broken by then and cannot continue. The community can then decide to create a new WG (or not) using the usual mechanisms of running a BoF or two, finding a possible chairman and drafting a new chapter. This seems so obvious to me, it shouldn't need to get documented in some Big Book of Working Group Procedures resting in the Holy Grail at the Temple of Process. [Hey, isn't that the title of the next Indiana Jones film? :-)] There's nothing in the current proposal to deal with one of the WG co-chairs getting incapacitated by killer sharks with mind-control lasers. Or all co-chairs disappearing in a mysterious boating accident involving the Loch Ness monster. The point I'm making here is inventing rules to cover every potential corner case and scenario is a mug's game. I hope everyone has got better things to do. IMO all that's needed is to agree and document the fundamental principles. How these get applied can be decided if/when some unforseen circumstance emerges and what approach is best to handle that, getting consensus from the WG if need be. I would expect the WG can trust itself to take a reasonable and pragmatic course of action at that point. If it can't, no amount of rules or process is going to help. > Maybe this isn't important +1 > and we can do the usual trick of sweeping it > under the carpet and pretending that it doesn't exist / isn't a problem / Works for me. YMMV. > oh look at the nice view out the window over there. Look! A squirrel! From nick at foobar.org Tue Nov 25 18:54:33 2014 From: nick at foobar.org (Nick Hilliard) Date: Tue, 25 Nov 2014 17:54:33 +0000 Subject: [dns-wg] reminder about the WG Chair appointment process In-Reply-To: <21098E33-5E2E-4EDF-930C-A654A3F82C19@rfc1035.com> References: <0FF3EBE1-D991-4669-9086-3248FD0728FF@rfc1035.com> <547477ED.2020906@foobar.org> <21098E33-5E2E-4EDF-930C-A654A3F82C19@rfc1035.com> Message-ID: <5474C259.4090006@foobar.org> On 25/11/2014 14:42, Jim Reid wrote: > Nick, thanks for your comments. > > I'm both surprised and disappointed. Surprised because the mood of the > room/WG appears to be the proposed text is "good enough". Nobody has > advocated making radical surgery to it despite the proposed text being > in circulation for almost two months now. I'm disappointed that you've > not provided alternate text to address the concerns you raised. This is > not helpful. You're welcome for the comments. I wasn't able to make the london wg session and only subscribed to the mailing list on Oct 11, which was a couple of days after the previous discussion about chair proposals ended. Timing is everything, apparently. >> There's no discriminator in place to decide who gets to stand down if >> N changes and two chairs need to stand down at the same time, or if >> somehow the chair terms become synchronised. > > Just apply common sense. If we go from 3 to 2 WG co-chairs, the one > that's next due to stand down does not get replaced and the remaining > ones get their terms cut by one year. If we then go from 2 to 3, do the > reverse: extend the current terms by a year and slot in a new co-chair > appointment at the newly-created gap in the cycle. If a co-chair leaves > mid-term, the replacement (if one) gets appointed for the remainder of > that term and we carry on from there: no muss, no fuss. Says he making > it up as he goes along.... :-) I don't disagree with any of this, including the common sense thing, but you've put your finger on the core issue: making things up as you go along is fine in situations where the WG chairs are both benign and competent. Problems arise where either of these attributes is missing, which is one of the core reasons why there is a move to have WG selection guidelines in the first place. >> What happens if the WG goes to blazes and there's only one chair and >> that chair is subject of a mutiny? > > If that ever happens, bring in Bijal to kill the WG. :-) eh yeah, I cannot confirm or deny deleting that suggestion from my original email before clicking send. But on a more serious note, being prime instigator in a certain incident not wholly unrelated to this, some guidelines / procedures would have things a lot easier for everyone involved. It's good to see that you've explicitly mentioned chair removal in the appointment text because it's important. > There's nothing in the current proposal to deal with one of the WG > co-chairs getting incapacitated by killer sharks with mind-control > lasers. Or all co-chairs disappearing in a mysterious boating accident > involving the Loch Ness monster. Indeed no, nor do we need things like this; just that the proposals be unambiguous and straightforward, and that they cover most situations. Nick From pk at DENIC.DE Tue Nov 25 19:15:03 2014 From: pk at DENIC.DE (Peter Koch) Date: Tue, 25 Nov 2014 19:15:03 +0100 Subject: [dns-wg] reminder about the WG Chair appointment process In-Reply-To: <0FF3EBE1-D991-4669-9086-3248FD0728FF@rfc1035.com> References: <0FF3EBE1-D991-4669-9086-3248FD0728FF@rfc1035.com> Message-ID: <20141125181503.GB32749@x28.adm.denic.de> On Tue, Nov 25, 2014 at 12:09:25PM +0000, Jim Reid wrote: > [2] A co-chair will serve a term of N years, where N is the number > of co-chairs. Terms will be staggered so that one term expires every > year. A co-chair cannot serve more than 2 consecutive terms. as was mentioned during the session, not all of the co-chairs agreed on this text. Let me explain my dissent: iff (sic!) we accept the 'as lightweight as possible' axiom for the design, the term limit seems redundant to me based on the assumption that common sense should prevail. Change and rotation is already taken care of by the useful term length and explicit appointment procedures. Rest assured this is not myself looking forward to a lifetime sentence. > [5] The WG may decide by consensus to remove a WG co-chair at any time. Last time this became imminent in another WG, a lynch mob was orchestrated kind of along these lines. The result was right, just that due process suffered "a bit". Therefore I think this aspect is underspecified and would benefit from replacement by what the WG chair task force had come up with. Of course, that's not specific to this particular WG. -Peter (no hat) From jim at rfc1035.com Tue Nov 25 19:46:31 2014 From: jim at rfc1035.com (Jim Reid) Date: Tue, 25 Nov 2014 18:46:31 +0000 Subject: [dns-wg] reminder about the WG Chair appointment process In-Reply-To: <5474C259.4090006@foobar.org> References: <0FF3EBE1-D991-4669-9086-3248FD0728FF@rfc1035.com> <547477ED.2020906@foobar.org> <21098E33-5E2E-4EDF-930C-A654A3F82C19@rfc1035.com> <5474C259.4090006@foobar.org> Message-ID: On 25 Nov 2014, at 17:54, Nick Hilliard wrote: > You're welcome for the comments. I wasn't able to make the london wg > session and only subscribed to the mailing list on Oct 11, which was a > couple of days after the previous discussion about chair proposals ended. > Timing is everything, apparently. Indeed. Sigh. > I don't disagree with any of this, including the common sense thing, but > you've put your finger on the core issue: making things up as you go along > is fine in situations where the WG chairs are both benign and competent. But why should this be a problem? Presumably the WG can be trusted to select people who have those qualities. If it turns out not to be the case, the WG has the tools to get rid of someone who no longer has the confidence of the WG for whatever reason. The proposed mechanism includes a measure for removing any WG co-chair who was evil or incompetent or both. So it shouldn't be necessary to go beyond that. If this admittedly complacent attitude later turns out to have been a mistake, it can be addressed at that point. > Problems arise where either of these attributes is missing, which is one of > the core reasons why there is a move to have WG selection guidelines in the > first place. Not quite Nick. The main reasons for this WG chair selection-fest are accountability and transparency. It was not motivated by the recent need to remove a defective WG chair. Though admittedly some people felt at that time that the absence of a process to follow was a concern. Not that this gap made a difference to the outcome in that particular case once an angry mob with pitchforks and blazing torches made their feelings known in the relevant WG. From mir at ripe.net Wed Nov 26 14:04:30 2014 From: mir at ripe.net (Mirjam Kuehne) Date: Wed, 26 Nov 2014 14:04:30 +0100 Subject: [dns-wg] New on RIPE Labs: The Resolvers We Use (by Geoff Huston) Message-ID: <5475CFDE.5030509@ripe.net> Dear colleagues, For those who missed the plenary talk Geoff Huston gave on Monday during RIPE 69 ("The Resolvers We Use"), it is now published as an article on RIPE Labs: https://labs.ripe.net/Members/gih/the-resolvers-we-use Kind regards, Mirjam Kuehne RIPE NCC From nick at foobar.org Thu Nov 27 17:32:54 2014 From: nick at foobar.org (Nick Hilliard) Date: Thu, 27 Nov 2014 16:32:54 +0000 Subject: [dns-wg] reminder about the WG Chair appointment process In-Reply-To: <20141125181503.GB32749@x28.adm.denic.de> References: <0FF3EBE1-D991-4669-9086-3248FD0728FF@rfc1035.com> <20141125181503.GB32749@x28.adm.denic.de> Message-ID: <54775236.9010104@foobar.org> On 25/11/2014 18:15, Peter Koch wrote: > On Tue, Nov 25, 2014 at 12:09:25PM +0000, Jim Reid wrote: > >> [2] A co-chair will serve a term of N years, where N is the number >> of co-chairs. Terms will be staggered so that one term expires every >> year. A co-chair cannot serve more than 2 consecutive terms. > > as was mentioned during the session, not all of the co-chairs agreed on > this text. Let me explain my dissent: iff (sic!) we accept the 'as lightweight > as possible' axiom for the design, the term limit seems redundant to me > based on the assumption that common sense should prevail. Change and rotation > is already taken care of by the useful term length and explicit appointment > procedures. Rest assured this is not myself looking forward to a lifetime sentence. > >> [5] The WG may decide by consensus to remove a WG co-chair at any time. > > Last time this became imminent in another WG, a lynch mob was orchestrated > kind of along these lines. The result was right, just that due process > suffered "a bit". Therefore I think this aspect is underspecified and > would benefit from replacement by what the WG chair task force had come up with. > Of course, that's not specific to this particular WG. > > -Peter (no hat) I'm fascinated by the ability of so many people in the RIPE community to be able to switch hats from one moment to the next, depending on the topic, and then argue about something as passionately as they claim to be dispassionate. Perhaps at the next meeting we could have a game of hat-switching bingo? Dutch bonnets for the winner, nieuwe haring for the runners-up. Otherwise, can you confirm that it is your completely unbiassed opinion, speaking as not-working-group-chair for a brief moment, that working group chairs should not be obliged to routinely stand down for re-selection because "don't be silly!" Nick From nick at foobar.org Thu Nov 27 17:39:16 2014 From: nick at foobar.org (Nick Hilliard) Date: Thu, 27 Nov 2014 16:39:16 +0000 Subject: [dns-wg] reminder about the WG Chair appointment process In-Reply-To: References: <0FF3EBE1-D991-4669-9086-3248FD0728FF@rfc1035.com> <547477ED.2020906@foobar.org> <21098E33-5E2E-4EDF-930C-A654A3F82C19@rfc1035.com> <5474C259.4090006@foobar.org> Message-ID: <547753B4.8080800@foobar.org> On 25/11/2014 18:46, Jim Reid wrote: > But why should this be a problem? I'm not saying it'll ever be a problem for DNS-WG in the future, just that it's been a problem for other WGs in the past. Those who don't learn their history are condemned to repeat it. Nick