From jim at rfc1035.com Mon Jan 5 18:33:48 2015 From: jim at rfc1035.com (Jim Reid) Date: Mon, 5 Jan 2015 17:33:48 +0000 Subject: [dns-wg] yet another heave on the WG Chair selection procedure Message-ID: <6C2679FD-69F8-4452-ADE9-93DF3E847AAA@rfc1035.com> Happy new year everyone. The list has been silent about the draft selection procedure. This means it's not possible to decide if there's a consensus or not so we can declare victory and move on. Sigh. Could I ask you all to review the proposal and comment on the list? One sticking point appears to be the "A co-chair cannot serve more than 2 consecutive terms." provision in [2]. Someone commented at the mike at RIPE69 that this was a good thing. One of your co-chairs says the opposite. Everyone else has not commented one way or the other. Result: stalemate. WGs are supposed to have adopted a selection process by now and have it up and running in good time for RIPE70. Our WG is lagging behind the others. So, could we please have some comments on the proposed procedure and try to get the WG to converge on a consensus? Thanks. It would be appreciated if people gave clear statements of support or objection. In the latter case, please explain why and suggest alternate text. Simply saying "I disagree" will not be constructive. Though it would of course help with the consensus determination. Here's the suggested process 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 Mon Jan 5 21:59:59 2015 From: nick at foobar.org (Nick Hilliard) Date: Mon, 05 Jan 2015 20:59:59 +0000 Subject: [dns-wg] yet another heave on the WG Chair selection procedure In-Reply-To: <6C2679FD-69F8-4452-ADE9-93DF3E847AAA@rfc1035.com> References: <6C2679FD-69F8-4452-ADE9-93DF3E847AAA@rfc1035.com> Message-ID: <54AAFB4F.805@foobar.org> Jim, On 05/01/2015 17:33, Jim Reid wrote: > One sticking point appears to be the "A co-chair cannot serve more than > 2 consecutive terms." provision in [2]. Someone commented at the mike > at RIPE69 that this was a good thing. One of your co-chairs says the > opposite. Everyone else has not commented one way or the other. Result: > stalemate. I'm in favour of term limits, but please tidy up the language because we're all a bit ASD. "A co-chair cannot serve more than 2 consecutive terms" could mean that once you've done two consecutive terms, you cannot serve ever again. You probably mean that after a period of not being co-chair, they can submit themselves for re-selection again. It's not easy to suggest language tweaks to fix this because the rest of the selection / resignation mechanism is non-deterministic and needs to be re-thought out, which gets back to the points I brought up previously which still haven't really been dealt with. Nick From pk at DENIC.DE Mon Jan 5 22:20:07 2015 From: pk at DENIC.DE (Peter Koch) Date: Mon, 5 Jan 2015 22:20:07 +0100 Subject: [dns-wg] yet another heave on the WG Chair selection procedure In-Reply-To: <6C2679FD-69F8-4452-ADE9-93DF3E847AAA@rfc1035.com> References: <6C2679FD-69F8-4452-ADE9-93DF3E847AAA@rfc1035.com> Message-ID: <20150105212007.GC622@x28.adm.denic.de> Jim, all, On Mon, Jan 05, 2015 at 05:33:48PM +0000, Jim Reid wrote: > One sticking point appears to be the "A co-chair cannot serve more than 2 consecutive terms." provision in [2]. Someone commented at the mike at RIPE69 that this was a good thing. One of your co-chairs says the opposite. Everyone else has not commented one way or the other. Result: stalemate. I didn't quite say it that way and definitely not ex officio. What I tried was hold you/the proposal to its design criteria, first and foremost being "minimalist" or lean or lightweight, in the spirit of good protocol design - it's ready when yoy can't delete anything further. To that extent, the limits are superfluous because common sense will prevail. Should they be deemed necessary, there are probably bigger fish to fry, e.g., the impeachment clause. -Peter From Brett.Carr at nominet.org.uk Tue Jan 6 10:07:54 2015 From: Brett.Carr at nominet.org.uk (Brett Carr) Date: Tue, 6 Jan 2015 09:07:54 +0000 Subject: [dns-wg] yet another heave on the WG Chair selection procedure In-Reply-To: <6C2679FD-69F8-4452-ADE9-93DF3E847AAA@rfc1035.com> References: <6C2679FD-69F8-4452-ADE9-93DF3E847AAA@rfc1035.com> Message-ID: I strongly support the proposal that a WG Chair serves a term of N years and also cannot serve more than 2 consecutive terms, I also agree with Nick that adding something into the language to make it clear that a previous chair can be re-elected following a set period would be a good move. Brett Carr Nominet. On 05/01/2015 17:33, "Jim Reid" wrote: >Happy new year everyone. > >The list has been silent about the draft selection procedure. This means >it's not possible to decide if there's a consensus or not so we can >declare victory and move on. Sigh. Could I ask you all to review the >proposal and comment on the list? > >One sticking point appears to be the "A co-chair cannot serve more than 2 >consecutive terms." provision in [2]. Someone commented at the mike at >RIPE69 that this was a good thing. One of your co-chairs says the >opposite. Everyone else has not commented one way or the other. Result: >stalemate. > >WGs are supposed to have adopted a selection process by now and have it >up and running in good time for RIPE70. Our WG is lagging behind the >others. So, could we please have some comments on the proposed procedure >and try to get the WG to converge on a consensus? Thanks. > >It would be appreciated if people gave clear statements of support or >objection. In the latter case, please explain why and suggest alternate >text. Simply saying "I disagree" will not be constructive. Though it >would of course help with the consensus determination. > >Here's the suggested process 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 Piotr.Strzyzewski at polsl.pl Tue Jan 6 11:25:38 2015 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Tue, 6 Jan 2015 11:25:38 +0100 Subject: [dns-wg] yet another heave on the WG Chair selection procedure In-Reply-To: <6C2679FD-69F8-4452-ADE9-93DF3E847AAA@rfc1035.com> References: <6C2679FD-69F8-4452-ADE9-93DF3E847AAA@rfc1035.com> Message-ID: <20150106102538.GA12227@hydra.ck.polsl.pl> On Mon, Jan 05, 2015 at 05:33:48PM +0000, Jim Reid wrote: Dear All > One sticking point appears to be the "A co-chair cannot serve more than 2 consecutive terms." provision in [2]. Someone commented at the mike at RIPE69 that this was a good thing. One of your co-chairs says the opposite. Everyone else has not commented one way or the other. Result: stalemate. [cut] > # > # $Id: appointment,v 1.6 2014/10/06 11:46:56 jim Exp $ > # [cut] I support the proposal and at the same time I agree with Nick that some language clarification about re-election after break period should be considered. Piotr -- gucio -> Piotr Strzy?ewski E-mail: Piotr.Strzyzewski at polsl.pl From niall.oreilly at ucd.ie Tue Jan 6 13:41:52 2015 From: niall.oreilly at ucd.ie (Niall O'Reilly) Date: Tue, 06 Jan 2015 12:41:52 +0000 Subject: [dns-wg] yet another heave on the WG Chair selection procedure In-Reply-To: <6C2679FD-69F8-4452-ADE9-93DF3E847AAA@rfc1035.com> References: <6C2679FD-69F8-4452-ADE9-93DF3E847AAA@rfc1035.com> Message-ID: At Mon, 5 Jan 2015 17:33:48 +0000, Jim Reid wrote: > > Happy new year everyone. +1! I suggest replacing these paragraphs > [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. with these [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. [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 except that at the end of a second consecutive term, the outgoing co-chair may not do so. IHTH Niall From Michael.Daly at nominet.org.uk Tue Jan 6 13:48:29 2015 From: Michael.Daly at nominet.org.uk (Michael Daly) Date: Tue, 6 Jan 2015 12:48:29 +0000 Subject: [dns-wg] yet another heave on the WG Chair selection procedure In-Reply-To: References: <6C2679FD-69F8-4452-ADE9-93DF3E847AAA@rfc1035.com> Message-ID: <06EE2C75-34D9-47FE-8CCE-043797C5A9EA@nominet.org.uk> > On 6 Jan 2015, at 12:41, Niall O'Reilly wrote: > > At Mon, 5 Jan 2015 17:33:48 +0000, > Jim Reid wrote: >> >> Happy new year everyone. > > +1! > > I suggest replacing these paragraphs > >> [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. > > with these > > [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. > > [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 except that at the end of a second > consecutive term, the outgoing co-chair may not do so. +1 That works for me.. - I think that covers off any issues I might have had with the language. Michael From billy.glynn at iedr.ie Tue Jan 6 13:51:14 2015 From: billy.glynn at iedr.ie (Billy Glynn) Date: Tue, 6 Jan 2015 12:51:14 +0000 Subject: [dns-wg] yet another heave on the WG Chair selection procedure In-Reply-To: References: <6C2679FD-69F8-4452-ADE9-93DF3E847AAA@rfc1035.com> Message-ID: > On 6 Jan 2015, at 12:41, Niall O'Reilly wrote: > > At Mon, 5 Jan 2015 17:33:48 +0000, > Jim Reid wrote: >> >> Happy new year everyone. > > +1! > > I suggest replacing these paragraphs > >> [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. > > with these > > [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. > > [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 except that at the end of a second > consecutive term, the outgoing co-chair may not do so. +1 Billy (IEDR) From niall.oreilly at ucd.ie Wed Jan 7 09:42:06 2015 From: niall.oreilly at ucd.ie (Niall O'Reilly) Date: Wed, 07 Jan 2015 08:42:06 +0000 Subject: [dns-wg] yet another heave on the WG Chair selection procedure In-Reply-To: References: <6C2679FD-69F8-4452-ADE9-93DF3E847AAA@rfc1035.com> Message-ID: At Tue, 06 Jan 2015 12:41:52 +0000, Niall O'Reilly wrote: > > I suggest replacing these paragraphs [...] I ought perhaps also to have mentioned that I was just wordsmithing. I don't wish to take a position on either side of the discussion of whether a term limit is appropriate. Best regards, Niall From rstory at tislabs.com Wed Jan 7 17:20:51 2015 From: rstory at tislabs.com (Robert Story) Date: Wed, 7 Jan 2015 11:20:51 -0500 Subject: [dns-wg] yet another heave on the WG Chair selection procedure In-Reply-To: <20150105212007.GC622@x28.adm.denic.de> References: <6C2679FD-69F8-4452-ADE9-93DF3E847AAA@rfc1035.com> <20150105212007.GC622@x28.adm.denic.de> Message-ID: <20150107112051.287d5581@ispx.vb.futz.org> On Mon, 5 Jan 2015 22:20:07 +0100 Peter wrote: PK> [...] To that extent, the limits are superfluous PK> because common sense will prevail. PK> Should they be deemed necessary, there are probably bigger fish to fry, PK> e.g., the impeachment clause. I agree. It seems silly to limit the term of someone willing to serve and who has wg support. If, however, the consensus is in favor of term limits, I suggest that language be added to allow for an exception in the case where there are no other candidates available with sufficient wg support. Robert -- Senior Software Engineer @ Parsons -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From nick at foobar.org Wed Jan 7 21:14:11 2015 From: nick at foobar.org (Nick Hilliard) Date: Wed, 07 Jan 2015 20:14:11 +0000 Subject: [dns-wg] yet another heave on the WG Chair selection procedure In-Reply-To: <20150107112051.287d5581@ispx.vb.futz.org> References: <6C2679FD-69F8-4452-ADE9-93DF3E847AAA@rfc1035.com> <20150105212007.GC622@x28.adm.denic.de> <20150107112051.287d5581@ispx.vb.futz.org> Message-ID: <54AD9393.1000203@foobar.org> On 07/01/2015 16:20, Robert Story wrote: > I agree. It seems silly to limit the term of someone willing to serve and > who has wg support. This approach favours the creation of an incumbency, which most people agree is not good governance. > If, however, the consensus is in favor of term limits, I suggest that > language be added to allow for an exception in the case where there are no > other candidates available with sufficient wg support. This also encourages incumbencies to form. If a WG chair is going a good job, then reappointment within limits will be routine. If the proposed process causes the number of WG chairs to drop to zero, then that implies that only a single person (i.e. the last outgoing chair) is prepared to do the job. If this is the case, that would raise questions about whether the WG is worth keeping around. Nick From nick at foobar.org Wed Jan 7 21:15:09 2015 From: nick at foobar.org (Nick Hilliard) Date: Wed, 07 Jan 2015 20:15:09 +0000 Subject: [dns-wg] yet another heave on the WG Chair selection procedure In-Reply-To: References: <6C2679FD-69F8-4452-ADE9-93DF3E847AAA@rfc1035.com> Message-ID: <54AD93CD.8070509@foobar.org> On 06/01/2015 12:41, Niall O'Reilly 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. This is also semantically non-deterministic in the case where the number of co-chairs changes. >From what I can tell, the intention of Jim's proposal is that there is one resignation / appointment process per year, at which one co-chair steps down. If this is the case, here's a suggestion about how you might codify it: > [2] Every second RIPE meeting, the co-chair who has been in that > position the longest will resign. If more than one co-chair qualifies > for resignation, then only one co-chair will be required to resign, as > determined by [drawing lots|some other appropriate means]. Personally, I think it's simpler and more understandable to have fixed terms, e.g.: > [2] A co-chair will serve a term of 3 years. Simple is good. Regarding re-appointment: > [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 except that at the end of a second > consecutive term, the outgoing co-chair may not do so. this is well-worded. Nick From jim at rfc1035.com Sun Jan 11 16:31:32 2015 From: jim at rfc1035.com (Jim Reid) Date: Sun, 11 Jan 2015 15:31:32 +0000 Subject: [dns-wg] yet another heave on the WG Chair selection procedure In-Reply-To: <54AD93CD.8070509@foobar.org> References: <6C2679FD-69F8-4452-ADE9-93DF3E847AAA@rfc1035.com> <54AD93CD.8070509@foobar.org> Message-ID: <3D4A3538-7EB3-48AC-99B0-869684D72701@rfc1035.com> On 7 Jan 2015, at 20:15, Nick Hilliard wrote: > On 06/01/2015 12:41, Niall O'Reilly 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. > > This is also semantically non-deterministic in the case where the number of > co-chairs changes. It's not Nick. If the number of co-chairs changes, the term of office would be adjusted to reflect this. ie If/when 3 co-chairs drops to 2, what were the 3 year terms of the two remaining incumbents would automagically drop by a year. Likewise if we go from 2 to 3, the 2 year terms of the incumbents get extended by a year and the new stuckee slips into the gap that's just been created in the selection cycle. This is implicit from what was in the proposed text. Or should be. Now I suppose we could choose to write this up and spell it out in painstaking detail. But that seems to be overkill and/or shed painting. YMMV. That said your suggested [2] seems to be a cleaner and less verbose solution: > [2] Every second RIPE meeting, the co-chair who has been in that > position the longest will resign. If more than one co-chair qualifies > for resignation, then only one co-chair will be required to resign, as > determined by [drawing lots|some other appropriate means]. Though I'd prefer "once a year" to "every second RIPE meeting" in case the number of RIPE meetings per year changes or one of them gets cancelled say because the Kras catches fire. And while the selection process may well be aligned with a RIPE meeting, I would be very uncomfortable if that gave the impression that the meeting took precedence over the mailing list when it came to making the consensus decision. From nick at foobar.org Sun Jan 11 20:16:26 2015 From: nick at foobar.org (Nick Hilliard) Date: Sun, 11 Jan 2015 19:16:26 +0000 Subject: [dns-wg] yet another heave on the WG Chair selection procedure In-Reply-To: <3D4A3538-7EB3-48AC-99B0-869684D72701@rfc1035.com> References: <6C2679FD-69F8-4452-ADE9-93DF3E847AAA@rfc1035.com> <54AD93CD.8070509@foobar.org> <3D4A3538-7EB3-48AC-99B0-869684D72701@rfc1035.com> Message-ID: <54B2CC0A.4080906@foobar.org> On 11/01/2015 15:31, Jim Reid wrote: > Though I'd prefer "once a year" to "every second RIPE meeting" in case > the number of RIPE meetings per year changes or one of them gets > cancelled say because the Kras catches fire. And while the selection > process may well be aligned with a RIPE meeting, I would be very > uncomfortable if that gave the impression that the meeting took > precedence over the mailing list when it came to making the consensus > decision. I put some thought into this before committing to email. "Once a year" doesn't work either because if you have variations in the RIPE meeting dates (e.g. RIPE67 in mid-oct, RIPE69 in mid-nov), then "once a year" means that half of the time, you will need to move forward the selection slot at the DNS WG session to the previous RIPE meeting if you want to stay consistent with the selection procedure. There are many other ways to say this which will get around the problem, e.g. "at least once every 15 months" or "once in every calendar year, at a RIPE meeting, and in the second half of the year", and the qualify them by saying that if there were problems, that the selection process be held in the next scheduled RIPE meeting anyway. But it was fewer words and simpler to say "every second RIPE meeting". If the number of RIPE meeting changes, the protocol can be changed. If a RIPE meeting is unexpectedly cancelled or postponed, there will be bigger problems to deal with than this. Nick From jim at rfc1035.com Sun Jan 11 20:51:35 2015 From: jim at rfc1035.com (Jim Reid) Date: Sun, 11 Jan 2015 19:51:35 +0000 Subject: [dns-wg] yet another heave on the WG Chair selection procedure In-Reply-To: <54B2CC0A.4080906@foobar.org> References: <6C2679FD-69F8-4452-ADE9-93DF3E847AAA@rfc1035.com> <54AD93CD.8070509@foobar.org> <3D4A3538-7EB3-48AC-99B0-869684D72701@rfc1035.com> <54B2CC0A.4080906@foobar.org> Message-ID: On 11 Jan 2015, at 19:16, Nick Hilliard wrote: > But it was fewer words and simpler to say "every second RIPE meeting". "every calendar year" is even simpler and fewer words than that Nick. :-) I doubt it will matter or if anyone really cares when the selection process kicks in at some point during the year. Maybe it's Q1 one year and Q4 the next. So what? Or maybe the selection thing needs to be started earlier than normal because a co-chair resigns before their term's anniversary. I think that provided a selection event takes place at least once during a calendar year, it shouldn't matter when in that year that process is invoked. It's kind of like an AGM which usually can take place +/- 3 months from the previous one. From nick at foobar.org Sun Jan 11 23:31:32 2015 From: nick at foobar.org (Nick Hilliard) Date: Sun, 11 Jan 2015 22:31:32 +0000 Subject: [dns-wg] yet another heave on the WG Chair selection procedure In-Reply-To: References: <6C2679FD-69F8-4452-ADE9-93DF3E847AAA@rfc1035.com> <54AD93CD.8070509@foobar.org> <3D4A3538-7EB3-48AC-99B0-869684D72701@rfc1035.com> <54B2CC0A.4080906@foobar.org> Message-ID: <54B2F9C4.7050907@foobar.org> On 11/01/2015 19:51, Jim Reid wrote: > "every calendar year" is even simpler and fewer words than that Nick. :-) depends what you're looking for. If it's the simplest and fewest words, then you will probably want: [2] A co-chair will serve a term of N years. The main thing is that the wording should not be ambiguous. If you're going to go ahead with the other version, a decision needs to be made about how to decide who gets to resign. Again, the mechanism should be non-ambiguous. Drawing lots is one mechanism, but there are many others. Nick From benno at NLnetLabs.nl Tue Jan 13 15:01:14 2015 From: benno at NLnetLabs.nl (Benno Overeinder) Date: Tue, 13 Jan 2015 15:01:14 +0100 Subject: [dns-wg] Call For Presentations RIPE 70, submission deadline 1 March 2015 Message-ID: <54B5252A.2080106@NLnetLabs.nl> Dear colleagues, Please find the CFP for RIPE 70 below. The deadline for submissions is 1 March 2015. Please also note that speakers do not receive any extra reduction or funding towards the meeting fee at the RIPE Meetings. Kind regards, Benno Overeinder for the RIPE Programme Committee http://www.ripe.net/ripe/meetings/ripe-meetings/pc ---------------------------------------- Call for Presentations A RIPE Meeting is an open event where Internet Service Providers, network operators and other interested parties get together. Although the meeting is mostly technical, it is also a chance for people to meet and network with others in their field. RIPE 70 will take place from 11-15 May 2015 in Amsterdam, The Netherlands. The RIPE Programme Committee (PC) is now seeking content proposals from the RIPE community for the plenary session presentations, BoFs (Birds of a Feather sessions), panels, workshops, tutorials and lightning talks at RIPE 70. The PC is looking for presentations covering topics of network engineering and operations, including but not limited to: - IPv6 deployment - Managing IPv4 scarcity in operations - Commercial transactions of IPv4 addresses - Data centre technologies - Network and DNS operations - Internet governance and regulatory practices - Network and routing security - Content delivery - Internet peering and mobile data exchange Submissions RIPE Meeting attendees are quite sensitive to keeping presentations non-commercial, and product marketing talks are strongly discouraged. Repeated audience feedback shows that the most successful talks focus on operational experience, research results, or case studies. For example, presenters wishing to describe a commercial solution should focus on the underlying technology and not attempt a product demonstration. The RIPE PC accepts proposals for different presentation formats, including plenary session presentations, tutorials, workshops, BoFs (Birds of a Feather sessions) and lightning talks. See the full descriptions of these formats at https://ripe70.ripe.net/submit-topic/presentation-formats/ Presenters who are proposing a panel or BoF are encouraged to include speakers from several (perhaps even competing) companies and/or a neutral facilitator. In addition to presentations selected in advance for the plenary, the RIPE PC also offers several time slots for "lightning talks", which are selected immediately before or during the conference. The following general requirements apply: - Proposals for plenary session presentations, BoFs, panels, workshops and tutorials must be submitted for full consideration no later than 1 March 2015, using the meeting submission system at https://ripe70.ripe.net/submit-topic/submission-form/. Proposals submitted after this date will be considered on a space-available basis. Important Dates regarding RIPE 70 can be found at: https://ripe70.ripe.net/programme/important-dates/ - Lightning talks should also be submitted using the meeting submission system (https://ripe70.ripe.net/submit-topic/submission-form/) and can be submitted just days before the RIPE Meeting starts or even during the meeting week. The allocation of lightning talk slots will be announced in short notice ? in some cases on the same day but often one day prior to the relevant session. - Presenters should indicate how much time they will require. See more information on time slot allocations per presentation format at https://ripe70.ripe.net/submit-topic/presentation-formats/. - Proposals for talks will only be considered by the PC if they contain at least draft presentation slides (slides may be updated later on). For panels, proposals must contain a clear description, as well as the names of invited panellists, presenters and moderators. - Due to potential technical issues, it is expected that most, if not all, presenters/panellists will be physically present at the RIPE Meeting. If you have any questions or requests concerning content submissions, please email pc [at] ripe [dot] net. -- Benno J. Overeinder NLnet Labs http://www.nlnetlabs.nl/