<div dir="ltr">Hi Robert, all:<div><br></div><div>I was considering emailing about the possibility of HTTP measurements to our <a href="https://peering.ee.columbia.edu/" target="_blank">PEERING</a> testbed when I stumbled on the five proposals that Robert posted in December.</div><div><br></div><div>I want to express my strong support for the two HTTP proposals. Hourly [CDN-HTTP] would be great (eventually with HTTPS support). </div><div><br></div><div>([STARTTLS] also sounds good, but I haven't thought deeply about it, and [ONLY-PUBLIC] sounds good unless it costs RIPE Atlas support / probe hosts)</div><div><br></div><div>I was wondering about the feasibility of allowing HTTP measurements towards PEERING experiments (meaning, towards our address space announced from an experiment via our routers). Is that something that you might be open to supporting?</div><div><br></div><div>This came to mind because we are in the process of onboarding PEERING to some bring-your-own-prefix services offered by CDNs and cloud providers, and so an increasing number of PEERING experiments are about content delivery/cloud hosting, and it would be great if RIPE Atlas could act as measurement clients to provide widespread vantage points.</div><div><br></div><div>One hands-off option that comes to mind is to set them up similar to the proposal for CDN-HTTP, where probes will regularly fetch an object at a fixed URL, say <a href="http://ripeatlas.ee.columbia.edu/testobject" target="_blank">http://ripeatlas.ee.columbia.edu/testobject</a>. Normally, that could resolve to our project webserver, which is hosted in AWS. When an experiment needs this HTTP capability (all experiments undergo review by at least 2 people for safety, and we enable only the capabilities they request and need, following the principle of least privilege), we could instead redirect it to a PEERING address allocated to the project that would host the same test object but that would be announced from cloud/CDN/PEERING sites however the experiment had configured. Alternatively, it could be a measurement available to approved accounts, and we could pass on which experiments are approved, or perhaps available to all accounts. We have fixed address space, if you have a way to whitelist. We maintain our list of prefixes as RS-PEERING-TESTBED on RIPE's IRR.</div><div><br></div><div>I believe Johan recently contacted Kevin Vermeulen about talking to us about RIPE Atlas in the context of another one of our projects, so possibly we can have a discussion covering both topics.</div><div><br></div><div>Thanks for all your work providing the platform -- it's great!</div><div><br></div><div>Ethan</div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><a href="http://www.columbia.edu/~ebk2141/" target="_blank">http://www.columbia.edu/~ebk2141/</a><br></div></div></div>