From robert at ripe.net Wed Mar 5 10:54:19 2014 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 05 Mar 2014 10:54:19 +0100 Subject: [atlas] New on RIPE Labs: The Seismograph User Guide In-Reply-To: <9D7ACB0A-EDD1-4350-B31E-03308FACBFFC@ripe.net> References: <9D7ACB0A-EDD1-4350-B31E-03308FACBFFC@ripe.net> Message-ID: <5316F44B.5080807@ripe.net> On 2014.02.12. 10:02, Suzanne Taylor Muzzin wrote: > Dear colleagues, > > Please find a new article on RIPE Labs that explains how you can get the most out of the Seismograph, an interactive RIPE Atlas tool that provides an overview of different RTT and packet loss trends measured by multiple probes. > > The Seismograph User Guide > https://labs.ripe.net/Members/massimo_candela/seismograph-user-guide > > Kind regards, > > Suzanne Taylor Muzzin > Measurements Community Building > RIPE NCC Dear colleagues, The above article reiterated our previous communication about decommissioning the RRD style ping visualisations: "The Seismograph is the new way to visualise ping user-defined measurements within RIPE Atlas, and is meant to replace the old ping visualisations (under the RRDs tab), which we will decommission at the end of February 2014." Based on this, we began to remove the old graphs. Regards, Robert From dquinn at ripe.net Wed Mar 5 13:45:57 2014 From: dquinn at ripe.net (Daniel Quinn) Date: Wed, 05 Mar 2014 12:45:57 +0000 Subject: [atlas] New on RIPE Labs: Improved RIPE Atlas Probe Pages In-Reply-To: <5310519F.30001@ripe.net> References: <53105176.4070904@ripe.net> <5310519F.30001@ripe.net> Message-ID: <53171C85.4020702@ripe.net> Dear colleagues, As Mirjam announced late last week, we've created a new interface for probe information on RIPE Atlas. Today we've set this as the default, so when you navigate to "My Atlas > Probes", you will get the new interface in place of the old one. You can read more about the new layout on RIPE Labs: https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripe-atlas-improved-probe-pages or just visit the pages yourself when you have some time: https://atlas.ripe.net/probes/ From BECHA at ripe.net Wed Mar 5 13:59:01 2014 From: BECHA at ripe.net (Vesna Manojlovic) Date: Wed, 05 Mar 2014 13:59:01 +0100 Subject: [atlas] ISC / PAIX (US) has joined RIPE Atlas anchors In-Reply-To: References: Message-ID: <53171F95.5000704@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 us-pao-as1280 and it is hosted by ISC at PAIX in Palo Alto, CA, United States, on behalf of RIPE NCC since they are one of our RIS Remote Route Collector locations. Congratulations, ISC - you are the anchor number 42! (this have some special significance.... http://www.urbandictionary.com/define.php?term=42 ) 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: Screen Shot 2014-03-05 at 13.47.15.png Type: image/png Size: 15786 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2014-03-05 at 13.56.57.png Type: image/png Size: 101780 bytes Desc: not available URL: From mgalante at ripe.net Mon Mar 10 12:33:40 2014 From: mgalante at ripe.net (Michela Galante) Date: Mon, 10 Mar 2014 12:33:40 +0100 Subject: [atlas] Mail.ru Group (RU) has joined RIPE Atlas anchors Message-ID: 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 ru-mow-as47764 and it is hosted by Mail.ru Group in Moscow, Russia. Congratulations to Mail.ru Group! This is the first anchor in Russia. 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: 2626 bytes Desc: not available URL: From marco.davids at sidn.nl Tue Mar 11 10:51:57 2014 From: marco.davids at sidn.nl (Marco Davids (SIDN)) Date: Tue, 11 Mar 2014 10:51:57 +0100 Subject: [atlas] Probe management Message-ID: <531EDCBD.5020106@sidn.nl> Hi, In the 'general information' tab of our probe I noticed a section 'management sharing', with our regID as a group that apparently has 'shared administration' rights. My question: is it possible to add some of my colleagues to that group, so that they have access to the probe as well? Seems like a better thing to do than handing out my LIR-credentials... Cheers, -- Marco -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4225 bytes Desc: S/MIME Cryptographic Signature URL: From BECHA at ripe.net Tue Mar 11 11:17:35 2014 From: BECHA at ripe.net (Vesna Manojlovic) Date: Tue, 11 Mar 2014 11:17:35 +0100 Subject: [atlas] Encouraging RIPE Atlas users to choose for public probes and measurements In-Reply-To: <531ED0C2.1090108@ripe.net> References: <531ED0C2.1090108@ripe.net> Message-ID: <531EE2BF.7020505@ripe.net> Dear colleagues, One of the main goals of RIPE Atlas is to share information about Internet performance, which we collect via the active measurements performed by the thousands of probes in the RIPE Atlas network. In order to better achieve that goal, last year we suggested making even more of the collected data public. You can read the full details of this proposal on RIPE Labs: https://labs.ripe.net/Members/becha/proposing-making-ripe-atlas-data-more-public We asked for feedback about this proposal from the RIPE Atlas community and, based on that feedback, we have decided not to go ahead with the proposal or make any major changes to the system. We would therefore like to revise our original proposal and suggest the following, revised plan: 1. We will strongly encourage RIPE Atlas users to keep their RIPE Atlas probes public and to perform public measurements as much as possible by: - Making new probes public by default (opt-out available) whenever someone applies for a new probe - Checking the public option by default when using the web interface to create user-defined measurements - Rewarding those who make their probes and measurements public by giving them more credits than those who don?t - Requiring all research enabled by special credits to produce public measurement results - Stressing the public nature of RIPE Atlas as a measurements platform in the RIPE NCC's publications and outreach 2. We will continue to allow users to *not* mark their probes public and to schedule user-defined measurements that are not public. 3. We will improve the documentation in order to clarify exactly what information is available for probes and user-defined measurements that are marked public versus those not marked public. Because this revised plan does not involve making any significant changes to our procedures or interfaces, the implementation would take place during our regular deployment cycle. We are basing this revised plan on the reactions of the 13 RIPE Atlas users who provided feedback after we proposed our original plan (you can find more details about the feedback we received below). We would like to hear from more of you, even if you just confirm that you agree with this revised proposal. Regards, Vesna Manojlovic Senior Community Builder for Measurements Tools RIPE NCC Summary of the feedback (the original comments can also be found on the RIPE Atlas mailing list archives): Eleven people replied on the mailing list and two replied on RIPE Labs, with some people supporting more than one option. - Three people supported making the data more public - Six people supported keeping things the same (i.e. against removing the "not public" option) - One person suggested making the data less public - Three people suggested delaying the publication of the public results (a new suggestion) - One person was completely neutral Specific comments included: - Making the data public by default is okay, but leave the option to not make it public - If a delay in making the data public is introduced, one-off measurements should be excluded - A delay in making the data public will introduce more complexity to the system - A proposal to receive extra/fewer credits for making probes and measurements public/not public, respectively From robert at ripe.net Tue Mar 11 13:57:06 2014 From: robert at ripe.net (Robert Kisteleki) Date: Tue, 11 Mar 2014 13:57:06 +0100 Subject: [atlas] Probe management In-Reply-To: <531EDCBD.5020106@sidn.nl> References: <531EDCBD.5020106@sidn.nl> Message-ID: <531F0822.3060404@ripe.net> Hi, On 2014.03.11. 10:51, Marco Davids (SIDN) wrote: > Hi, > > In the 'general information' tab of our probe I noticed a section > 'management sharing', with our regID as a group that apparently has > 'shared administration' rights. > > My question: is it possible to add some of my colleagues to that group, > so that they have access to the probe as well? Seems like a better thing > to do than handing out my LIR-credentials... > > Cheers, This function covers your co-worked in the same LIR (RIPE NCC member). We don't have support for ad hoc groups at the moment. We've heard some users asking for such random grouping, but so far there was no significant demand for this. Regards, Robert From fearghas at gmail.com Tue Mar 11 13:59:33 2014 From: fearghas at gmail.com (Fearghas McKay) Date: Tue, 11 Mar 2014 13:59:33 +0100 Subject: [atlas] Probe management In-Reply-To: <531F0822.3060404@ripe.net> References: <531EDCBD.5020106@sidn.nl> <531F0822.3060404@ripe.net> Message-ID: <2597A208-FDD9-409D-9D6F-A579E1E0973D@gmail.com> On 11 Mar 2014, at 13:57, Robert Kisteleki wrote: > We've heard some users > asking for such random grouping, but so far there was no significant demand > for this. So how many would be significant ? Perhaps a straw/doodle poll to guage interest ? f From brak at gameservers.com Tue Mar 11 15:09:40 2014 From: brak at gameservers.com (Brian Rak) Date: Tue, 11 Mar 2014 10:09:40 -0400 Subject: [atlas] Encouraging RIPE Atlas users to choose for public probes and measurements In-Reply-To: <531EE2BF.7020505@ripe.net> References: <531ED0C2.1090108@ripe.net> <531EE2BF.7020505@ripe.net> Message-ID: <531F1924.7060609@gameservers.com> Are there plans to make the data accessible without requiring a login? Currently, it's tough for me to share measurements with people, because most of us don't have RIPE accounts (since we're primarily located in the ARIN region). On 3/11/2014 6:17 AM, Vesna Manojlovic wrote: > Dear colleagues, > > One of the main goals of RIPE Atlas is to share information about > Internet performance, which we collect via the active measurements > performed by the thousands of probes in the RIPE Atlas network. > In order to better achieve that goal, last year we suggested making > even more of the collected data public. You can read the full details > of this proposal on RIPE Labs: > > https://labs.ripe.net/Members/becha/proposing-making-ripe-atlas-data-more-public > > > We asked for feedback about this proposal from the RIPE Atlas community > and, based on that feedback, we have decided not to go ahead with the > proposal or make any major changes to the system. > > We would therefore like to revise our original proposal and suggest the > following, revised plan: > > 1. We will strongly encourage RIPE Atlas users to keep their RIPE Atlas > probes public and to perform public measurements as much as possible by: > > - Making new probes public by default (opt-out available) whenever > someone applies for a new probe > - Checking the public option by default when using the web interface to > create user-defined measurements > - Rewarding those who make their probes and measurements public by > giving them more credits than those who don?t > - Requiring all research enabled by special credits to produce public > measurement results > - Stressing the public nature of RIPE Atlas as a measurements platform > in the RIPE NCC's publications and outreach > > 2. We will continue to allow users to *not* mark their probes public and > to schedule user-defined measurements that are not public. > > 3. We will improve the documentation in order to clarify exactly what > information is available for probes and user-defined measurements that > are marked public versus those not marked public. > > Because this revised plan does not involve making any significant > changes to our procedures or interfaces, the implementation would take > place during our regular deployment cycle. > > We are basing this revised plan on the reactions of the 13 RIPE Atlas > users who provided feedback after we proposed our original plan (you > can find more details about the feedback we received below). > > We would like to hear from more of you, even if you just confirm that > you agree with this revised proposal. > > Regards, > > Vesna Manojlovic > Senior Community Builder for Measurements Tools > RIPE NCC > > Summary of the feedback > (the original comments can also be found on the RIPE Atlas mailing list > archives): > > Eleven people replied on the mailing list and two replied on RIPE Labs, > with some people supporting more than one option. > > - Three people supported making the data more public > - Six people supported keeping things the same (i.e. against removing > the "not public" option) > - One person suggested making the data less public > - Three people suggested delaying the publication of the public results > (a new suggestion) > - One person was completely neutral > > Specific comments included: > > - Making the data public by default is okay, but leave the option to > not make it public > - If a delay in making the data public is introduced, one-off > measurements should be excluded > - A delay in making the data public will introduce more complexity to > the system > - A proposal to receive extra/fewer credits for making probes and > measurements public/not public, respectively > > > > > > > > > From the.lists at mgm51.com Tue Mar 11 15:55:20 2014 From: the.lists at mgm51.com (Mike.) Date: Tue, 11 Mar 2014 10:55:20 -0400 Subject: [atlas] Encouraging RIPE Atlas users to choose for public probes and measurements In-Reply-To: <531F1924.7060609@gameservers.com> References: <531ED0C2.1090108@ripe.net> <531EE2BF.7020505@ripe.net> <531F1924.7060609@gameservers.com> Message-ID: <201403111055200944.007360F6@smtp.24cl.home> |On 3/11/2014 6:17 AM, Vesna Manojlovic wrote: |> Dear colleagues, |> |> One of the main goals of RIPE Atlas is to share information about |> Internet performance, which we collect via the active measurements |> performed by the thousands of probes in the RIPE Atlas network. |> In order to better achieve that goal, last year we suggested making |> even more of the collected data public. You can read the full details |> of this proposal on RIPE Labs: |> |>[big snip] When I click on the My measurements tab, I am presented with a grid of my measurements. When I click on one of those measurements, I land on a summary page for that measurement. When I look at that summary page, whether the measurement is or is not public is not shown. I have to click on the Settings icon in the top right corner to access that information. Upon doing so, I found that one of my measurements was not public, and I corrected that. Suggestion: might it be possible to show the public status (i.e., yes/no) of my measurements on the summary page for those measurements? Thanks. From the.lists at mgm51.com Tue Mar 11 15:57:37 2014 From: the.lists at mgm51.com (Mike.) Date: Tue, 11 Mar 2014 10:57:37 -0400 Subject: [atlas] Encouraging RIPE Atlas users to choose for public probes and measurements In-Reply-To: <201403111055200944.007360F6@smtp.24cl.home> References: <531ED0C2.1090108@ripe.net> <531EE2BF.7020505@ripe.net> <531F1924.7060609@gameservers.com> <201403111055200944.007360F6@smtp.24cl.home> Message-ID: <201403111057370919.0075780E@smtp.24cl.home> On 3/11/2014 at 10:55 AM Mike. wrote: ||On 3/11/2014 6:17 AM, Vesna Manojlovic wrote: ||> Dear colleagues, ||> ||> One of the main goals of RIPE Atlas is to share information about ||> Internet performance, which we collect via the active measurements ||> performed by the thousands of probes in the RIPE Atlas network. ||> In order to better achieve that goal, last year we suggested |making ||> even more of the collected data public. You can read the full |details ||> of this proposal on RIPE Labs: ||> ||>[big snip] | | |When I click on the My measurements tab, I am presented with a grid |of my measurements. When I click on one of those measurements, I |land on a summary page for that measurement. When I look at that |summary page, whether the measurement is or is not public is not |shown. I have to click on the Settings icon in the top right corner |to access that information. | |Upon doing so, I found that one of my measurements was not public, |and I corrected that. | |Suggestion: might it be possible to show the public status (i.e., |yes/no) of my measurements on the summary page for those |measurements? | | |Thanks. ============= I forgot to add, the amended proposal sounds fine to me. From robert at ripe.net Tue Mar 11 16:00:28 2014 From: robert at ripe.net (Robert Kisteleki) Date: Tue, 11 Mar 2014 16:00:28 +0100 Subject: [atlas] Encouraging RIPE Atlas users to choose for public probes and measurements In-Reply-To: <201403111055200944.007360F6@smtp.24cl.home> References: <531ED0C2.1090108@ripe.net> <531EE2BF.7020505@ripe.net> <531F1924.7060609@gameservers.com> <201403111055200944.007360F6@smtp.24cl.home> Message-ID: <531F250C.8090001@ripe.net> > Suggestion: might it be possible to show the public status (i.e., > yes/no) of my measurements on the summary page for those > measurements? Yes, of course! Robert From sebastian at nzrs.net.nz Tue Mar 11 21:41:42 2014 From: sebastian at nzrs.net.nz (Sebastian Castro) Date: Wed, 12 Mar 2014 09:41:42 +1300 Subject: [atlas] Searching for public measurements Message-ID: <531F7506.20701@nzrs.net.nz> Hi: I want to search for specific public measurements for hosts that are most likely be monitored at this point. Is there are way to do this using the web interface, or I should try to fetch all public measurement ids and do the grinding myself? Considering there are more than 560,000 public measurements, getting all the ids doesn't sound like a good idea. Cheers, -- Sebastian Castro Technical Research Manager .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 495 2337 mobile: +64 21 400535 From benc at hawaga.org.uk Wed Mar 12 01:01:08 2014 From: benc at hawaga.org.uk (Ben Clifford) Date: Wed, 12 Mar 2014 00:01:08 +0000 (UTC) Subject: [atlas] Encouraging RIPE Atlas users to choose for public probes and measurements In-Reply-To: <531F1924.7060609@gameservers.com> References: <531ED0C2.1090108@ripe.net> <531EE2BF.7020505@ripe.net> <531F1924.7060609@gameservers.com> Message-ID: This has also annoyed me in the past - I've chosen to make some stuff public but it isn't public enough. On Tue, 11 Mar 2014, Brian Rak wrote: > Are there plans to make the data accessible without requiring a login? > Currently, it's tough for me to share measurements with people, because > most of us don't have RIPE accounts (since we're primarily located in > the ARIN region). > > > On 3/11/2014 6:17 AM, Vesna Manojlovic wrote: > > Dear colleagues, > > > > One of the main goals of RIPE Atlas is to share information about > > Internet performance, which we collect via the active measurements > > performed by the thousands of probes in the RIPE Atlas network. > > In order to better achieve that goal, last year we suggested making > > even more of the collected data public. You can read the full details > > of this proposal on RIPE Labs: > > > > https://labs.ripe.net/Members/becha/proposing-making-ripe-atlas-data-more-public > > > > We asked for feedback about this proposal from the RIPE Atlas > > community > > and, based on that feedback, we have decided not to go ahead with the > > proposal or make any major changes to the system. > > > > We would therefore like to revise our original proposal and suggest > > the > > following, revised plan: > > > > 1. We will strongly encourage RIPE Atlas users to keep their RIPE > > Atlas > > probes public and to perform public measurements as much as possible > > by: > > > > - Making new probes public by default (opt-out available) whenever > > someone applies for a new probe > > - Checking the public option by default when using the web interface > > to > > create user-defined measurements > > - Rewarding those who make their probes and measurements public by > > giving them more credits than those who don?t > > - Requiring all research enabled by special credits to produce public > > measurement results > > - Stressing the public nature of RIPE Atlas as a measurements platform > > in the RIPE NCC's publications and outreach > > > > 2. We will continue to allow users to *not* mark their probes public > > and > > to schedule user-defined measurements that are not public. > > > > 3. We will improve the documentation in order to clarify exactly what > > information is available for probes and user-defined measurements that > > are marked public versus those not marked public. > > > > Because this revised plan does not involve making any significant > > changes to our procedures or interfaces, the implementation would take > > place during our regular deployment cycle. > > > > We are basing this revised plan on the reactions of the 13 RIPE Atlas > > users who provided feedback after we proposed our original plan (you > > can find more details about the feedback we received below). > > > > We would like to hear from more of you, even if you just confirm that > > you agree with this revised proposal. > > > > Regards, > > > > Vesna Manojlovic > > Senior Community Builder for Measurements Tools > > RIPE NCC > > > > Summary of the feedback > > (the original comments can also be found on the RIPE Atlas mailing > > list > > archives): > > > > Eleven people replied on the mailing list and two replied on RIPE > > Labs, > > with some people supporting more than one option. > > > > - Three people supported making the data more public > > - Six people supported keeping things the same (i.e. against removing > > the "not public" option) > > - One person suggested making the data less public > > - Three people suggested delaying the publication of the public > > results > > (a new suggestion) > > - One person was completely neutral > > > > Specific comments included: > > > > - Making the data public by default is okay, but leave the option to > > not make it public > > - If a delay in making the data public is introduced, one-off > > measurements should be excluded > > - A delay in making the data public will introduce more complexity to > > the system > > - A proposal to receive extra/fewer credits for making probes and > > measurements public/not public, respectively > > > > > > > > > > > > > > > > > > > > > From dquinn at ripe.net Wed Mar 12 11:06:19 2014 From: dquinn at ripe.net (Daniel Quinn) Date: Wed, 12 Mar 2014 10:06:19 +0000 Subject: [atlas] Searching for public measurements In-Reply-To: <531F7506.20701@nzrs.net.nz> References: <531F7506.20701@nzrs.net.nz> Message-ID: <5320319B.4040604@ripe.net> I'm having a little trouble understanding what it is you want to search for exactly, but you should know that the measurement listing page has the ability to filter by target (among a few other things as well). Just click on the arrow next to the "Target" column header, go down to "Filter >" and type in what you're searching for. If that is insufficient for you, let me know off-list and maybe I can help you out further. From willem at nlnetlabs.nl Wed Mar 12 11:14:18 2014 From: willem at nlnetlabs.nl (Willem Toorop) Date: Wed, 12 Mar 2014 11:14:18 +0100 Subject: [atlas] Is "Prepend probe's ID" checkbox working? Message-ID: <5320337A.1020703@nlnetlabs.nl> Hi, In the web-interface DNS UDM, there is checkbox "Prepend probe's ID". Is this working already? Where does it prepend the ID? I expected it to prepend to the query name (i.e. Argument), but I couldn't see it working. Regards, -- Willem From astrikos at ripe.net Wed Mar 12 11:24:29 2014 From: astrikos at ripe.net (Andreas Strikos) Date: Wed, 12 Mar 2014 11:24:29 +0100 Subject: [atlas] Is "Prepend probe's ID" checkbox working? In-Reply-To: <5320337A.1020703@nlnetlabs.nl> References: <5320337A.1020703@nlnetlabs.nl> Message-ID: <532035DD.9070003@ripe.net> On 3/12/14, 11:14 AM, Willem Toorop wrote: > Hi, > > In the web-interface DNS UDM, there is checkbox "Prepend probe's ID". > Is this working already? Where does it prepend the ID? I expected it > to prepend to the query name (i.e. Argument), but I couldn't see it working. > Regards, > > -- Willem > Hi Willem, There is a bug in the web-interface for this option indeed. It will go away with today's release though. In the meantime you can use the API, it should work there (option is "prepend_probe_id") Regards, Andreas From willem at nlnetlabs.nl Wed Mar 12 11:42:30 2014 From: willem at nlnetlabs.nl (Willem Toorop) Date: Wed, 12 Mar 2014 11:42:30 +0100 Subject: [atlas] Is "Prepend probe's ID" checkbox working? In-Reply-To: <532035DD.9070003@ripe.net> References: <5320337A.1020703@nlnetlabs.nl> <532035DD.9070003@ripe.net> Message-ID: <53203A16.7090304@nlnetlabs.nl> Wow! Not only the probe's ID but also a timestamp. Excellent. I'm happy. Thank you! -- Willem op 12-03-14 11:24, Andreas Strikos schreef: > On 3/12/14, 11:14 AM, Willem Toorop wrote: >> Hi, >> >> In the web-interface DNS UDM, there is checkbox "Prepend probe's ID". >> Is this working already? Where does it prepend the ID? I expected it >> to prepend to the query name (i.e. Argument), but I couldn't see it >> working. >> Regards, >> >> -- Willem >> > Hi Willem, > > There is a bug in the web-interface for this option indeed. It will go > away with today's release though. > In the meantime you can use the API, it should work there (option is > "prepend_probe_id") > > > Regards, > Andreas From BECHA at ripe.net Wed Mar 12 13:00:35 2014 From: BECHA at ripe.net (Vesna Manojlovic) Date: Wed, 12 Mar 2014 13:00:35 +0100 Subject: [atlas] Research papers for IMC or other measurements conferences Message-ID: <53204C63.5020401@ripe.net> Dear colleagues, a couple of researchers using RIPE Atlas brought this conference to my attention, and I noticed that the CFP deadline is approaching fast. I would be curious to hear if anyone else is planning to submit a paper based on RIPE Atlas data to IMC, or any other conference. Please let me know if you need some extra help from us: more credits, higher limits for usage of probes per measurements, or additional text for your paper. We would be grateful for your mention of the RIPE NCC and RIPE Atlas in your paper, and would like to invite you to share your results, after the conference, with RIPE community, either by presenting at RIPE meetings or publishing on RIPE Labs. Regards, Vesna IMC Details: http://conferences2.sigcomm.org/imc/2014/ The 2014 Internet Measurement Conference (IMC) is a three-day event focusing on Internet measurement and analysis. The conference is sponsored jointly by ACM SIGCOMM and ACM SIGMETRICS. IMC 2014 is the 14th in a series of highly successful Internet Measurement Workshops and Conferences. The ACM IMC 2014 conference will be held in Vancouver, BC, Canada on November 5-7, 2014. Call for papers deadline: 30 April http://conferences2.sigcomm.org/imc/2014/cfp.html From mgalante at ripe.net Wed Mar 12 13:57:37 2014 From: mgalante at ripe.net (Michela Galante) Date: Wed, 12 Mar 2014 13:57:37 +0100 Subject: [atlas] Blacknight Internet Solutions Ltd (IE) has joined RIPE Atlas anchors Message-ID: <1CE1DB40-6933-4E09-BA87-305587D3684A@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 ie-caw-as39122 and it is hosted by Blacknight Internet Solutions Ltd in Carlow, Ireland. 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: 2626 bytes Desc: not available URL: From laurent at laurent-wattieaux.com Wed Mar 12 17:02:10 2014 From: laurent at laurent-wattieaux.com (Laurent Wattieaux) Date: Wed, 12 Mar 2014 17:02:10 +0100 Subject: [atlas] Encouraging RIPE Atlas users to choose for public probes and measurements In-Reply-To: <531EE2BF.7020505@ripe.net> References: <531ED0C2.1090108@ripe.net> <531EE2BF.7020505@ripe.net> Message-ID: <53208502.1010807@laurent-wattieaux.com> Hi, I agree with this revised proposal. "Encourage RIPE Atlas users to keep their RIPE Atlas probes public and to perform public measurements" is _very important_. "Allowing users to schedule" _some_ "user-defined measurements that are not public" is interesting. -- *Laurent Wattieaux*. -------------- next part -------------- An HTML attachment was scrubbed... URL: From max+ratlml at grobecker.info Thu Mar 13 00:02:10 2014 From: max+ratlml at grobecker.info (Max Grobecker) Date: Thu, 13 Mar 2014 00:02:10 +0100 Subject: [atlas] New on RIPE Labs: Improved RIPE Atlas Probe Pages In-Reply-To: <53171C85.4020702@ripe.net> References: <53105176.4070904@ripe.net> <5310519F.30001@ripe.net> <53171C85.4020702@ripe.net> Message-ID: <5320E772.6090107@grobecker.info> Hi, is it a wanted feature that when I access my probes page WITHOUT being logged in, I can see logs with full IP addresses which are also downloadable as JSON file on the "Network Information" tab? If it's intended: Is there any way I can disable sharing of these information? Greetings from Wuppertal, Germany Max Grobecker Am 05.03.2014 13:45, schrieb Daniel Quinn: > Dear colleagues, > > As Mirjam announced late last week, we've created a new interface for > probe information on RIPE Atlas. Today we've set this as the default, > so when you navigate to "My Atlas > Probes", you will get the new > interface in place of the old one. > > You can read more about the new layout on RIPE Labs: > > > https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripe-atlas-improved-probe-pages > > or just visit the pages yourself when you have some time: > > https://atlas.ripe.net/probes/ > > From robert at ripe.net Thu Mar 13 09:20:16 2014 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 13 Mar 2014 09:20:16 +0100 Subject: [atlas] New on RIPE Labs: Improved RIPE Atlas Probe Pages In-Reply-To: <5320E772.6090107@grobecker.info> References: <53105176.4070904@ripe.net> <5310519F.30001@ripe.net> <53171C85.4020702@ripe.net> <5320E772.6090107@grobecker.info> Message-ID: <53216A40.9050604@ripe.net> Hello, The system previously enforced logins before showing anything probe or measurement related. The UI change for probes no longer requires this. This specific information has been available for public probes in the previous layout as well, so the behavior did not change. Of course we can change what's available as public info, if there's consensus about this. Regards, Robert On 2014.03.13. 0:02, Max Grobecker wrote: > Hi, > > is it a wanted feature that when I access my probes page WITHOUT being > logged in, I can see logs with full IP addresses which are also > downloadable as JSON file on the "Network Information" tab? > > If it's intended: Is there any way I can disable sharing of these > information? > > > Greetings from Wuppertal, Germany > Max Grobecker > > > Am 05.03.2014 13:45, schrieb Daniel Quinn: >> Dear colleagues, >> >> As Mirjam announced late last week, we've created a new interface for >> probe information on RIPE Atlas. Today we've set this as the default, >> so when you navigate to "My Atlas > Probes", you will get the new >> interface in place of the old one. >> >> You can read more about the new layout on RIPE Labs: >> >> >> https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripe-atlas-improved-probe-pages >> >> or just visit the pages yourself when you have some time: >> >> https://atlas.ripe.net/probes/ >> >> > > From Woeber at CC.UniVie.ac.at Thu Mar 13 12:07:07 2014 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Thu, 13 Mar 2014 12:07:07 +0100 Subject: [atlas] Encouraging RIPE Atlas users to choose for public probes and measurements In-Reply-To: <531EE2BF.7020505@ripe.net> References: <531ED0C2.1090108@ripe.net> <531EE2BF.7020505@ripe.net> Message-ID: <5321915B.7010806@CC.UniVie.ac.at> Vesna Manojlovic wrote: [...] > We would like to hear from more of you, even if you just confirm that > you agree with this revised proposal. IIRC, I was one of those argueing in favour of retaining the option of non-public. So it is appropriate to also state that I fully support your approach and suggestions, on how to "push" people into the right direction :-) > Regards, > > Vesna Manojlovic > Senior Community Builder for Measurements Tools > RIPE NCC Regards, Wilfried From gert at space.net Thu Mar 13 12:09:38 2014 From: gert at space.net (Gert Doering) Date: Thu, 13 Mar 2014 12:09:38 +0100 Subject: [atlas] Encouraging RIPE Atlas users to choose for public probes and measurements In-Reply-To: <5321915B.7010806@CC.UniVie.ac.at> References: <531ED0C2.1090108@ripe.net> <531EE2BF.7020505@ripe.net> <5321915B.7010806@CC.UniVie.ac.at> Message-ID: <20140313110938.GK43641@Space.Net> Hi, On Thu, Mar 13, 2014 at 12:07:07PM +0100, Wilfried Woeber wrote: > IIRC, I was one of those argueing in favour of retaining the option of non-public. > > So it is appropriate to also state that I fully support your approach and > suggestions, on how to "push" people into the right direction :-) +1, for me. 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 sebastian at nzrs.net.nz Fri Mar 14 03:44:56 2014 From: sebastian at nzrs.net.nz (Sebastian Castro) Date: Fri, 14 Mar 2014 15:44:56 +1300 Subject: [atlas] Seismograph for public ongoing measurement Message-ID: <53226D28.6030605@nzrs.net.nz> Hi! The seismograph is available for UDMs as announced here https://labs.ripe.net/Members/becha/seismograph-and-other-new-ripe-atlas-features Is there a way to generate the seismograph for a public ongoing measurement, for example, MSM id 1423322 (f-root)? Cheers -- Sebastian Castro Technical Research Manager .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 495 2337 mobile: +64 21 400535 From mph at one.com Fri Mar 14 09:39:03 2014 From: mph at one.com (Martin Topholm) Date: Fri, 14 Mar 2014 09:39:03 +0100 Subject: [atlas] Building a "My Measurement" list via the API Message-ID: <20140314083903.GA655@one.com> I recently started using the Atlas API interface for easier measurement access. I can't seem to find a way to list "My merasurements". It is quite possible I've overlooked something in the docs, but it seems to me I only can differentiate on is_public=0. Thus all my measurements need to be private in order build a "My Measurements" list. Is there another way? -- Kind regards, Martin Topholm -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From robert at ripe.net Fri Mar 14 13:29:33 2014 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 14 Mar 2014 13:29:33 +0100 Subject: [atlas] Seismograph for public ongoing measurement In-Reply-To: <53226D28.6030605@nzrs.net.nz> References: <53226D28.6030605@nzrs.net.nz> Message-ID: <5322F62D.2050609@ripe.net> On 2014.03.14. 3:44, Sebastian Castro wrote: > Hi! > > The seismograph is available for UDMs as announced here > https://labs.ripe.net/Members/becha/seismograph-and-other-new-ripe-atlas-features > > Is there a way to generate the seismograph for a public ongoing > measurement, for example, MSM id 1423322 (f-root)? > > Cheers Hi, The seismographs works for all ping results, even the public ones that are not yours. Look for the seismograph tab on these pages. The measurement you refer to above is not a ping, so the seismograph is not displayed there. Regards, Robert From mail at johnbond.org Fri Mar 14 16:34:15 2014 From: mail at johnbond.org (John Bond) Date: Fri, 14 Mar 2014 16:34:15 +0100 Subject: [atlas] Feature Request - Atlas Latest Message-ID: Hello Atlas, I would like to request an additional API call which just returns the latest results for a specific measurement. For use cases I would point you to the "RIPE Atlas - Map Visualisations?[1]. I have also seen places in the dnsmon beta where you only show the latest results. this would also be very useful for trouble shooting, if I see an issue its inconvenient to download xMB of json data just to see the whats going on now. An additional feature would be to ask for a result for X seconds in the past, the call would return a result closest to that time. This is for investigating historic events, if I have an issue that lasts one hour I would normally only need one result to perform the initial investigation. This would also be useful to have a history/timeline function to the maps[1]. The following code at the end of this mail does something similar to what I would like using the current API. By setting GO_BACK_IN_TIME=0 you should get the most recent measurement. However this is not perfect, depending on what value one sets the INTERVAL do you may get multiple results or now may get none and as far as I can tell this dose not relate to the measurement Interval. The other issue with queuing the results like this is that you get a lot of superfluous data. I.e. For the dns measurement in the script below you get result[answers][RDATA] and result-rdata which both seem to have the same data. Furthermore when in a script im not to interested in the probe and measurement details. If I am, I will request that information from the appropriate probe or measurement api call. For the DNS measurement a structure like the following would suite my needs { probe_id: { abuf: str, timestamp: int, result: { additional: str, question: str, authority: str, opcode: str, answer: str, flags: str, rcode: str, id: int }, response_time: float } } Thanks John #/bin/sh GO_BACK_IN_TIME=86400 INTERVAL=240 NOW=$(date +%s) MSG_ID=1423370 URL="https://atlas.ripe.net/api/v1/measurement/${MSG_ID}/result/?stop=$((NO W - GO_BACK_IN_TIME))&start=$((NOW - GO_BACK_IN_TIME - FREQUENCY))&format=json" echo ${URL} wget -q "${URL}" -O - [1]https://atlas.ripe.net/results/maps/ From dquinn at ripe.net Fri Mar 14 17:47:46 2014 From: dquinn at ripe.net (Daniel Quinn) Date: Fri, 14 Mar 2014 16:47:46 +0000 Subject: [atlas] Feature Request - Atlas Latest In-Reply-To: References: Message-ID: <532332B2.5080502@ripe.net> On 14/03/14 15:34, John Bond wrote: > I would like to request an additional API call which just returns the > latest results for a specific measurement. For use cases I would point > you to the "RIPE Atlas - Map Visualisations?[1]. I have also seen places > in the dnsmon beta where you only show the latest results. this would > also be very useful for trouble shooting, if I see an issue its > inconvenient to download xMB of json data just to see the whats going on > now. I wrote this call yesterday actually, though it'll still be a few weeks before it sees the light of day. We recently updated our datastore table structure to allow simpler querying of the latest results, so this call is now relatively low-cost to our infrastructure. I'm currently in the process of porting it to work against all of our measurement maps, including the new measurement pages, so they will probably be released at the same time. > An additional feature would be to ask for a result for X seconds in the > past, the call would return a result closest to that time. This is for > investigating historic events, if I have an issue that lasts one hour I > would normally only need one result to perform the initial investigation. > This would also be useful to have a history/timeline function to the > maps[1]. Unfortunately, because of how we store the data, we can't simply grab a perfect set of results nearest time X. At best, I can give you that which you've already accomplished with your snippet of code here: Take all results within a designated window, loop over them, throwing out duplicates by probe id, returning the remainder. It would require the server to do much of the work you've managed to do client-side, in only a few lines, so there isn't a lot of motivation on our side to do it... yet. We do have intentions to make the maps you mentioned historically relevant, at which point such a call may make more sense. I can't make any promises here though. Keep an eye on the list and we'll announce when the new latest call is ready :-) From amskh at yandex.ru Sat Mar 15 09:35:49 2014 From: amskh at yandex.ru (Andrei Sukhov) Date: Sat, 15 Mar 2014 12:35:49 +0400 Subject: [atlas] [mat-wg] Research papers for IMC or other measurements conferences In-Reply-To: <53204C63.5020401@ripe.net> References: <53204C63.5020401@ripe.net> Message-ID: <946481394872549@web24m.yandex.ru> Dear Vesna, Unfortunately this paper has been published in a short form only in Russian, our translation is available on http://arxiv.org/abs/1003.0190. Once we publish this work, I will send a link to it. Currently we began to research percent of optimal routes based on RIPE Atlas data. The basis of this research is comparison of minimum delay and geographic distance between autonomous systems. We need at least six months to analyze the data. Sincerely yours, Andrei Sukhov 12.03.2014, 16:01, "Vesna Manojlovic" : > Dear colleagues, > > a couple of researchers using RIPE Atlas brought this conference to my > attention, and I noticed that the CFP deadline is approaching fast. > > I would be curious to hear if anyone else is planning to submit a paper > based on RIPE Atlas data to IMC, or any other conference. Please let me > know if you need some extra help from us: more credits, higher limits > for usage of probes per measurements, or additional text for your paper. > > We would be grateful for your mention of the RIPE NCC and RIPE Atlas in > your paper, and would like to invite you to share your results, after > the conference, with RIPE community, either by presenting at RIPE > meetings or publishing on RIPE Labs. > > Regards, > Vesna > > IMC Details: > > http://conferences2.sigcomm.org/imc/2014/ > > The 2014 Internet Measurement Conference (IMC) is a three-day event > focusing on Internet measurement and analysis. The conference is > sponsored jointly by ACM SIGCOMM and ACM SIGMETRICS. IMC 2014 is the > 14th in a series of highly successful Internet Measurement Workshops and > Conferences. > > The ACM IMC 2014 conference will be held in Vancouver, BC, Canada on > November 5-7, 2014. > > Call for papers deadline: 30 April > > http://conferences2.sigcomm.org/imc/2014/cfp.html From dquinn at ripe.net Mon Mar 17 12:25:04 2014 From: dquinn at ripe.net (Daniel Quinn) Date: Mon, 17 Mar 2014 11:25:04 +0000 Subject: [atlas] Building a "My Measurement" list via the API In-Reply-To: <20140314083903.GA655@one.com> References: <20140314083903.GA655@one.com> Message-ID: <5326DB90.1000504@ripe.net> Unfortunately, at this time there's no way to make a request like "show me my measurements" as authentication isn't available via the API, only authorization by way of the API keys system. With that said though, you can get a list of measurements by a number of filtration methods, including by just asking for a list of measurements filtered by msm_id: curl 'https://atlas.ripe.net/api/v1/measurement/?msm_id__in=1000192,1000005' So, if you know the ids of your measurements, this is probably the easiest way to get that list via the API. I hope that helps. From mail at johnbond.org Mon Mar 17 12:56:04 2014 From: mail at johnbond.org (John Bond) Date: Mon, 17 Mar 2014 12:56:04 +0100 Subject: [atlas] Feature Request - Atlas Latest In-Reply-To: <532332B2.5080502@ripe.net> References: <532332B2.5080502@ripe.net> Message-ID: Hi Daniel On 14/03/14 17:47, "Daniel Quinn" wrote: >On 14/03/14 15:34, John Bond wrote: >> I would like to request an additional API call which just returns the >> latest results for a specific measurement. For use cases I would point >> you to the "RIPE Atlas - Map Visualisations?[1]. I have also seen >>places >> in the dnsmon beta where you only show the latest results. this would >> also be very useful for trouble shooting, if I see an issue its >> inconvenient to download xMB of json data just to see the whats going on >> now. > >I wrote this call yesterday actually, though it'll still be a few weeks >before it sees the light of day. We recently updated our datastore >table structure to allow simpler querying of the latest results, so this >call is now relatively low-cost to our infrastructure. I'm currently in >the process of porting it to work against all of our measurement maps, >including the new measurement pages, so they will probably be released >at the same time. Great news Thanks > >> An additional feature would be to ask for a result for X seconds in the >> past, the call would return a result closest to that time. This is for >> investigating historic events, if I have an issue that lasts one hour I >> would normally only need one result to perform the initial >>investigation. >> This would also be useful to have a history/timeline function to the >> maps[1]. > >Unfortunately, because of how we store the data, we can't simply grab a >perfect set of results nearest time X. At best, I can give you that >which you've already accomplished with your snippet of code here: Take >all results within a designated window, loop over them, throwing out >duplicates by probe id, returning the remainder. It would require the >server to do much of the work you've managed to do client-side, in only >a few lines, so there isn't a lot of motivation on our side to do it... >yet. We do have intentions to make the maps you mentioned historically >relevant, at which point such a call may make more sense. I can't make >any promises here though. Understood I can live with doing this client side. Thanks John From mgalante at ripe.net Mon Mar 17 13:31:19 2014 From: mgalante at ripe.net (Michela Galante) Date: Mon, 17 Mar 2014 13:31:19 +0100 Subject: [atlas] CSUC (ES) has joined RIPE Atlas anchors Message-ID: 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 es-bcn-as13041 and it is hosted by Consorci de Serveis Universitaris de Catalunya (CSUC) in Barcelona, Spain. Congratulations to CSUC! This is the first anchor in Spain. 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: 2626 bytes Desc: not available URL: From BECHA at ripe.net Tue Mar 18 13:58:03 2014 From: BECHA at ripe.net (Vesna Manojlovic) Date: Tue, 18 Mar 2014 13:58:03 +0100 Subject: [atlas] The Beta Version of the New DNSMON is Now Available In-Reply-To: <77BC1167-29D6-45C1-B380-7C67A8B49621@ripe.net> References: <77BC1167-29D6-45C1-B380-7C67A8B49621@ripe.net> Message-ID: <532842DB.7000306@ripe.net> Dear colleagues, The DNS Monitoring Service (DNSMON) has been providing a comprehensive, objective and up-to-date overview of the quality of various global and regional DNS operators' services since 2003. We are in the process of integrating DNSMON within RIPE Atlas and the beta version of the new DNSMON is now publicly available: https://atlas.ripe.net/dnsmon We have also published a RIPE Labs article detailing what?s changed in the new DNSMON: https://labs.ripe.net/Members/fatemah_mafi/an-updated-dns-monitoring-service We invite you all to try the new service and provide your feedback. We?re confident that the new DNSMON will continue to meet your needs and hope that you'll be happy with the new features. Please send your comments and questions to the DNS Working Group Mailing List at dns-wg at ripe.net. Kind regards, Vesna Manojlovic Measurements Community Building RIPE NCC From jaap at NLnetLabs.nl Wed Mar 19 11:49:57 2014 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Wed, 19 Mar 2014 11:49:57 +0100 Subject: [atlas] [dnsmon-user] The Beta Version of the New DNSMON is Now Available In-Reply-To: <532842DB.7000306@ripe.net> References: <77BC1167-29D6-45C1-B380-7C67A8B49621@ripe.net> <532842DB.7000306@ripe.net> Message-ID: <201403191049.s2JAnv8p001190@bela.nlnetlabs.nl> We invite you all to try the new service and provide your feedback. We?re confident that the new DNSMON will continue to meet your needs and hope that you'll be happy with the new features. It doesn't come anywhere close to the old service. E.g., the functionality of is missing. The UI page is garbled. All in all this is pretty bad. jaap From robert at ripe.net Wed Mar 19 12:11:39 2014 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 19 Mar 2014 12:11:39 +0100 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: <53297B6B.7010500@ripe.net> Dear Jaap, On 2014.03.19. 11:49, Jaap Akkerhuis wrote: > > We invite you all to try the new service and provide your feedback. > We?re confident that the new DNSMON will continue to meet your needs and > hope that you'll be happy with the new features. > > It doesn't come anywhere close to the old service. E.g., the functionality > of is missing. This server view exists in the new implementation too. One can reach it from the zone view, by clicking on the name on a particular server. We prepared for this use case since people are mostly interested in the servers of a (their) particular zone, not an alphabetical list. That said, we can make such a listing page if there's a need for it. > The UI page is garbled. That was an oops, but it is fixed already. Regards, Robert > All in all this is pretty bad. > > > jaap > > From Brett.Carr at nominet.org.uk Wed Mar 19 11:57:51 2014 From: Brett.Carr at nominet.org.uk (Brett Carr) Date: Wed, 19 Mar 2014 10:57:51 +0000 Subject: [atlas] [dnsmon-contact] [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: <2485CD86D7C59E4C99BA16B2B5754E2024E6DF@wds-exc2.okna.nominet.org.uk> Jaap, > -----Original Message----- > From: dnsmon-contact-bounces at ripe.net [mailto:dnsmon-contact- > bounces at ripe.net] On Behalf Of Jaap Akkerhuis > Sent: Wednesday, March 19, 2014 10:50 AM > To: Vesna Manojlovic > Cc: ncc-services-wg at ripe.net; dns-wg at ripe.net; RIPE Atlas People; > dnsmon-contact at ripe.net; dnsmon-user at ripe.net; Measurement Analysis and > Tools Working Group > Subject: Re: [dnsmon-contact] [dnsmon-user] The Beta Version of the New > DNSMON is Now Available > > > > We invite you all to try the new service and provide your feedback. > We're confident that the new DNSMON will continue to meet your > needs and > hope that you'll be happy with the new features. > > It doesn't come anywhere close to the old service. E.g., the > functionality of is > missing. > That's what I thought at first but actually it is there it just takes a little finding. Click on the TLD and you will get a list of servers down the left, if you then click on a server you will get something that looks very similar to the old server view. There are two things that I would really like to see: 1. The ability to pull some data out and pull it in to my own monitoring system for a familiar view for our operations engineers. 2. An ability to provide sms/e-mail alerting depending on certain (user definable) conditions. Brett Nominet UK. From Brett.Carr at nominet.org.uk Wed Mar 19 12:02:03 2014 From: Brett.Carr at nominet.org.uk (Brett Carr) Date: Wed, 19 Mar 2014 11:02:03 +0000 Subject: [atlas] [dns-wg] [dnsmon-contact] [dnsmon-user] The Beta Version of the New DNSMON is Now Available {Sender Address Possibly Forged} In-Reply-To: <2485CD86D7C59E4C99BA16B2B5754E2024E6DF@wds-exc2.okna.nominet.org.uk> References: <77BC1167-29D6-45C1-B380-7C67A8B49621@ripe.net> <532842DB.7000306@ripe.net> <201403191049.s2JAnv8p001190@bela.nlnetlabs.nl> <2485CD86D7C59E4C99BA16B2B5754E2024E6DF@wds-exc2.okna.nominet.org.uk> Message-ID: <2485CD86D7C59E4C99BA16B2B5754E2024E8FF@wds-exc2.okna.nominet.org.uk> > -----Original Message----- > From: dns-wg-bounces at ripe.net [mailto:dns-wg-bounces at ripe.net] On > Behalf Of Brett Carr > Sent: Wednesday, March 19, 2014 10:58 AM > To: Jaap Akkerhuis; Vesna Manojlovic > Cc: ncc-services-wg at ripe.net; dns-wg at ripe.net; RIPE Atlas People; > dnsmon-contact at ripe.net; dnsmon-user at ripe.net; Measurement Analysis and > Tools Working Group > Subject: Re: [dns-wg] [dnsmon-contact] [dnsmon-user] The Beta Version > of the New DNSMON is Now Available {Sender Address Possibly Forged} > 2. An ability to provide sms/e-mail alerting depending on certain (user > definable) conditions. To be slightly more specific, https://labs.ripe.net/Members/suzanne_taylor_muzzin/introducing-ripe-atlas-status-checks Something more DNS specific but similar to the above would be very useful. Brett From jared at puck.nether.net Wed Mar 19 14:14:05 2014 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 19 Mar 2014 09:14:05 -0400 Subject: [atlas] 8.8.8.8 hijack and ripe atlas Message-ID: <3339049E-1F07-4AA1-9075-5068C5829742@puck.nether.net> It appears there are some public measurements like #1002630, and i'm curious if someone is able to look at the latency and TTL numbers of the transport side and observe the localized hijacking of 8.8.8.8. The dataset is somewhat huge and i'm not a json master so trying to discern if there is evidence in there is something i'm looking at. - Jared From Woeber at CC.UniVie.ac.at Wed Mar 19 14:47:16 2014 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Wed, 19 Mar 2014 14:47:16 +0100 Subject: [atlas] life-cycle of a probe? Message-ID: <53299FE4.1010903@CC.UniVie.ac.at> Hi folks, is there a way to find out when a particular probe (under my control[1]) was seen by a/the collector(s) for the first time? The best I have come up with is to look at the raw data download, but I'm not sure that the data has been preserved for raw download in the "early days". Thanks, Wilfried [1] just in case, I am interested in ID 466 and 414 From robert at ripe.net Wed Mar 19 15:06:25 2014 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 19 Mar 2014 15:06:25 +0100 Subject: [atlas] life-cycle of a probe? In-Reply-To: <53299FE4.1010903@CC.UniVie.ac.at> References: <53299FE4.1010903@CC.UniVie.ac.at> Message-ID: <5329A461.4040503@ripe.net> On 2014.03.19. 14:47, Wilfried Woeber wrote: > Hi folks, > > is there a way to find out when a particular probe (under my control[1]) > was seen by a/the collector(s) for the first time? > > The best I have come up with is to look at the raw data download, but I'm > not sure that the data has been preserved for raw download in the "early days". > > Thanks, > Wilfried > > [1] just in case, I am interested in ID 466 and 414 Wilfried, The best place to look is probably your connection log history, which is downloadable for your probes through the UI in monthly chunks. Regards, Robert From Woeber at CC.UniVie.ac.at Wed Mar 19 16:02:22 2014 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Wed, 19 Mar 2014 16:02:22 +0100 Subject: [atlas] life-cycle of a probe? In-Reply-To: <5329A461.4040503@ripe.net> References: <53299FE4.1010903@CC.UniVie.ac.at> <5329A461.4040503@ripe.net> Message-ID: <5329B17E.2070904@CC.UniVie.ac.at> Thanks Robert, the conn log history is an even better idea than my raw data idea was, 'cause obviously it starts with the month when the probe was seen (Nov. 2010), while the raw data starts with (empty sets) on 2010-01-01. Tnx, Wilfried Robert Kisteleki wrote: > On 2014.03.19. 14:47, Wilfried Woeber wrote: > >>Hi folks, >> >>is there a way to find out when a particular probe (under my control[1]) >>was seen by a/the collector(s) for the first time? >> >>The best I have come up with is to look at the raw data download, but I'm >>not sure that the data has been preserved for raw download in the "early days". >> >>Thanks, >>Wilfried >> >>[1] just in case, I am interested in ID 466 and 414 > > > Wilfried, > > The best place to look is probably your connection log history, which is > downloadable for your probes through the UI in monthly chunks. > > Regards, > Robert > > From mgalante at ripe.net Wed Mar 19 16:48:33 2014 From: mgalante at ripe.net (Michela Galante) Date: Wed, 19 Mar 2014 16:48:33 +0100 Subject: [atlas] Netnod (SE) has joined RIPE Atlas anchors Message-ID: 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 se-sto-as8674 and it is hosted by Netnod in Stockholm, Sweden on behalf of RIPE NCC since they are one of our RIS Remote Route Collector locations. 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: 2626 bytes Desc: not available URL: From stephanr.mueller at gmx.de Wed Mar 19 18:14:39 2014 From: stephanr.mueller at gmx.de (=?UTF-8?Q?=22Stephan_M=C3=BCller=22?=) Date: Wed, 19 Mar 2014 18:14:39 +0100 Subject: [atlas] 8.8.8.8 hijack and ripe atlas In-Reply-To: <3339049E-1F07-4AA1-9075-5068C5829742@puck.nether.net> References: <3339049E-1F07-4AA1-9075-5068C5829742@puck.nether.net> Message-ID: > Gesendet: Mittwoch, 19. M?rz 2014 um 14:14 Uhr > Von: "Jared Mauch" > An: "RIPE Atlas People" > Betreff: [atlas] 8.8.8.8 hijack and ripe atlas > > It appears there are some public measurements like #1002630, and i'm curious if someone is able to look at the latency and TTL numbers of the transport side and observe the localized hijacking of 8.8.8.8. > > The dataset is somewhat huge and i'm not a json master so trying to discern if there is evidence in there is something i'm looking at. > > - Jared > Could you please elaborate on what you are trying to do? I did not fully understand you (and I'm only a layman). Is this related to http://www.itnews.com.au/News/375278,google-dns-servers-suffer-brief-traffic-hijack.aspx Regards, Stephan From jared at puck.nether.net Wed Mar 19 18:23:20 2014 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 19 Mar 2014 13:23:20 -0400 Subject: [atlas] 8.8.8.8 hijack and ripe atlas In-Reply-To: References: <3339049E-1F07-4AA1-9075-5068C5829742@puck.nether.net> Message-ID: On Mar 19, 2014, at 1:14 PM, Stephan M?ller wrote: > > >> Gesendet: Mittwoch, 19. M?rz 2014 um 14:14 Uhr >> Von: "Jared Mauch" >> An: "RIPE Atlas People" >> Betreff: [atlas] 8.8.8.8 hijack and ripe atlas >> >> It appears there are some public measurements like #1002630, and i'm curious if someone is able to look at the latency and TTL numbers of the transport side and observe the localized hijacking of 8.8.8.8. >> >> The dataset is somewhat huge and i'm not a json master so trying to discern if there is evidence in there is something i'm looking at. >> >> - Jared >> > > Could you please elaborate on what you are trying to do? I did not fully understand you (and I'm only a layman). > Is this related to http://www.itnews.com.au/News/375278,google-dns-servers-suffer-brief-traffic-hijack.aspx What i'm trying to determine is if there is an outlier of the mean RTT and/or TTL from probes within a region to 8.8.8.8 which would represent a localized hijacking could be detected. eg: If the RTT is typically 20ms and drops to 8ms, perhaps that is something worthy of investigating. Same for TTL, if the IP_TTL is typically 54 due to taking 10 hops to reach Google, and now becomes 58, that would be a localized "hijacking" or unauthorized use of the IP space. - Jared From emile.aben at ripe.net Thu Mar 20 09:14:55 2014 From: emile.aben at ripe.net (Emile Aben) Date: Thu, 20 Mar 2014 09:14:55 +0100 Subject: [atlas] 8.8.8.8 hijack and ripe atlas In-Reply-To: <3339049E-1F07-4AA1-9075-5068C5829742@puck.nether.net> References: <3339049E-1F07-4AA1-9075-5068C5829742@puck.nether.net> Message-ID: <532AA37F.1050806@ripe.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 19/03/14 14:14, Jared Mauch wrote: > It appears there are some public measurements like #1002630, and > i'm curious if someone is able to look at the latency and TTL > numbers of the transport side and observe the localized hijacking > of 8.8.8.8. > > The dataset is somewhat huge and i'm not a json master so trying > to discern if there is evidence in there is something i'm looking > at. This may works to get the data into an easier to digest form (requires the perl JSON module installed): curl "https://atlas.ripe.net/api/v1/measurement/1002630/result/?start=1340323200&stop=1395273599&format=txt" | perl -MJSON -nle'$d=decode_json($_); print "$d->{timestamp} $d->{prb_id} $d->{min} $d->{ttl}"' | tee results.txt I looked into the results a little bit and didn't find clues for a localized hijacking of 8.8.8.8 for the probes I looked at (out of the 10 total in that measurement). The fact that 8.8.8.8 is anycast may make it hard to distinguish between changes due to anycast flapping or localized hijacks. hth, Emile -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlMqo38ACgkQj05ACITZaqq8rgD6A50rqO5rTCzlTBPj+fNET7bR 7U2wO54lXbAFND+ciKsA/1dS+yKqysVa2j5I0WTLXAoiSWK3cBGDYB4nkeNKP0AZ =iDv1 -----END PGP SIGNATURE----- From jared at puck.nether.net Thu Mar 20 09:47:03 2014 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 20 Mar 2014 04:47:03 -0400 Subject: [atlas] 8.8.8.8 hijack and ripe atlas In-Reply-To: <532AA37F.1050806@ripe.net> References: <3339049E-1F07-4AA1-9075-5068C5829742@puck.nether.net> <532AA37F.1050806@ripe.net> Message-ID: <28E0C15A-131C-4BE2-9C07-F8640279AFD9@puck.nether.net> On Mar 20, 2014, at 4:14 AM, Emile Aben wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 19/03/14 14:14, Jared Mauch wrote: >> It appears there are some public measurements like #1002630, and >> i'm curious if someone is able to look at the latency and TTL >> numbers of the transport side and observe the localized hijacking >> of 8.8.8.8. >> >> The dataset is somewhat huge and i'm not a json master so trying >> to discern if there is evidence in there is something i'm looking >> at. > > This may works to get the data into an easier to digest form (requires > the perl JSON module installed): > > curl > "https://atlas.ripe.net/api/v1/measurement/1002630/result/?start=1340323200&stop=1395273599&format=txt" > | perl -MJSON -nle'$d=decode_json($_); print "$d->{timestamp} > $d->{prb_id} $d->{min} $d->{ttl}"' | tee results.txt > > I looked into the results a little bit and didn't find clues for a > localized hijacking of 8.8.8.8 for the probes I looked at (out of the > 10 total in that measurement). The fact that 8.8.8.8 is anycast may > make it hard to distinguish between changes due to anycast flapping or > localized hijacks. Do the allocated probes stay fixed or rotate over time? (I?m new here, so hope the question isn?t too dumb). - Jared From robert at ripe.net Thu Mar 20 09:49:18 2014 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 20 Mar 2014 09:49:18 +0100 Subject: [atlas] RIPE Atlas DNS status checks (was:Beta Version of the New DNSMON...) In-Reply-To: <2485CD86D7C59E4C99BA16B2B5754E2024E8FF@wds-exc2.okna.nominet.org.uk> References: <77BC1167-29D6-45C1-B380-7C67A8B49621@ripe.net> <532842DB.7000306@ripe.net> <201403191049.s2JAnv8p001190@bela.nlnetlabs.nl> <2485CD86D7C59E4C99BA16B2B5754E2024E6DF@wds-exc2.okna.nominet.org.uk> <2485CD86D7C59E4C99BA16B2B5754E2024E8FF@wds-exc2.okna.nominet.org.uk> Message-ID: <532AAB8E.9020104@ripe.net> Brett, On 2014.03.19. 12:02, Brett Carr wrote: > There are two things that I would really like to see: > > 1. The ability to pull some data out and pull it in to my own monitoring system for a familiar view for our operations engineers. All the data for DNSMON are collected by RIPE Atlas as ongoing, public DNS measurements. The measurement IDs are exposed in the DNSMON interface ("Show RIPE Atlas measurements" button). There's a related discussion on the RIPE Atlas users' mailing list about an API to get to the *latest* results per measurement, which will come handy if you don't want to download gigs of results every time. >> 2. An ability to provide sms/e-mail alerting depending on certain (user >> definable) conditions. > > To be slightly more specific, > > https://labs.ripe.net/Members/suzanne_taylor_muzzin/introducing-ripe-atlas-status-checks > > Something more DNS specific but similar to the above would be very useful. This is entirely possible. In order to implement it, we'd like to keep the mechanism described in the article, but extend it to support DNS. Still, because determining success/failure of DNS measurements is a bit more tricky than pings, the details need some discussion. I invite all to have that discussion on the MAT-WG mailing list (also on cc now). Regards, Robert > Brett > > > > From emile.aben at ripe.net Thu Mar 20 09:56:57 2014 From: emile.aben at ripe.net (Emile Aben) Date: Thu, 20 Mar 2014 09:56:57 +0100 Subject: [atlas] 8.8.8.8 hijack and ripe atlas In-Reply-To: <28E0C15A-131C-4BE2-9C07-F8640279AFD9@puck.nether.net> References: <3339049E-1F07-4AA1-9075-5068C5829742@puck.nether.net> <532AA37F.1050806@ripe.net> <28E0C15A-131C-4BE2-9C07-F8640279AFD9@puck.nether.net> Message-ID: <532AAD59.9030202@ripe.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 20/03/14 09:47, Jared Mauch wrote: > > On Mar 20, 2014, at 4:14 AM, Emile Aben > wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >> >> On 19/03/14 14:14, Jared Mauch wrote: >>> It appears there are some public measurements like #1002630, >>> and i'm curious if someone is able to look at the latency and >>> TTL numbers of the transport side and observe the localized >>> hijacking of 8.8.8.8. >>> >>> The dataset is somewhat huge and i'm not a json master so >>> trying to discern if there is evidence in there is something >>> i'm looking at. >> >> This may works to get the data into an easier to digest form >> (requires the perl JSON module installed): >> >> curl >> "https://atlas.ripe.net/api/v1/measurement/1002630/result/?start=1340323200&stop=1395273599&format=txt" >> >> | perl -MJSON -nle'$d=decode_json($_); print "$d->{timestamp} >> $d->{prb_id} $d->{min} $d->{ttl}"' | tee results.txt >> >> I looked into the results a little bit and didn't find clues for >> a localized hijacking of 8.8.8.8 for the probes I looked at (out >> of the 10 total in that measurement). The fact that 8.8.8.8 is >> anycast may make it hard to distinguish between changes due to >> anycast flapping or localized hijacks. > > Do the allocated probes stay fixed or rotate over time? (I?m new > here, so hope the question isn?t too dumb). Fixed, so you can look at the same probe over longer periods of time. > > - Jared > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlMqrVkACgkQj05ACITZaqoq2wD+N0p5J96zlGYXYWtGA6gilc36 +uMMYC2YZs1+IdVMTz4A/3atwBaqzvUv2R7yXFHZDVnCw9Iacug616OJ96AKCaA1 =rKuO -----END PGP SIGNATURE----- From jared at puck.nether.net Thu Mar 20 09:59:03 2014 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 20 Mar 2014 04:59:03 -0400 Subject: [atlas] 8.8.8.8 hijack and ripe atlas In-Reply-To: <532AAD59.9030202@ripe.net> References: <3339049E-1F07-4AA1-9075-5068C5829742@puck.nether.net> <532AA37F.1050806@ripe.net> <28E0C15A-131C-4BE2-9C07-F8640279AFD9@puck.nether.net> <532AAD59.9030202@ripe.net> Message-ID: <2358BC56-0810-4C11-BFEA-5B6E0B58F2D5@puck.nether.net> On Mar 20, 2014, at 4:56 AM, Emile Aben wrote: > Fixed, so you can look at the same probe over longer periods of time. Might be interesting to have an option to allow this to have entropy/reallocation after a single test to eventually collect data from all probes. Would be valuable for monitoring these ?anycast? type resources. - Jared From robert at ripe.net Thu Mar 20 11:35:22 2014 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 20 Mar 2014 11:35:22 +0100 Subject: [atlas] APIs for accessing DNSMON data In-Reply-To: <48C3E808-1B1F-4B10-A7C6-89A6BE4A9261@rfc1035.com> References: <77BC1167-29D6-45C1-B380-7C67A8B49621@ripe.net> <532842DB.7000306@ripe.net> <201403191049.s2JAnv8p001190@bela.nlnetlabs.nl> <2485CD86D7C59E4C99BA16B2B5754E2024E6DF@wds-exc2.okna.nominet.org.uk> <2485CD86D7C59E4C99BA16B2B5754E2024E8FF@wds-exc2.okna.nominet.org.uk> <532AAB8E.9020104@ripe.net> <48C3E808-1B1F-4B10-A7C6-89A6BE4A9261@rfc1035.com> Message-ID: <532AC46A.9040206@ripe.net> On 2014.03.20. 11:21, Jim Reid wrote: > On 20 Mar 2014, at 08:49, Robert Kisteleki wrote: > >> There's a related discussion on the RIPE Atlas users' mailing list about an >> API to get to the *latest* results per measurement, which will come handy if >> you don't want to download gigs of results every time. > > It's a pity Robert that the discussion appears to be confined to that list. I expect many TLD and root operators would be interested in having some way of using DNSMON data to supplement their existing DNS monitoring arrangements. Not all of these will be paying customers for DNSMON or hosting Atlas probes. There may well be other fora too like CENTR or OARC who could have useful contributions to the development of this API. > > It would be nice if the DNS business could come up with a standard API/data format for this side of thing. OTOH, I can see why that could be considerably harder to achieve than cat-herding. > > Perhaps we can have the WG discuss this in Warsaw. Jim, I don't really mind where the discussion happens, I'm more interested in making sure that it does happen, with that the interested parties are involved. And I was trying to avoid having multiple discussions on multiple mailing lists so named one: Atlas, because it will be an Atlas feature at the end of the process. Regards, Robert From Brett.Carr at nominet.org.uk Thu Mar 20 11:33:03 2014 From: Brett.Carr at nominet.org.uk (Brett Carr) Date: Thu, 20 Mar 2014 10:33:03 +0000 Subject: [atlas] APIs for accessing DNSMON data In-Reply-To: <48C3E808-1B1F-4B10-A7C6-89A6BE4A9261@rfc1035.com> References: <77BC1167-29D6-45C1-B380-7C67A8B49621@ripe.net> <532842DB.7000306@ripe.net> <201403191049.s2JAnv8p001190@bela.nlnetlabs.nl> <2485CD86D7C59E4C99BA16B2B5754E2024E6DF@wds-exc2.okna.nominet.org.uk> <2485CD86D7C59E4C99BA16B2B5754E2024E8FF@wds-exc2.okna.nominet.org.uk> <532AAB8E.9020104@ripe.net> <48C3E808-1B1F-4B10-A7C6-89A6BE4A9261@rfc1035.com> Message-ID: <58DFDDEA-5FE6-4437-B91F-5264400C9C1D@nominet.org.uk> On 20 Mar 2014, at 10:21, Jim Reid wrote: > On 20 Mar 2014, at 08:49, Robert Kisteleki wrote: > >> There's a related discussion on the RIPE Atlas users' mailing list about an >> API to get to the *latest* results per measurement, which will come handy if >> you don't want to download gigs of results every time. > > It's a pity Robert that the discussion appears to be confined to that list. I expect many TLD and root operators would be interested in having some way of using DNSMON data to supplement their existing DNS monitoring arrangements. Not all of these will be paying customers for DNSMON or hosting Atlas probes. There may well be other fora too like CENTR or OARC who could have useful contributions to the development of this API. > > It would be nice if the DNS business could come up with a standard API/data format for this side of thing. OTOH, I can see why that could be considerably harder to achieve than cat-herding. > > Perhaps we can have the WG discuss this in Warsaw. > I think that this would be an excellent use of some time in Warsaw. Brett From jim at rfc1035.com Thu Mar 20 11:21:05 2014 From: jim at rfc1035.com (Jim Reid) Date: Thu, 20 Mar 2014 10:21:05 +0000 Subject: [atlas] APIs for accessing DNSMON data In-Reply-To: <532AAB8E.9020104@ripe.net> References: <77BC1167-29D6-45C1-B380-7C67A8B49621@ripe.net> <532842DB.7000306@ripe.net> <201403191049.s2JAnv8p001190@bela.nlnetlabs.nl> <2485CD86D7C59E4C99BA16B2B5754E2024E6DF@wds-exc2.okna.nominet.org.uk> <2485CD86D7C59E4C99BA16B2B5754E2024E8FF@wds-exc2.okna.nominet.org.uk> <532AAB8E.9020104@ripe.net> Message-ID: <48C3E808-1B1F-4B10-A7C6-89A6BE4A9261@rfc1035.com> On 20 Mar 2014, at 08:49, Robert Kisteleki wrote: > There's a related discussion on the RIPE Atlas users' mailing list about an > API to get to the *latest* results per measurement, which will come handy if > you don't want to download gigs of results every time. It's a pity Robert that the discussion appears to be confined to that list. I expect many TLD and root operators would be interested in having some way of using DNSMON data to supplement their existing DNS monitoring arrangements. Not all of these will be paying customers for DNSMON or hosting Atlas probes. There may well be other fora too like CENTR or OARC who could have useful contributions to the development of this API. It would be nice if the DNS business could come up with a standard API/data format for this side of thing. OTOH, I can see why that could be considerably harder to achieve than cat-herding. Perhaps we can have the WG discuss this in Warsaw. From mgalante at ripe.net Thu Mar 20 12:55:18 2014 From: mgalante at ripe.net (Michela Galante) Date: Thu, 20 Mar 2014 12:55:18 +0100 Subject: [atlas] HEAnet (IE) has joined RIPE Atlas anchors Message-ID: 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 ie-dub-as1213 and it is hosted by HEAnet in Dublin, Ireland. 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: 2626 bytes Desc: not available URL: From Woeber at CC.UniVie.ac.at Thu Mar 20 13:31:25 2014 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Thu, 20 Mar 2014 13:31:25 +0100 Subject: [atlas] [dns-wg] APIs for accessing DNSMON data In-Reply-To: <532AC46A.9040206@ripe.net> References: <77BC1167-29D6-45C1-B380-7C67A8B49621@ripe.net> <532842DB.7000306@ripe.net> <201403191049.s2JAnv8p001190@bela.nlnetlabs.nl> <2485CD86D7C59E4C99BA16B2B5754E2024E6DF@wds-exc2.okna.nominet.org.uk> <2485CD86D7C59E4C99BA16B2B5754E2024E8FF@wds-exc2.okna.nominet.org.uk> <532AAB8E.9020104@ripe.net> <48C3E808-1B1F-4B10-A7C6-89A6BE4A9261@rfc1035.com> <532AC46A.9040206@ripe.net> Message-ID: <532ADF9D.3040502@CC.UniVie.ac.at> Robert Kisteleki wrote: > On 2014.03.20. 11:21, Jim Reid wrote: > >>On 20 Mar 2014, at 08:49, Robert Kisteleki wrote: >> >> >>>There's a related discussion on the RIPE Atlas users' mailing list about an >>>API to get to the *latest* results per measurement, which will come handy if >>>you don't want to download gigs of results every time. >> >>It's a pity Robert that the discussion appears to be confined to that list. I expect many TLD and root operators would be interested in having some way of using DNSMON data to supplement their existing DNS monitoring arrangements. Not all of these will be paying customers for DNSMON or hosting Atlas probes. There may well be other fora too like CENTR or OARC who could have useful contributions to the development of this API. >> >>It would be nice if the DNS business could come up with a standard API/data format for this side of thing. OTOH, I can see why that could be considerably harder to achieve than cat-herding. >> >>Perhaps we can have the WG discuss this in Warsaw. Perhaps a prep discussion from the DNS pov and then a follow-up in MAT on Thursday? Wilfried > Jim, > > I don't really mind where the discussion happens, I'm more interested in > making sure that it does happen, with that the interested parties are > involved. And I was trying to avoid having multiple discussions on multiple > mailing lists so named one: Atlas, because it will be an Atlas feature at > the end of the process. > > Regards, > Robert > > From Woeber at CC.UniVie.ac.at Fri Mar 21 22:31:23 2014 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Fri, 21 Mar 2014 22:31:23 +0100 Subject: [atlas] 400 Bad Request Message-ID: <532CAFAB.6000301@CC.UniVie.ac.at> Hi folks, I had a look at the list of my ambassador probes and noticed that one of them is currently listed as being off-line (ID 12734) The probe ID is rendered as a link, with this URL: https://atlas.ripe.net/ambassadors/probes/%7B%%20url%20'probe-detail'%20pk=record.prb_id%20%7D%7D which comes back with " Bad Request Your browser sent a request that this server could not understand. " Just fyi, no harm done :-) Cheers, Wilfried From robert at ripe.net Sat Mar 22 09:49:37 2014 From: robert at ripe.net (Robert Kisteleki) Date: Sat, 22 Mar 2014 09:49:37 +0100 Subject: [atlas] 400 Bad Request In-Reply-To: <532CAFAB.6000301@CC.UniVie.ac.at> References: <532CAFAB.6000301@CC.UniVie.ac.at> Message-ID: <532D4EA1.6030208@ripe.net> Wilfried, Thank you for the report, this is now fixed. Regards, Robert On 2014.03.21. 22:31, Wilfried Woeber wrote: > Hi folks, > > I had a look at the list of my ambassador probes and noticed that one of > them is currently listed as being off-line (ID 12734) > > The probe ID is rendered as a link, with this URL: > > https://atlas.ripe.net/ambassadors/probes/%7B%%20url%20'probe-detail'%20pk=record.prb_id%20%7D%7D > > which comes back with > " > Bad Request > > Your browser sent a request that this server could not understand. > " > > Just fyi, no harm done :-) > Cheers, > Wilfried > > From Woeber at CC.UniVie.ac.at Sat Mar 22 15:26:01 2014 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Sat, 22 Mar 2014 15:26:01 +0100 Subject: [atlas] 400 Bad Request - tnx + another Q In-Reply-To: <532D4EA1.6030208@ripe.net> References: <532CAFAB.6000301@CC.UniVie.ac.at> <532D4EA1.6030208@ripe.net> Message-ID: <532D9D79.107@CC.UniVie.ac.at> Thanks Robert, now works like a charm :-) Just out of curiosity - is the probe ID a link only during those periods when it is "down"? Asking because I have another one (ID = 12711) which is "up" and the Id isn't clickable. Low prio, just trying to understand what the algorithm is. Cheer, Wilfried. Robert Kisteleki wrote: > Wilfried, > > Thank you for the report, this is now fixed. > > Regards, > Robert > > > On 2014.03.21. 22:31, Wilfried Woeber wrote: > >>Hi folks, >> >>I had a look at the list of my ambassador probes and noticed that one of >>them is currently listed as being off-line (ID 12734) >> >>The probe ID is rendered as a link, with this URL: >> >>https://atlas.ripe.net/ambassadors/probes/%7B%%20url%20'probe-detail'%20pk=record.prb_id%20%7D%7D >> >>which comes back with >>" >>Bad Request >> >>Your browser sent a request that this server could not understand. >>" >> >>Just fyi, no harm done :-) >>Cheers, >>Wilfried >> >> > > From lhestina at ripe.net Mon Mar 24 14:22:58 2014 From: lhestina at ripe.net (Lia Hestina) Date: Mon, 24 Mar 2014 14:22:58 +0100 Subject: [atlas] Ennit Server (DE) has joined RIPE Atlas anchors Message-ID: <10214128-CE38-4BEC-BB76-D4A74FE98082@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-kel-as13101 and it is hosted by Ennit Server in Kiel, 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 -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2622 bytes Desc: not available URL: From mgalante at ripe.net Tue Mar 25 13:12:02 2014 From: mgalante at ripe.net (Michela Galante) Date: Tue, 25 Mar 2014 13:12:02 +0100 Subject: [atlas] ATI (TN) has joined RIPE Atlas anchors Message-ID: 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 tn-tun-as5438 and it is hosted by ATI in Tunis, Tunisia. Our congratulations to ATI! This is the first anchor in Africa. 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 mgalante at ripe.net Wed Mar 26 14:18:58 2014 From: mgalante at ripe.net (Michela Galante) Date: Wed, 26 Mar 2014 14:18:58 +0100 Subject: [atlas] MWEB (ZA) has joined RIPE Atlas anchors Message-ID: 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 za-jnb-as10474 and it is hosted by MWEB in Johannesburg, South Africa. Congratulations to MWEB! We have now a total of 50 active RIPE Atlas anchors! 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 mgalante at ripe.net Fri Mar 28 12:04:06 2014 From: mgalante at ripe.net (Michela Galante) Date: Fri, 28 Mar 2014 12:04:06 +0100 Subject: [atlas] LACNIC (UY) has joined RIPE Atlas anchors Message-ID: 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 uy-mvd-as28000 and it is hosted by LACNIC in Montevideo, Uruguay. Congratulations to LACNIC! This is the first anchor in Latin America and the first one hosted by an RIR on behalf of the RIPE NCC. 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 BECHA at ripe.net Sun Mar 30 12:30:00 2014 From: BECHA at ripe.net (Vesna Manojlovic) Date: Sun, 30 Mar 2014 12:30:00 +0200 Subject: [atlas] Use case for RIPE Atlas: DNS service disruption in Turkey Message-ID: <5337F228.7040004@ripe.net> Dear all, one of our most active users, Stephane Bortzmeyer, performed RIPE Atlas (and other) measurements to collect the data for his analysis, published in a blog post yesterday: "Hijacking of public DNS servers in Turkey, through routing" http://www.bortzmeyer.org/dns-routing-hijack-turkey.html Thank you for this interesting use-case! This is a call for the rest of the community to let us know if you have done some measurements or analysis to solve your problem, or to better understand a network-event - please share it with us. We are also interested in re-publishing your stories on RIPE Labs. You can find the previous articles here: https://labs.ripe.net/atlas Regards, Vesna From georg.chytil at nextlayer.at Mon Mar 31 12:46:23 2014 From: georg.chytil at nextlayer.at (Georg Chytil) Date: Mon, 31 Mar 2014 12:46:23 +0200 Subject: [atlas] Net Neutrality measurements Message-ID: Dear collegues, I sympathize with the cause for net measurements, and the RIPE Atlas project in particular. I?d like to draw your attention to the use of net measurement infrastructure as a means of documenting net neutrality, and a consulation of BEREC in this context: http://berec.europa.eu/eng/news_consultations/ongoing_public_consultations/2098-public-consultations-on-the-on-the-draft-berec-report-on-monitoring-quality-of-internet-access-services-in-the-context-of-net-neutrality I?d appreciate if RIPE got involved in this field before less desireable and competent parties do ;-) Maybe comment on net neutrality on https://atlas.ripe.net/about/future-plans/ ? Kind Regards #g From jeroen at dckd.nl Mon Mar 31 13:06:41 2014 From: jeroen at dckd.nl (Jeroen van der Ham) Date: Mon, 31 Mar 2014 13:06:41 +0200 Subject: [atlas] Net Neutrality measurements In-Reply-To: References: Message-ID: Hi, I actually have some experience in this, and it is not as easy as you would think. We did this as part of an activity of ISOC-NL which has a Internet Transparancy workinggroup. Do you have any contacts for this? Jeroen. On 31 Mar 2014, at 12:46, Georg Chytil wrote: > > Dear collegues, > > I sympathize with the cause for net measurements, and the RIPE Atlas project in particular. I?d like to draw your attention to the use > of net measurement infrastructure as a means of documenting net neutrality, and a consulation of BEREC in this context: > > http://berec.europa.eu/eng/news_consultations/ongoing_public_consultations/2098-public-consultations-on-the-on-the-draft-berec-report-on-monitoring-quality-of-internet-access-services-in-the-context-of-net-neutrality > > I?d appreciate if RIPE got involved in this field before less desireable and competent parties do ;-) > > Maybe comment on net neutrality on https://atlas.ripe.net/about/future-plans/ ? > > Kind Regards > > #g > > From BECHA at ripe.net Mon Mar 31 15:39:15 2014 From: BECHA at ripe.net (Vesna Manojlovic) Date: Mon, 31 Mar 2014 15:39:15 +0200 Subject: [atlas] Use case for RIPE Atlas: DNS service disruption in Turkey In-Reply-To: <5337F228.7040004@ripe.net> References: <5337F228.7040004@ripe.net> Message-ID: <53397003.6000608@ripe.net> ... and today a new article by Emile Aben was published on RIPE Labs: "A RIPE Atlas View of Internet Meddling in Turkey" https://labs.ripe.net/Members/emileaben/a-ripe-atlas-view-of-internet-meddling-in-turkey Regards, Vesna From hsalgado at nic.cl Mon Mar 31 15:39:23 2014 From: hsalgado at nic.cl (Hugo Salgado) Date: Mon, 31 Mar 2014 10:39:23 -0300 Subject: [atlas] Net Neutrality measurements In-Reply-To: References: Message-ID: <5339700B.8030609@nic.cl> Hi. Even when it's a legitimate and laudable use of probes, I'd prefer Atlas itself wouldn't take a "political" side and keep the project only in a technical sense. The use that someone gives to the probes is a separate issue. I'm worried that saying explicitely that atlas probes are a device to test network neutrality, could make it to be banned in the same countries we're trying to observe. Regards, Hugo On 03/31/2014 07:46 AM, Georg Chytil wrote: > > Dear collegues, > > I sympathize with the cause for net measurements, and the RIPE Atlas > project in particular. I?d like to draw your attention to the use > of net measurement infrastructure as a means of documenting net > neutrality, and a consulation of BEREC in this context: > > http://berec.europa.eu/eng/news_consultations/ongoing_public_consultations/2098-public-consultations-on-the-on-the-draft-berec-report-on-monitoring-quality-of-internet-access-services-in-the-context-of-net-neutrality > > > I?d appreciate if RIPE got involved in this field before less desireable > and competent parties do ;-) > > Maybe comment on net neutrality on > https://atlas.ripe.net/about/future-plans/ ? > > Kind Regards > > #g > > >