On Feb 24, 2020, at 21:10, John Heidemann <johnh@isi.edu> wrote:
On Mon, 24 Feb 2020 10:45:37 +0000, Andrew McConachie wrote:
On Feb 21, 2020, at 23:52, Ray Bellis <ray@isc.org> wrote:
On 21/02/2020 22:33, Paul Hoffman wrote:
Just to be clear: are you saying that you can only produce figures for Section 3.5 (number of sources seen) for a subset of your nodes, or that you can only produce figures for a subset of your nodes for *all* the measurements? If the latter, that's going to mess up the evaluation of the measurements for the whole RSS. Even if it is just the former, that will make the measurements in Section 3.5 be not comparable to the other sections.
Only for the unique sources measurement.
Hi Ray,
I changed section 6.6 to mark the ‘unique-sources’ metric as optional. This is reflected in the changelog as well.
This change means that if the 'unique-sources' metric is produced by an RSO they must provide values for both 'num-sources-ipv4' and 'num-sources-ipv6-aggregate’. So produce values for both or produce values for neither.
I would like to hear from other RSO’s if this approach is OK or if a different approach is needed.
Ray asked the important question: is this metric useful.
Wearing my "researcher" hat: yes, we have found number of unique-sources in RSSAC data useful to indicate when a RSO is subject to an attack with spoofed sources.
But I can understand the challenge in computing this metric. It is by far the most stressful (least compressible).
Rather than just declaring the metric optional, what about declaring the precision of the answer variable? Perhaps adding a "fraction-of-traffic-for-sources" field, which for some RSOs would be 1 and others might be less than 1? There is value in a num-sources even if it's based on a 10% sample of traffic, or 10% of anycast sites, and a sampled value might be easier for some RSOs to compute.
(And yes, I recognize that sampling could be non-uniform.)
-John
Hi John, I think the idea of a percent-instances-sampled makes a lot of sense, I’m just concerned about adding it this late in the process of RSSAC002v4. Is it OK to postpone this suggestion until RSSAC002v5? I can imagine a fair amount of discussion surrounding how exactly to measure precision given the different operating environments. —Andrew
Thanks, Andrew
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_p... ) and the website Terms of Service (https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_t... ). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.