The role of aggregators in RIPE Atlas
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. Regards, Robert Kisteleki RIPE NCC
On Nov 22, 2023, at 8:43 AM, Robert Kisteleki <robert@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/>
On Wed, 22 Nov 2023 at 17:43 Robert Kisteleki <robert@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.
Regards, Robert Kisteleki RIPE NCC
-- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Looks good! The only things I can think of that could be discussed are: 1. Separating own use from service use through different accounts - here I'd rather see something like a service account tied to an existing account instead, only usable through the API, with credits taken from the owner account. Makes it so you don't need to juggle credit transfers, especially if you end up owning multiple aggregators. 2. Client identification is a touchy subject under GDPR, especially for hobbyist projects like the one I'm making. Best I could offer is a unique ID that *may* be stable, but most likely rotates regularly. 3. Regarding "official sponsors", any policy that will require me to spend money will kill this project. I already support Atlas with a probe :) /Sebastian
participants (3)
-
Robert Kisteleki
-
Sebastian Johansson
-
Steve Gibbard