This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[atlas] The role of aggregators in RIPE Atlas
- Previous message (by thread): [atlas] The role of aggregators in RIPE Atlas
- Next message (by thread): [atlas] RIPE NCC measurement data retention
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Steve Gibbard
scg at gibbard.org
Wed Nov 22 19:12:20 CET 2023
> On Nov 22, 2023, at 8:43 AM, Robert Kisteleki <robert at ripe.net> wrote: > > Dear all, > > We've just published a proposal about recognising the role of "aggregators" in RIPE Atlas: https://labs.ripe.net/author/kistel/the-role-of-aggregators-in-ripe-atlas/ > > We would be very happy to see discussions about this here on the mailing list, on the RIPE NCC Forum, or live at RIPE87. And from the referenced web page: > • They would need to explicitly identify the account they use for this purpose. This one is easy. > • They would need to separate their “own use” of RIPE Atlas from the aggregator role - i.e. if an organisation uses RIPE Atlas for their own NOC staff as well as offer services to their clients, these would need to be separate accounts in the service. Likewise, Global Traceroute would have no issues complying with this. It is currently running in my personal account, but I haven’t done a non-Global Traceroute Atlas query in years. One thing to be conscious here is that the account needs Atlas credits in order to run, at least under the current model. This means the role account would ideally be able to own probes, in addition to being able to receive transfers from other sources. If the probes need to be owned by a different account, that would be some extra overhead to keeping the role account funded. > • They would need to provide identification of their clients towards RIPE Atlas. The exact form of this needs to be defined, but it should be unique to their clients (some ID, hash of an email address, obfuscated IP address, …) We don’t require users to log in (although we provide some extra features to users who do). So a hashed or obfuscated IP address is what we could provide consistently, while more unique identification would be sporadically available. There may also be privacy considerations to take into account here, so I’m hoping the requirement can be kept sufficiently minimal that I don’t have to hire legal counsel to tell me how to safely comply… But I should also note, for purposes of not discouraging new projects, that gathering all this data (to enable various history features) required rewriting a large portion of the original Global Traceroute. It started out as a “let’s see if I can make this work,” and then, “it works, so I guess I might as well share it” project. The original version was a pure passthrough that retained no data. The user IP address would have been the only identifier I could have easily provided at that point. > • Perhaps (TBD) they should even step up as official sponsors of RIPE Atlas. This is where I hope you’ll be careful about not discouraging personal/hobby projects. I’d be happy to provide percentage of Global Traceroute’s revenue, but so far that’s zero. If you were to charge a fixed fee, it’s possible that that would be the necessary hook to get some of the larger users (who are companies with money) to start paying, but given the level of success I’ve had so far in attempting to even get this to cover its own hosting costs, it’s more likely that it would push me to give up and turn the thing off. -Steve On behalf of Global Traceroute https://www.globaltraceroute.com <https://www.globaltraceroute.com/>
- Previous message (by thread): [atlas] The role of aggregators in RIPE Atlas
- Next message (by thread): [atlas] RIPE NCC measurement data retention
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]