From jim at rfc1035.com Wed Oct 8 11:43:25 2014 From: jim at rfc1035.com (Jim Reid) Date: Wed, 8 Oct 2014 10:43:25 +0100 Subject: [dns-wg] proposal for appointment/removal of WG co-chairs Message-ID: <9533115E-E360-49B1-AFA5-04BE569FC463@rfc1035.com> Colleagues, you may be aware that all RIPE Working Groups have been asked to devise and document a procedure for the selection of its Chairs. Some WGs have started to do that. Each WG is expected to come up with its own mechanism and decide on that themselves. My personal view is WGs are too different and the community is too diffuse for consensus to emerge on a "one size fits all" approach any time soon. Perhaps WGs will converge on a common approach in a few years in light of experience with whatever mechanisms get adopted in the coming months. However, that should not delay each WG deciding on a procedure and using it. And documenting it of course! With that in mind, here's a proposal for you to consider. The objective here is to have something simple and lightweight with the minimum of "rules" and "process". Feel free to disagree if you prefer something more elaborate. The key points in the draft are (a) the WG decides for itself how the WG gets run; (b) we work by consensus; (c) decisions are taken on the list; (d) there is an element of rotation. As well as the expected list discussion, there will be some time in the WG agenda for RIPE69 to discuss matters. The hope is the WG can reach consensus on an appointment/removal mechanism by the end of the year (ish) and the first run of the WG Chair beauty contest (swimsuit round optional) by RIPE70(ish) in 2015. Comments welcome. # # $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 joao at bondis.org Wed Oct 8 12:05:41 2014 From: joao at bondis.org (=?iso-8859-1?Q?Jo=E3o_Damas?=) Date: Wed, 8 Oct 2014 12:05:41 +0200 Subject: [dns-wg] proposal for appointment/removal of WG co-chairs In-Reply-To: <9533115E-E360-49B1-AFA5-04BE569FC463@rfc1035.com> References: <9533115E-E360-49B1-AFA5-04BE569FC463@rfc1035.com> Message-ID: <40917E73-BA89-4F35-B47F-25ABCCE256AE@bondis.org> I like simplicity that works so, in general, the proposal looks good to me. A few questions though: On 08 Oct 2014, at 11:43, Jim Reid wrote: > > Comments welcome. > > # > # $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. > Can we at least pick a default value, e.g. 3 as it is now, since it seems to work. > [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. Please define tie in the context of a consensus process. Sounds like one of these simple-to-say/hard-to-do-right things. What would be wrong with a simple vote? sounds simpler. > > [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. In closing, would the current co-chairs stay in place, initiate a rotation right away, or all clear the deck (ala IPv6 wg)? Thanks for this, Joao -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jim at rfc1035.com Wed Oct 8 13:18:22 2014 From: jim at rfc1035.com (Jim Reid) Date: Wed, 8 Oct 2014 12:18:22 +0100 Subject: [dns-wg] proposal for appointment/removal of WG co-chairs In-Reply-To: <40917E73-BA89-4F35-B47F-25ABCCE256AE@bondis.org> References: <9533115E-E360-49B1-AFA5-04BE569FC463@rfc1035.com> <40917E73-BA89-4F35-B47F-25ABCCE256AE@bondis.org> Message-ID: On 8 Oct 2014, at 11:05, Jo?o Damas wrote: > I like simplicity that works so, in general, the proposal looks good to me. Thanks Joao. >> [1] The DNS WG will have N co-chairs. N will normally be 2 or 3, as >> determined by the WG. > > Can we at least pick a default value, e.g. 3 as it is now, since it seems to work. I think it's best to leave this open for now Joao: flexibility and all that. The WG is probably only going to have one slot at RIPE69 and if that continues for future meetings, 2 co-chairs may well be enough. OTOH if the WG gets flooded with work and/or agenda items, an extra meeting slot and co-chair would be needed. A decision on the number of co-chairs should be separated from the appointment procedure. ie the thing here is co-chairs serve a term of N years where N is whatever the number of co-chairs the WG decides is appropriate. >> [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. > > Please define tie in the context of a consensus process. Sounds like one of these simple-to-say/hard-to-do-right things. When two or more candidates have roughly equal levels of support which means there's no clear consensus on who should be appointed. I hope we can just apply common sense here instead of devising a procedure which requires wordsmithing and amateur lawyering over lots of definitions. > What would be wrong with a simple vote? sounds simpler. There be dragons! It opens up too many awkward problems IMO. Like deciding who gets to vote, how that gets done anonymously (presumably), what the eligibility criteria are, how the vote gets audited/counted, etc, etc. Voting by mailing list or on-line gives me the heebie-jeebies. I'm unsure how feasible it would be to use the NCC's on-line voting stuff (say) to appoint a WG Chair. Or if that's even appropriate. [Maybe one of the other WGs will try that and see how it works out.] Voting in person at a RIPE meeting would disenfranchise those who are unable to attend. So although voting might sound simpler, IMO it opens up lots of rat-holes and adds unwelcome complexity that shouldn't be needed. YMMV. I think it's best to start with something simple and lightweight. The procedure can always be changed later if/when experience shows that voting or whatever turns out to be a better way of deciding things. It seems reasonable to me that if the WG arrives at a consensus behind two candidates for one position, we might as well toss a coin to pick one of them. Why bother with anything more complicated than that? Aside from these operational and practical concerns, there's an important meta-issue. RIPE does not vote. It is not the ITU. RIPE decides important things by consensus (or should do). It will be a very sad day if RIPE sleepwalks away from consensus-driven decision making and introduces voting for (nearly) everything. Yes, I know we vote at RIPE meetings for the ASO and PC. But these things have no impact on RIPE's governance and policy-making. > In closing, would the current co-chairs stay in place, initiate a rotation right away, or all clear the deck (ala IPv6 wg)? That's for the WG to decide. My own view is there should not be a mass clear-out -- continuity and all that -- and the current co-chairs would be subject to whatever process the WG decides, one per year. So one of Jaap, Peter and myself would go through the process in 2015, another in 2016 and the final stuckee in 2017. That might well allow fresh faces to be gradually introduced: no bad thing. However if the WG feels a palace coup is required, that'll be fine by me. From gilles.massen at restena.lu Thu Oct 9 09:59:28 2014 From: gilles.massen at restena.lu (Gilles Massen) Date: Thu, 09 Oct 2014 09:59:28 +0200 Subject: [dns-wg] proposal for appointment/removal of WG co-chairs In-Reply-To: <9533115E-E360-49B1-AFA5-04BE569FC463@rfc1035.com> References: <9533115E-E360-49B1-AFA5-04BE569FC463@rfc1035.com> Message-ID: <54364060.4030000@restena.lu> Jim, Nice, simple, straightforward guidance for well behaving people. Love it. > # > # $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. Why restrict strictly to 2 consecutive terms? If WG and chairs are happy, why not keep them? (esp. if there are no other candidates) > [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. Can one be volonteered? (in case someone needs a gentle nudge) > [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. This may be the only point where I think something close to a majority is enough: if about half of the membership does no longer approve a co-chair, he may not longer be fit to play that role. > [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. Gilles -- Fondation RESTENA - DNS-LU 6, rue Coudenhove-Kalergi L-1359 Luxembourg tel: (+352) 424409 fax: (+352) 422473 From jim at rfc1035.com Thu Oct 9 10:52:06 2014 From: jim at rfc1035.com (Jim Reid) Date: Thu, 9 Oct 2014 09:52:06 +0100 Subject: [dns-wg] proposal for appointment/removal of WG co-chairs In-Reply-To: <54364060.4030000@restena.lu> References: <9533115E-E360-49B1-AFA5-04BE569FC463@rfc1035.com> <54364060.4030000@restena.lu> Message-ID: <93C12175-10DD-4CC6-8D9E-FBB31A276B79@rfc1035.com> On 9 Oct 2014, at 08:59, Gilles Massen wrote: > Nice, simple, straightforward guidance for well behaving people. Love it. Thanks Gilles. >> [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. > > Why restrict strictly to 2 consecutive terms? If WG and chairs are > happy, why not keep them? (esp. if there are no other candidates) The intention is to have an element of rotation so that new faces will be introduced from time to time. I suppose a well-respected co-chair could take a sabbatical for a year and take their chances in the appointment process the year after that. OTOH maybe that's not needed. It'll be for the WG to decide. FWIW your co-chairs do not agree on whether this 2 consecutive clauses should be there or not. So we're asking all of you. :-) Perhaps there's a better trade-off between stability/continuity and letting things get stale. >> [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. > > Can one be volonteered? (in case someone needs a gentle nudge) Sure. Why not? It's quite likely someone might not think of putting themselves forward even though others consider they'd be a good candidate. If need be, I suppose the other WG co-chairs could look for potential stuckees and apply some arm-twisting^W^Wfriendly persuasion. The main idea here is to make the barriers to entry as low as possible. Anyone who's prepared to do the job should have no obstacles to applying. >> [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. > > This may be the only point where I think something close to a majority > is enough: if about half of the membership does no longer approve a > co-chair, he may not longer be fit to play that role. I would expect a reasonable co-chair to stand down immediately if there was a credible motion of no confidence against them and there would be no need for the WG to take that consensus decision. That's certainly what I would do. [Don't all rush at once! :-)] If things did get to that point, a consensus decision will be good enough IMO. In all likelihood that would be a majority decision one way or another. For some definition of majority. From nick at foobar.org Sat Oct 11 00:02:53 2014 From: nick at foobar.org (Nick Hilliard) Date: Fri, 10 Oct 2014 23:02:53 +0100 Subject: [dns-wg] heads-up on dec.com domain Message-ID: <5438578D.5050000@foobar.org> folks, for those not already aware, control of the dec.com domain was transferred to an unknown third party a couple of weeks ago and is no longer owned by HP Inc, Hewlett-Packard Enterprise or anyone with prior responsibility to the remains of Digital Equipment Corporation. This means that the address records for the uucp-gw-{1,2}.pa.dec.com nameservers are controlled by an unknown third party. Most organisations migrated away from these host names many moons ago (including all but one cctld), but there are still some second-level domains out there who use these hosts for NS records. If any ccTLDs recognise this these host names in their zone files, the old farts still using them might appreciate a heads up on what's happened and what they need to do. Nick From jim at rfc1035.com Sat Oct 11 01:39:12 2014 From: jim at rfc1035.com (Jim Reid) Date: Sat, 11 Oct 2014 00:39:12 +0100 Subject: [dns-wg] heads-up on dec.com domain In-Reply-To: <5438578D.5050000@foobar.org> References: <5438578D.5050000@foobar.org> Message-ID: On 10 Oct 2014, at 23:02, Nick Hilliard wrote: > folks, > > for those not already aware, control of the dec.com domain was transferred > to an unknown third party a couple of weeks ago and is no longer owned by > HP Inc, Hewlett-Packard Enterprise or anyone with prior responsibility to > the remains of Digital Equipment Corporation. > > This means that the address records for the uucp-gw-{1,2}.pa.dec.com > nameservers are controlled by an unknown third party. > > Most organisations migrated away from these host names many moons ago > (including all but one cctld), but there are still some second-level > domains out there who use these hosts for NS records. > > If any ccTLDs recognise this these host names in their zone files, the old > farts still using them might appreciate a heads up on what's happened and > what they need to do. Thanks for this Nick. Do you know if IANA have been informed? I would like to think IANA is in contact with the TLDs who have these legacy delegations and is co-ordinating a response. This might also be an opportunity for those TLD operators to find other DNS suppliers. Perhaps they'll arrange contracts too instead of relying on the presumably undocumented arrangements for uucp-gw-{1,2}.pa.dec.com. From drc at virtualized.org Sat Oct 11 01:42:57 2014 From: drc at virtualized.org (David Conrad) Date: Fri, 10 Oct 2014 16:42:57 -0700 Subject: [dns-wg] heads-up on dec.com domain In-Reply-To: References: <5438578D.5050000@foobar.org> Message-ID: On Oct 10, 2014, at 4:39 PM, Jim Reid wrote: > Do you know if IANA have been informed? Yes. uucp-gw-{1,2}.pa.dec.com. Wow. What a blast from the past... 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 kim.davies at icann.org Sat Oct 11 03:33:10 2014 From: kim.davies at icann.org (Kim Davies) Date: Sat, 11 Oct 2014 01:33:10 +0000 Subject: [dns-wg] heads-up on dec.com domain In-Reply-To: <5438578D.5050000@foobar.org> References: <5438578D.5050000@foobar.org> Message-ID: <0E8542B3-4049-4D8A-B265-7BFC7327DD05@icann.org> On Oct 10, 2014, at 3:02 PM, Nick Hilliard wrote: > > This means that the address records for the uucp-gw-{1,2}.pa.dec.com > nameservers are controlled by an unknown third party. > > Most organisations migrated away from these host names many moons ago > (including all but one cctld), but there are still some second-level > domains out there who use these hosts for NS records. FWIW, the "official" replacement hostnames are ns{3,4}.hpl.hp.com, and the affected ccTLD is in process to update to those. kim From niall.oreilly at ucd.ie Sat Oct 11 22:06:11 2014 From: niall.oreilly at ucd.ie (Niall O'Reilly) Date: Sat, 11 Oct 2014 21:06:11 +0100 Subject: [dns-wg] heads-up on dec.com domain In-Reply-To: <0E8542B3-4049-4D8A-B265-7BFC7327DD05@icann.org> References: <5438578D.5050000@foobar.org> <0E8542B3-4049-4D8A-B265-7BFC7327DD05@icann.org> Message-ID: At Sat, 11 Oct 2014 01:33:10 +0000, Kim Davies wrote: > > FWIW, the "official" replacement hostnames are ns{3,4}.hpl.hp.com, > and the affected ccTLD is in process to update to those. Thanks, Kim. This infomation will be useful to the holders of a number of second-or-lower-level domains. /Niall From romeo.zwart at ripe.net Mon Oct 20 12:38:32 2014 From: romeo.zwart at ripe.net (Romeo Zwart) Date: Mon, 20 Oct 2014 12:38:32 +0200 Subject: [dns-wg] time slot for RIPE NCC update Message-ID: <5444E628.9090500@ripe.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 dear Chairs, As usual, we would like to have a time slot for a quick update from the RIPE NCC. Some 15 minutes would be sufficient. Anand will, as usual, present this. Also, are there any updates on the outstanding issues we have discussed on the list previously (the 'policy-statement' around ccTLD secondary; adding new zones to DNSMON and visualisation delay for DNSMON)? Discussion on these topics seems to have dried up a long time ago. It would be great if we can achieve formal closure on these during the coming meeting. Would it be useful to specifically schedule an agenda item to have the WG formalise their decisions? Kind regards, Romeo -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlRE5icACgkQGRL9suBV+er0zQCfdDZfzV7DCkAGXqYp+uC1nabY qD8AoIGmwV9pHuexvyLztjtr/vMsHKvn =v1VY -----END PGP SIGNATURE----- From jaap at nlnetlabs.nl Wed Oct 22 12:11:31 2014 From: jaap at nlnetlabs.nl (Jaap Akkerhuis) Date: Wed, 22 Oct 2014 12:11:31 +0200 Subject: [dns-wg] DNS-WG Draft agenda Message-ID: <201410221011.s9MABVDG081109@bela.nlnetlabs.nl> Apologies for the delay, but ICANN ate my homework and a disk crash didn't help either. Anyway, here is the draft agenda for the DNS-WG. jaap -------------- next part -------------- DNS WG, Thursday 6 November 09:00-10:30 Drafts agenda A. Administrative matters o Welcome o Scribe selection/introduction o Jabber selection/introduction o Microphone Etiquette o Finalise agenda B. Matters arising from RIPE-68 Minutes (None the co-chairs are aware off) C. Review of Action items (No open items) E. RIPE-NCC Report: Update Anand Buddhdev F. DNS attacks: can we still afford using old, ineffective solutions? Nicolas Cartron, efficientip.com These days see an increase in DDoS DNS attacks, more of them making their way to the public and this talks presents new answers to DNS attacks. G. Dynamic DNS Abuse Overview, Chris Baker dyn.org This presentation details how dynamic dns is being abused and how different types of abuse can be detected H. Please don't pick the ECDSA-ies, George Michaelson. apnic Possible effects of RSA->ECC algorithm change in DNSSEC I. DNS-WG Organisational discussion, Jim Reid Chairs elections etc. Z. AOB From romeo.zwart at ripe.net Wed Oct 29 17:18:57 2014 From: romeo.zwart at ripe.net (Romeo Zwart) Date: Wed, 29 Oct 2014 17:18:57 +0100 Subject: [dns-wg] Experiment proposal to improve K-root In-Reply-To: <5450CCA0.9040009@ripe.net> References: <554547DD-F70B-4575-9D2A-B9DA0423C3E3@ripe.net> <84EF1D21-87C1-4B13-9F28-7A9523546BD5@ripe.net> <82624AEE-A3F3-4DF5-8B8C-48DAE6C4586F@ripe.net> <5450CCA0.9040009@ripe.net> Message-ID: <54511371.3000008@ripe.net> Dear colleagues, We used RIPE Atlas to measure latency to K-root, and we believe we can improve average latency by adding new nodes to K-root in strategic locations. In a new RIPE Labs article, we propose performing an experiment that would let us measure this potential improvement. You can find the details, including the full measurement results, here: https://labs.ripe.net/Members/suzanne_taylor_muzzin/experiment-proposal-to-improve-k-root As we define the experiment, we will publish more specific details about how many nodes we will add, in which locations, and what kind of improvement we might expect. If you have any feedback about these plans, please share your feedback on this list. Kind regards, Romeo Zwart Global Information Infrastructure Manager RIPE NCC