On 11/01/16 10:39, Daniel Karrenberg wrote:
On 10.01.16 6:17 , Emile Aben wrote:
Hi,
As for the origin of the tag: I set this on my probe as an experiment to see if one could do a poll among probe hosts. Apparently the hosts of 21 other probes already found the tag without it every being advertised.
Now that it is more widely known it would probably be interesting for proponents of BCP38 compliance-testing to set that probe-tag, and for opponents to set the 'idontwantbcp38compliancetesting' probe-tag.
In general I like creative use of the RIPE Atlas system. I could see the use of a "SourceAddressSpoofOK" tag that says it would be OK to spoof source addresses when sending traffic from this probe. This kind of opt-in statement has meaning. It would also be a constructive way to get around the risks associated with source address spoofing from probes of unsuspecting hosts.
However doing a poll by setting probe tags which are meant to convey attributes of the probe and not opinions of the host is not really useful. This is aggravated by the lack of a clear definition for the meaning of this tag.
dismissing this as useless is a bit premature i think. this is an experiment about how to get community feedback, tied to specific resources (ripe atlas probes) this community has (ie. one vote per probe). if the number of people that 'vote' is insignificant the conclusion is that my attempt of collecting feedback didn't work. as to meaning of the tag: as you said yourself the tag conveys the opinion of the probe host. what may be unclear is if the probe host would be ok with bcp38 tests from their own probes. my assumption is they are (i probably should have made the tag 'iwantbcp38compliancetestingonthisprobe', but thought that rather long). currently there are 37 probes with 'iwantbcp38compliancetesting' set, so in case ripe atlas would have 'bcp38-compliance testing' as an opt-in measurement, this would likely be the lower bound of the probes that would be opted-in. emile ps: i think the definition problem is more with spoofing vs. bcp38-compliance testing. spoofing doesn't necessarily involve all involved parties' agreement, while i think a bcp38-compliance test could (should?). personally, as a probe host, i would *not* want all spoofing being made possible from my ripe atlas probe, but i would be ok with bcp38-compliance testing, especially if all involved parties are ok with sending bcp38 test packets. involved parties: - probe host - holder/user of src address for a bcp38 test packet - holder/user of dst address for a bcp38 test packet and i think we can create circumstances where we can actually make all these parties agree. having a probe host opt-in (like my tag implies, but could be more explicit like you suggest) and by having fixed src/dst address space being used for these tests (or have probe public ip addresses of hosts that agree being used in tests?).