[mat-wg] Feedback on draft RIPE Atlas Service Terms and Conditions
Wilfried Woeber Woeber at CC.UniVie.ac.at
Tue Sep 16 13:36:50 CEST 2014
First of all, thanks to the Atlas folks for getting us involved in the review of the proposed T&C for the production service, and thanks to Adam for getting the ball rolling :-) Just to set the stage: I do host two probes and one Anchor, I signed up as an ambassador and I have been strongly in favour of the project. But, as this draft text is obviously set against a strong legalese background, I have to switch to that mode, too. In addition to the observation by Adam regarding 7.1 and 7.2 I'd like to make the comment regarding 10.1 even stronger: The User/Host is required to always have a correct registered email addrss, thus it seems to be reasonable to actively alert this user community about upcoming changes as an "info-push-service", rather than a "pull-service". On top of that, I think it would be responsible to allow for -say- 30 days advance notice before changes apply "automatically", rather than "immediately". But even more fundamental is the interaction of proposed 8.4a .. 8.4e versus Article 9. I can understand what the goal and the intention is, from the NCC's point of view, but I think it is not acceptable for me, as it stands right now. I even doubt that those provisions would hold up in court, if one of the parties is a private person ("consumer"). Within the same realm, the strict definition of Article 11, with 9.5 (and 9.7) is a no-go, imho. On the more editorial plane, I like to suggest to - s/critical Internet infrastructure/important Internet infrastructure/ as Critical Infrastructure is a heavily loaded term already in some countries, - check or rephrase the "email addresses of probes" in 4.4 - add a reference to the Anchor MoU in 6.1 - finally check the use of "liability" in 8.1: "...NCC may suspend its operation, avalability or liability to the Users" Hth, cheers, Wilfried Adam Piggott wrote: > Hello, > > Having read the draft I find the T&Cs quite sensible but have some > points to bring up. > > 7.1. [...] The RIPE NCC may perform security checks and audits to > determine unauthorised use of the RIPE Atlas Service. > 7.2. Users must assist the RIPE NCC with security checks and audits. > > These are a very open-ended statements and I'm sure that RIPE NCC has no > intention of visiting our homes or places of work to perform "security > checks and audits". The terms are written in a "legalese" form of > language and hence must be taken at face value by those who accept them. > I would not be comfortable agreeing to these two points without some > sort of clarification as to what "security audits and checks" could be, > and what "assistance" I would be obliged to provide. > > > 10.1. All the RIPE Documents referred to in this agreement are available > on http://www.ripe.net/. The Probe Host will regularly take notice of > updated RIPE Documents on the website. > > I cannot accept this term. I can only accept to be bound to new terms if > they are sent to me directly, for example by email. Article 2.3 seems to > infer that RIPE NCC will indeed contact users directly at least 30 days > in advance, which is acceptable. > > > Thanks to RIPE NCC for including the community in such an important > process.
[ mat-wg Archives ]