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" ?

- To make it clearer that root zone size is not being measured by the RSOs, I propose moving that entire discussion to its own section.

That's fine with me.

- A second root zone metrics that might be measured is "number of records changed". It will always be at least 1 (for the SOA), but it might be useful to know how many root zones are just changing the SOA versus changing actual data.

This is problematic. There is no readily available in-server metric and/or log that contains this information.

- The DNS community would probably like to watch the adoption rate for QNAME minimization. To measure that, I propose a new RSO measurement: number of queries that are single-label requests that result in NOERROR responses. The latter part would eliminate effects of things like Chrome asking for more names. I recognize that this idea might not be popular for RSSAC, but it would be one of the best ways for the DNS community to measure uptake of the protocol.

I'm also against this. It pre-supposes that either an on-the-wire DNS monitoring system or in-server metrics to measure this are deployed. 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. kind regards, Ray

On 19/08/2019 16:38, Paul Hoffman wrote:

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.

That works for me.

...

This is problematic. There is no readily available in-server metric and/or log that contains this information.

Creating the metric is trivial. In fact, there is already a Twitter account that exists pretty much for it.

Indeed, but that Twitter account is maintaining copies of the root zone, and then performing a "diff" each time it changes. This requires state. Since receiving an XFR is an autonomous function of a name server (and which is stateless in the case of AXFR) capturing the change count at each RSO would require additional software and/or systems, and in theory they should all just give out the same answer anyway. If it were to be done, just have the RZM do it (but see below).

That view seems reasonable to me, but then it would argue for the removal of the root zone size metric as well.

The theory was that a large zone *might* affect stability, therefore it's important to know the history of the zone's size. AFAICR, 002v3 removed the requirement for every RSO to measure the root zone such that only the RZM has to report it. There's no formal archive of the "root zone history" run by either IANA or the RZM, although DNS-OARC maintains an informal one. The zone size metric is therefore the most easily obtainable official public measure. cheers, Ray

On Mon, 19 Aug 2019 15:38:19 -0000, Paul Hoffman wrote:

On Aug 19, 2019, at 8:23 AM, Ray Bellis <ray@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

On Aug 19, 2019, at 6:27 PM, YAN Zhiwei <yanzhiwei@cnnic.cn> wrote:

I think we may need to consider the adoption situation of new technologies from the view of root servers, such as new transport protocols (QUIC) and DoT/DoH and RFC7816...... although some have not been widely deployed yet.

Ditto Paul's thoughts. At the moment, the root servers accumulate and report the statistics to an RSO-central service, which is then converted to a single YAML file (summing up tens or hundreds of server's observations) and uploaded to root-servers.org. Whether QUIC or whatever is used by a given RSO is pretty much up to that RSO. If there is a desire to support QUIC as an access transport on root-servers.org, that could probably be accommodated, but it's a different question. The use of DoT or DoH for DNS service from the root servers themselves might be a more interesting question. RSSAC001 only discusses the use of DNS (as in RFC 1034/5 as updated); the resolvers haven't asked for DoT/DoH. My understanding is that the DoT/DoH specifications are currently limited to stub resolvers as opposed to services such as the DNS Root, and the obvious software hasn't necessarily been updated to directly support it. I suspect there are scaling issues with perpetual pipelined transport sessions...