Hi Robert/Stephen First of all, thank you for writing all of this up and attempting to clear up a bit of a grey area on RIPE Atlas. I understand that a lot of people have been operating in this grey area for quite some time now so it's nice to have some clarification.
Tl;dr As far as me+bgp.tools is concerned, this is a good middle ground, however I am worried about the long term deployment impacts on Atlas as a result of this. For my own interests (bgp.tools that is) the proposed changes are fine (maybe some anxieties around what are the requirements to become a sponsor and what costs that entails), I am happy from the point of view of bgp.tools to provide some kind of user identification, but it will have to be quite vague as to comply with various privacy laws around Europe such as GDPR ( to my own understanding ). But I understand the spirit of the scheme is to ensure that ripe does not lose visibility of how many users are using atlas in which case I can likely provide a token that fulfils that purpose May I also suggest that for the good of the internet ( and researchers ), that we put a secondary requirement that all measurements performed through aggregators are publicly visible? This feels more than reasonable given that a user itself is not directly contributing towards RIPE atlas improved visibility. I do have some general concerns that part of the driving force behind RIPE Atlas is people installing probes onto their network so they could use the network itself, obviously with public aggregation the requirement and thus motivation for them to install atlas probes into their network is decreased, in the long haul ( if true ) this will harm the RIPE Atlas project quite severely, RIPE Atlas I believe is one of the best measurement networks available right now but I assume there is a relatively high degree of attrition on probes. So is this worth keeping in mind? Thanks Ben On Mon, Dec 11, 2023 at 4:49 AM Stephen Strowes via mat-wg <mat-wg@ripe.net> wrote: > > Hi folks, > > Bumping this thread in case you missed this one, too: > > The topic of third-party RIPE Atlas service aggregators was also on the > agenda at RIPE87. We'd like to see discussion continue either here on the WG > mailing list, or on the forum, or privately back to the NCC if you prefer. > > The materials for this discussion are here: > > - Recording: https://ripe87.ripe.net/archives/video/1176/ > - Slides: > https://ripe87.ripe.net/presentations/13-kisteleki-MATWG-RIPE87.pdf, slides > 14 & 15 > - Labs post: > https://labs.ripe.net/author/kistel/the-role-of-aggregators-in-ripe-atlas/ > > > Cheers, > > S. > > > On Wed, Nov 22, 2023 at 11:43 AM Robert Kisteleki <rob...@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 >> >> -- >> >> To unsubscribe from this mailing list, get a password reminder, or change >> your subscription options, please visit: >> https://lists.ripe.net/mailman/listinfo/mat-wg > > -- > > To unsubscribe from this mailing list, get a password reminder, or change > your subscription options, please visit: > https://lists.ripe.net/mailman/listinfo/mat-wg -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/mat-wg
