From woody at pch.net Mon Sep 8 15:17:19 2014 From: woody at pch.net (Bill Woodcock) Date: Mon, 8 Sep 2014 06:17:19 -0700 Subject: [atlas] [ncc-services-wg] [dnsmon-user] The Beta Version of the New DNSMON is Now Available In-Reply-To: <201403191049.s2JAnv8p001190@bela.nlnetlabs.nl> References: <77BC1167-29D6-45C1-B380-7C67A8B49621@ripe.net> <532842DB.7000306@ripe.net> <201403191049.s2JAnv8p001190@bela.nlnetlabs.nl> Message-ID: <7240528F-AFA4-40F1-A7D9-FD7CA0BB5B0A@pch.net> Anything that can be done about the bad AS48294 probe, that doesn?t actually have IPv6 connectivity? Can you have it stop reporting its lack of IPv6 connectivity, or exclude it from results, or something? It makes it hard to see what?s going on in overview results, if it?s constantly adding to the floor of measurements it contributes to. Obviously, I?d prefer a generalized solution that applied to all such non-functional probes. Thanks. -Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PastedGraphic-2.png Type: image/png Size: 1023088 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mgalante at ripe.net Wed Sep 10 11:05:53 2014 From: mgalante at ripe.net (Michela Galante) Date: Wed, 10 Sep 2014 11:05:53 +0200 Subject: [atlas] DigitalOcean (SG) has joined RIPE Atlas anchors Message-ID: <008FE309-78DC-4BEE-B2B4-007D87E9BBF6@ripe.net> Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called sg-sin-as133165 and it is hosted by DigitalOcean in Singapore City, Singapore. Congratulations to DigitalOcean for their third anchor online! Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, Measurements Community Building Team RIPE NCC mcb at ripe.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2612 bytes Desc: not available URL: From s.eravuchira at jacobs-university.de Thu Sep 11 18:20:45 2014 From: s.eravuchira at jacobs-university.de (Eravuchira, Steffie Jacob) Date: Thu, 11 Sep 2014 16:20:45 +0000 Subject: [atlas] 'limit' filed in the probe API metadata Message-ID: <081E9415D79F9A469A4B6C79815FC09205C4B95D@SXCHMB01.jacobs.jacobs-university.de> Hello, In the REST API for RIPE Atlas probes [1], there is a metadata "limit" to set the number of items displayed in the API [2]. Previously I have used the "limit" field to get the details of all the registered probes (by specifying limit as the value in the field "total_count" in metadata) at once using this API. Now the API works well with values of "limit" up to 100. But for any value greater than 100, the limit is automatically set to 100. Could anyone help me understand why this could happen and how I can access the details of all the RIPE Atlas registered probes? [1] https://atlas.ripe.net/api/v1/probe [2] https://atlas.ripe.net/api/v1/probe/?limit=n Thank you in advance for the help. Regards, Steffie _________________________________________________________ Steffie Jacob Eravuchira Research I, Room 91 Computer Networks and Distributed Systems (CNDS) Lab School of Engineering and Sciences Jacobs University Bremen, Germany From mir at ripe.net Fri Sep 12 12:11:12 2014 From: mir at ripe.net (Mirjam Kuehne) Date: Fri, 12 Sep 2014 12:11:12 +0200 Subject: [atlas] New on RIPE Labs: RIPE Atlas Measurements with Tagged Probes coming soon In-Reply-To: <5412C6A0.2080001@ripe.net> References: <5412C6A0.2080001@ripe.net> Message-ID: <5412C6C0.30104@ripe.net> Dear colleagues, Please find a new article on RIPE Labs: RIPE Atlas: Measurements with Tagged Probes Coming Soon https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripe-atlas-measurements-with-tagged-probes-coming-soon If you have any comments or questions, please let us know. Kind regards, Mirjam Kuehne RIPE NCC From robert at ripe.net Fri Sep 12 12:23:02 2014 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 12 Sep 2014 12:23:02 +0200 Subject: [atlas] 'limit' filed in the probe API metadata In-Reply-To: <081E9415D79F9A469A4B6C79815FC09205C4B95D@SXCHMB01.jacobs.jacobs-university.de> References: <081E9415D79F9A469A4B6C79815FC09205C4B95D@SXCHMB01.jacobs.jacobs-university.de> Message-ID: <5412C986.7040508@ripe.net> Hello, On 2014.09.11. 18:20, Eravuchira, Steffie Jacob wrote: > > Hello, > > In the REST API for RIPE Atlas probes [1], there is a metadata "limit" > to set the number of items displayed in the API [2]. Previously I have > used the "limit" field to get the details of all the registered probes > (by specifying limit as the value in the field "total_count" in metadata) > at once using this API. > > Now the API works well with values of "limit" up to 100. But for any > value greater than 100, the limit is automatically set to 100. > > Could anyone help me understand why this could happen and how > I can access the details of all the RIPE Atlas registered probes? The limit has always been there in order to support pagination, it was just not enforced. Now it is. You can still flip through the pages presented -- it's trivial to construct the URL for the next page, but the response also contains a pointer for this. There's also the (newly announced) feature to access probe archives -- that may be a better approach, depending on your use case. Hope this helps, Robert > [1] https://atlas.ripe.net/api/v1/probe > [2] https://atlas.ripe.net/api/v1/probe/?limit=n > > > Thank you in advance for the help. > > Regards, > Steffie > _________________________________________________________ > > Steffie Jacob Eravuchira > Research I, Room 91 > Computer Networks and Distributed Systems (CNDS) Lab > School of Engineering and Sciences > Jacobs University Bremen, Germany > From vasil at ludost.net Fri Sep 12 13:42:52 2014 From: vasil at ludost.net (Vasil Kolev) Date: Fri, 12 Sep 2014 14:42:52 +0300 Subject: [atlas] New on RIPE Labs: RIPE Atlas Measurements with Tagged Probes coming soon In-Reply-To: <5412C6C0.30104@ripe.net> References: <5412C6A0.2080001@ripe.net> <5412C6C0.30104@ripe.net> Message-ID: <1410522172.4051.94.camel@nymphadora.home.ludost.net> ? 12:11 +0200 ?? 12.09.2014 (??), Mirjam Kuehne ??????: > Dear colleagues, > > Please find a new article on RIPE Labs: > > RIPE Atlas: Measurements with Tagged Probes Coming Soon > > https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripe-atlas-measurements-with-tagged-probes-coming-soon > > If you have any comments or questions, please let us know. Hi, I have a question on repeated/periodic measurements. Let's say I'm able to say "use 50 probes with tag 'anchor' and without tag 'ipv6 problems'". Would the set of probes update when the tags change? E.g. if a probe has a problem with ipv6, to be removed automatically from the list? I'm using this for monitoring purposes, e.g. linked in Icinga to see if my network's visibility drops, and currently there are a lot of false positives for ipv6. -- Regards, Vasil Kolev From mgalante at ripe.net Mon Sep 15 12:39:03 2014 From: mgalante at ripe.net (Michela Galante) Date: Mon, 15 Sep 2014 12:39:03 +0200 Subject: [atlas] SCT Schiele (DE) has joined RIPE Atlas anchors Message-ID: <0683BFA0-C400-498E-A943-FD04443EF832@ripe.net> Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called de-ett-as202040 and it is hosted by SCT Schiele GmbH in Ettlingen, Germany. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, Measurements Community Building Team RIPE NCC mcb at ripe.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2612 bytes Desc: not available URL: From robert at ripe.net Mon Sep 15 12:53:39 2014 From: robert at ripe.net (Robert Kisteleki) Date: Mon, 15 Sep 2014 12:53:39 +0200 Subject: [atlas] New on RIPE Labs: RIPE Atlas Measurements with Tagged Probes coming soon In-Reply-To: <1410522172.4051.94.camel@nymphadora.home.ludost.net> References: <5412C6A0.2080001@ripe.net> <5412C6C0.30104@ripe.net> <1410522172.4051.94.camel@nymphadora.home.ludost.net> Message-ID: <5416C533.3070302@ripe.net> Hello, > Hi, > > I have a question on repeated/periodic measurements. Let's say I'm able > to say "use 50 probes with tag 'anchor' and without tag 'ipv6 > problems'". Would the set of probes update when the tags change? E.g. if > a probe has a problem with ipv6, to be removed automatically from the > list? When you schedule a measurement, the system tries to find the best probes that match your criteria and involve them in your measurement. For now, this set of probes does not change over time automatically -- but you can ask for changes yourself. We have a feature on our roadmap to deal with situations where probes disappear over time, and do "something" about it: warn the user, replace with new probes, stop the measurement, ... The issue is that this, by definition, results in a change of probes over time, so interpreting the results becomes trickier. At the moment this feature is only planned to work with probes that disappear (ie. get unplugged), not when they change properties. That is even more difficult to do -- think about how to avoid flapping, for example. It would be useful to hear what other think about such features, so we can better understand what the user needs are. Regards, Robert From BECHA at ripe.net Mon Sep 15 17:51:57 2014 From: BECHA at ripe.net (Vesna Manojlovic) Date: Mon, 15 Sep 2014 17:51:57 +0200 Subject: [atlas] Seeking community feedback on draft RIPE Atlas Service Terms and Conditions Message-ID: <54170B1D.6090903@ripe.net> Dear colleagues, We have published a draft proposal for RIPE Atlas Service Terms and Conditions and are asking for community feedback on this, along with our proposed implementation plan. Please find more information on the MAT Working Group Mailing List, where we kindly ask you to direct any feedback you may have: https://www.ripe.net/ripe/mail/archives/mat-wg/2014-September/000489.html Regards, Vesna Manojlovic Senior Community Builder Measurements Community Building RIPE NCC From mgalante at ripe.net Tue Sep 16 09:55:47 2014 From: mgalante at ripe.net (Michela Galante) Date: Tue, 16 Sep 2014 09:55:47 +0200 Subject: [atlas] XS4ALL (NL) has joined RIPE Atlas anchors Message-ID: <97C6A35E-BC77-4E7B-A057-2E4C34DAEC27@ripe.net> Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called nl-ams-as3265 and it is hosted by XS4ALL in Amsterdam, Nederland. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, Measurements Community Building Team RIPE NCC mcb at ripe.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2612 bytes Desc: not available URL: From pvlaar at afilias.info Thu Sep 18 12:07:07 2014 From: pvlaar at afilias.info (Paul Vlaar) Date: Thu, 18 Sep 2014 12:07:07 +0200 Subject: [atlas] UDM limit? Message-ID: <541AAECB.9070601@afilias.info> Hi, I'm trying to add a UDM for one of our nameservers, however it appears others are already doing "too many measurements" for this server, as this is the message I get when I try to add my UDM: "10 UDMs are already measuring 199.19.54.1/2001:500:c::1. Cannot add 2 more" AFAIK I have no UDMs running for this server, so the mentioned UDMs are beyond my control to retract. Is it possible to find out who is running these UDMs so I can ask them to stop, or alter them in such a way that they match what I need in this UDM? It seems a bit odd to me that I can't do custom measurements on our server because others are already doing some. ~paul -- Paul Vlaar DNS Infrastructure Group Afilias e-mail: pvlaar at afilias.info phone: +1-416-673-4078 mobile DE: +49-1578-5742-695 mobile NL: +31-6-506-306-35 mobile USA: +1-602-410-4148 From pvlaar at afilias.info Thu Sep 18 12:13:53 2014 From: pvlaar at afilias.info (Paul Vlaar) Date: Thu, 18 Sep 2014 12:13:53 +0200 Subject: [atlas] UDM limit? In-Reply-To: <541AAECB.9070601@afilias.info> References: <541AAECB.9070601@afilias.info> Message-ID: <541AB061.8050900@afilias.info> On 18/9/14, 12:07 PM, Paul Vlaar wrote: > It seems a bit odd to me that I can't do custom measurements on our > server because others are already doing some. P.S. while I understand this is probably done to protect the server in question, I would like to see a better way to deal with this than just a "hard stop" at 10 measurements. Perhaps a way to negotiate a higher amount of UDMs possible for a given server? As it is now, this feels a like a DoS that is very easy to achieve. We've been getting more probes up recently, and we even ordered a RIPE Atlas Anchor box so that we can do a decent amount of UDMs on our own servers, but with this limitation in place, I'm fearing disappointment. Thanks, ~paul -- Paul Vlaar DNS Infrastructure Group Afilias e-mail: pvlaar at afilias.info phone: +1-416-673-4078 mobile DE: +49-1578-5742-695 mobile NL: +31-6-506-306-35 mobile USA: +1-602-410-4148 From jared at puck.nether.net Thu Sep 18 14:32:57 2014 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 18 Sep 2014 08:32:57 -0400 Subject: [atlas] UDM limit? In-Reply-To: <541AB061.8050900@afilias.info> References: <541AAECB.9070601@afilias.info> <541AB061.8050900@afilias.info> Message-ID: <4B4958C6-7858-467C-B875-D0CB9E9416C8@puck.nether.net> > On Sep 18, 2014, at 6:13 AM, Paul Vlaar wrote: > > On 18/9/14, 12:07 PM, Paul Vlaar wrote: >> It seems a bit odd to me that I can't do custom measurements on our >> server because others are already doing some. > > P.S. while I understand this is probably done to protect the server in > question, I would like to see a better way to deal with this than just a > "hard stop" at 10 measurements. Perhaps a way to negotiate a higher > amount of UDMs possible for a given server? As it is now, this feels a > like a DoS that is very easy to achieve. > > We've been getting more probes up recently, and we even ordered a RIPE > Atlas Anchor box so that we can do a decent amount of UDMs on our own > servers, but with this limitation in place, I'm fearing disappointment. There?s some tricks to work around this. The easiest is to have a DNS name that points at the IP, or the RIPE folk have been able to adjust the limit in the past. I have some anycasted IPs I asked them to increase the limit for. - Jared From robert at ripe.net Thu Sep 18 14:55:01 2014 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 18 Sep 2014 14:55:01 +0200 Subject: [atlas] UDM limit? In-Reply-To: <4B4958C6-7858-467C-B875-D0CB9E9416C8@puck.nether.net> References: <541AAECB.9070601@afilias.info> <541AB061.8050900@afilias.info> <4B4958C6-7858-467C-B875-D0CB9E9416C8@puck.nether.net> Message-ID: <541AD625.7040700@ripe.net> On 2014.09.18. 14:32, Jared Mauch wrote: > >> On Sep 18, 2014, at 6:13 AM, Paul Vlaar wrote: >> >> On 18/9/14, 12:07 PM, Paul Vlaar wrote: >>> It seems a bit odd to me that I can't do custom measurements on our >>> server because others are already doing some. >> >> P.S. while I understand this is probably done to protect the server in >> question, I would like to see a better way to deal with this than just a >> "hard stop" at 10 measurements. Perhaps a way to negotiate a higher >> amount of UDMs possible for a given server? As it is now, this feels a >> like a DoS that is very easy to achieve. >> >> We've been getting more probes up recently, and we even ordered a RIPE >> Atlas Anchor box so that we can do a decent amount of UDMs on our own >> servers, but with this limitation in place, I'm fearing disappointment. > > There?s some tricks to work around this. The easiest is to have a DNS name that points at the IP, or the RIPE folk have been able to adjust the limit in the past. I have some anycasted IPs I asked them to increase the limit for. Hi, We have a system-wide setting for "no more than X ongoing measurements against the same target", where X=10 now. One can argue that 10 should be 20 (or a 100, 1000, ...) but there has to be something there. We can make exceptions on this per user. It'd be pretty difficult to administer quotas per target. Instead, our line of thinking at the moment is: * to separate the one-offs from the ongoing measurements; ie. there should be X one-off and X ongoing slots. This would allow users to do ad-hoc measurements even if the destination is otherwise well-measured * to switch to a model where we calculate the expected load on the target, like probes*frequency/time_interval, instead of pure number of measurements (which can have 1..10..100.1000 probes). In this model one could start a new measurement against a target even if there are a 1000 running already, as long as those measurements are not too heavy Let us know what you think about these scenarios! Cheers, Robert From gert at space.net Thu Sep 18 15:04:27 2014 From: gert at space.net (Gert Doering) Date: Thu, 18 Sep 2014 15:04:27 +0200 Subject: [atlas] UDM limit? In-Reply-To: <541AD625.7040700@ripe.net> References: <541AAECB.9070601@afilias.info> <541AB061.8050900@afilias.info> <4B4958C6-7858-467C-B875-D0CB9E9416C8@puck.nether.net> <541AD625.7040700@ripe.net> Message-ID: <20140918130427.GJ14459@Space.Net> Hi, On Thu, Sep 18, 2014 at 02:55:01PM +0200, Robert Kisteleki wrote: > It'd be pretty difficult to administer quotas per target. Instead, our line > of thinking at the moment is: > * to separate the one-offs from the ongoing measurements; ie. there should > be X one-off and X ongoing slots. This would allow users to do ad-hoc > measurements even if the destination is otherwise well-measured > * to switch to a model where we calculate the expected load on the target, > like probes*frequency/time_interval, instead of pure number of measurements > (which can have 1..10..100.1000 probes). In this model one could start a new > measurement against a target even if there are a 1000 running already, as > long as those measurements are not too heavy I think both models are useful :-) - one-off and ongoing to have separate quotas, and changing the actual quota calculation to some (obviously arbitrary) "packets per minute" number or such. Higher ppm values for well-known targets, like "all anchors", that signal their willingness to receive packets. Gert -- 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 pvlaar at afilias.info Thu Sep 18 21:43:29 2014 From: pvlaar at afilias.info (Paul Vlaar) Date: Thu, 18 Sep 2014 21:43:29 +0200 Subject: [atlas] UDM limit? In-Reply-To: <4B4958C6-7858-467C-B875-D0CB9E9416C8@puck.nether.net> References: <541AAECB.9070601@afilias.info> <541AB061.8050900@afilias.info> <4B4958C6-7858-467C-B875-D0CB9E9416C8@puck.nether.net> Message-ID: <541B35E1.8020801@afilias.info> On 18/9/14, 2:32 PM, Jared Mauch wrote: > the RIPE folk have been able to adjust the limit in the past. I have > some anycasted IPs I asked them to increase the limit for. This would be great if it can also be done for us. We're also talking about very solidly represented anycasted IPs here and it would be fine if the limit is raised to 100. Robert, should I contact you directly about this? ~paul -- Paul Vlaar DNS Infrastructure Group Afilias e-mail: pvlaar at afilias.info phone: +1-416-673-4078 mobile DE: +49-1578-5742-695 mobile NL: +31-6-506-306-35 mobile USA: +1-602-410-4148 From pvlaar at afilias.info Thu Sep 18 21:49:32 2014 From: pvlaar at afilias.info (Paul Vlaar) Date: Thu, 18 Sep 2014 21:49:32 +0200 Subject: [atlas] UDM limit? In-Reply-To: <541AD625.7040700@ripe.net> References: <541AAECB.9070601@afilias.info> <541AB061.8050900@afilias.info> <4B4958C6-7858-467C-B875-D0CB9E9416C8@puck.nether.net> <541AD625.7040700@ripe.net> Message-ID: <541B374C.1090205@afilias.info> On 18/9/14, 2:55 PM, Robert Kisteleki wrote: > It'd be pretty difficult to administer quotas per target. Instead, our line > of thinking at the moment is: > * to separate the one-offs from the ongoing measurements; ie. there should > be X one-off and X ongoing slots. This would allow users to do ad-hoc > measurements even if the destination is otherwise well-measured In this particular case, this would not suffice, since I'm trying to setup new ongoing measurements. 2 per IP, actually, for 4 IPs. It looks like they are all maxed out. This wasn't the case a month ago. > * to switch to a model where we calculate the expected load on the target, > like probes*frequency/time_interval, instead of pure number of measurements > (which can have 1..10..100.1000 probes). In this model one could start a new > measurement against a target even if there are a 1000 running already, as > long as those measurements are not too heavy Still, this would not address the fact that some IPs will simply always receive more measurements than others as they are more "popular". It just so happens that our IPs in question are okay to be measured more than others, as they are anycasted and have many servers running this IP. So I'm not worried about "over-measuring", and would prefer to have the limit raised on these. If we can prove ownership of these IPs, then perhaps this is something that can be done. Jared seems to have had luck in getting the NCC to raise the limit for individual IPs. ~paul -- Paul Vlaar DNS Infrastructure Group Afilias e-mail: pvlaar at afilias.info phone: +1-416-673-4078 mobile DE: +49-1578-5742-695 mobile NL: +31-6-506-306-35 mobile USA: +1-602-410-4148 From BECHA at ripe.net Thu Sep 25 09:13:27 2014 From: BECHA at ripe.net (Vesna Manojlovic) Date: Thu, 25 Sep 2014 09:13:27 +0200 Subject: [atlas] Fwd: Final Call For Presentations RIPE 69, deadline 1 October 2014 In-Reply-To: <54233964.3080005@NLnetLabs.nl> References: <54233964.3080005@NLnetLabs.nl> Message-ID: <5423C097.4050406@ripe.net> Dear colleagues, RIPE69 is approaching. If you would like to present to the whole plenary on RIPE Atlas, the deadline is soon. If you prefer to talk on MAT-WG, please approach the chairs directly: mat-wg-chairs at ripe.net Regards, Vesna -------- Original Message -------- Date: Wed, 24 Sep 2014 23:36:36 +0200 From: Benno Overeinder Dear colleagues, Following the past submission deadline, there is a Draft RIPE Plenary programme published at: https://ripe69.ripe.net/programme/meeting-plan/plenary/ There are still slots remaining for the final RIPE 69 programme and RIPE Programme Committee will accept new proposals until 1 October 2014. This is a last call deadline if you wish to submit a proposal. Kind regards, Benno Overeinder for RIPE programme committee On 27/08/14 13:33, Benno Overeinder wrote: > Dear colleagues, > > Please find the CFP for RIPE 69 in London below. > > The deadline for submissions is 31 August 2014. > > Please also note that speakers do not receive any extra reduction or > funding towards the meeting fee at the RIPE Meetings. > > Kind regards, > > RIPE PC > 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 69 will take place from 3-7 November 2014 in London, UK. > > 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 69. 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://ripe69.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 > 31 August 2014, using the meeting submission system at > https://ripe69.ripe.net/submit-topic/guidelines/. Proposals > submitted after this date will be considered on a space-available > basis. > > - Lightning talks should also be submitted using the meeting submission > system (https://ripe69.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://ripe69.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/