Hello Metrics WP members,

As I've looked into each definition of the measurement and aggregation of
the RSS related metrics to find out the thresholds, I came up with the
strong thought that these definition need to be corrected or redefined.

Current definitions of the RSS related metrics is just a gathering of the
outcome of the RSO metrics.  However, what we want to describe is how
RSS as a whole looks in the measurement.

For example, about the RSS Availability, once any of the responses time
out, the avaliability of the RSS as a whole will not be 100%.  This is
not true, since RSS as a whole at the time of the measurement is avaliable
if any of the 13 RSOs response to the queries.  Gathering the result of
this determination for one day would work for the availability of RSS
through the day.

For the RSS Response Latency, each RSOs may have the different strategy
of the deployment of the anycast locations, and those will cover the
whole world collectively.  The response latency for RSS as a whole seen
from certain vantage point at certain time cannot be describe by the
median of the response.
It is much more better to select the minimum response time or perhaps 10
percentile or such.

I believe there was this kind of discussions before, but current
document does not reflect this way. 
Ozan's discussion slides has just been posted, and I found that RSS
Availability part is considered there.  But RSS Response Latency part is
still not.

Regards,

Shinta Sato <shinta@jprs.co.jp>
Japan Registry Services Co., Ltd.

On Fri, 13 Sep 2019 15:11:18 +0000
Paul Hoffman <paul.hoffman@icann.org> wrote:

> On Sep 13, 2019, at 7:58 AM, Shinta Sato <shinta@jprs.co.jp> wrote:
> >
> > The rationale for each measurement has been discussed in the WP, but I
> > don't beleive that the importance or relation between each metric was
> > discussed in the context.
>
> This is correct. In some of the informal conversations, some people have given some rationale for individual metrics, but the WP has not yet discussed pulling the rationale together or coming to consensus on the rationale. That's why I did my own brain dump, to see if it matches other people's thoughts.
>
> > If we need to take such importance into consideration in finding out the
> > threshold, shouldn't we need additional discussion on this prior to
> > expressing the suggestion of the threshold to the spreadsheet?
>
> Maybe the discussion can happen at the same time. The WP leaders want to have some ideas of what people want in the spreadsheet in order to start good discussion on the next call, but those ideas don't need to be at all final.
>
> > In addition, the importance has only suggested for the RSO metrics.  The
> > importance for RSS metrics would need another discussion as well.
>
> So far, I am unable to come up with any technical or procedural justification for RSS thresholds. It is useful to collect the metrics, but I have tried to come up with some threshold ideas and just failed.
>
> > If these are already discussed before, I'd like to see the minutes,
> > transcripts or whatever, as I did miss some meetings.
>
> The rationale ideas I posted are new. I'm hoping others will do similar postings, or at least poke holes in the one I did.
>
> --Paul Hoffman


_______________________________________________
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://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). 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.