[RSSAC Caucus] Revisiting RSSAC002v3

[John Heidemann]

On Mon, 19 Aug 2019 15:38:19 -0000, Paul Hoffman wrote: 
>On Aug 19, 2019, at 8:23 AM, Ray Bellis <ray at isc.org> wrote:
>> 
>> On 19/08/2019 16:03, Paul Hoffman wrote:
>> 
>>> - v3 uses the term "latency" in a way that that is very different
>>> from that which the Metrics Work Party is. In the v3 document,
>>> "latency" is the delay in publication of a new root zone, whereas in
>>> the Metrics WP document, "latency" is the amount of time it takes for
>>> a response to a DNS query to be received. The latter is the much more
>>> common usage of "latency" in the DNS world. The Metrics WP document
>>> uses "staleness" for the concept from v3. I propose that v4 start
>>> using "staleness" to match the more common usage in the DNS world.
>>> Note that the metric doesn't need to be renamed: it remains
>>> "load-time", which is different than either "latency" or
>>> "staleness".
>> 
>> I don't like "staleness" either.
>> 
>> "stale" is already overloaded by the "serve-stale" model, where in that context "stale" really means "this zone is mouldy, use at your own risk" rather than "this zone isn't *quite* as fresh as it should be".
>> 
>> (in other words, a zone is not IMHO "stale" until its expiry timer has elapsed)
>> 
>> Why not just qualify latency as "publication latency" ?
>
>This is possible if the Metrics WP also changes "latency" to "response latency" and "staleness" to "publication latency". The two documents would then align, and the community would more likely understand that there are two types of latency.

I strongly agree with this direction; it's much clearer to add a subject
descriptor to the word "latency" rather than try to get another
stand-alone word and leave the subject implicit.

>...
>
>> So long as wire-sniffing systems remain viable a long term view of this can be gleaned from DITL data, even if it is only sampled once a year.
>> 
>> On a more general note, my take on RSSAC 002 (and I said so vociferously during the v3 discussion) is that it was not intended for answering arbitrary research questions.  That just becomes a never-ending list of "wouldn't it be nice if..." discussions.
>
>That view seems reasonable to me, but then it would argue for the removal of the root zone size metric as well.

I think that was the consensus from the RSSC002v3 discusion, which I
believe demoted zone size to be something to something that need not be
reported by all operators.

It has seemed helpful in the past to focus RSSAC002 on
operationally-relevant questions that need to be measured continously,
and to leave to research (DITL, etc.) questions that can be answered
there using intermittent or partial data.

(I do hope we answer research questions, too.  Just not with RSSAC002,
but with measurements that a more agile and less expensive.)

   -John