On Thu, Sep 12, 2019 at 1:11 PM Wessels, Duane via rssac-caucus <rssac-caucus@icann.org> wrote:
On Sep 12, 2019, at 8:01 AM, Andrew McConachie <andrew.mcconachie@icann.org> wrote:
Dear RSSAC Caucus,
Thanks to everyone who contributed to the discussions around updating RSSAC002. Based on this feedback the RSSAC Admin Committee suggests the following list of topics to be covered in the update.
Draft Topics List: A) Agree to new terminology around 'latency' B) Discuss removing root zone size measurements C) Discuss adding metric to measure number of resource records changed between zone updates D) Discuss adding metric to measure QNAME minimization
Andrew,
My apologies for not participating in the earlier discussion (happened when I was out on PTO).
To me (B) and (C) seem at odds. From reviewing that earlier discussion I don't think there was really a lot of support for removing the zone-size metric? It was more a matter of having metrics related to the zone content being reported by the RZM only. Assuming this is the direction we take, RSSAC002 would probably benefit by placing RSO vs RZM metrics into separate sections.
I think I'm probably missing a bunch of background here, and like Duane am confused by B and C. Oh, and also A and D... A: What is the new terminology that we would be agreeing to? I'm assuming that the text has been shared somewhere and I lost track of it. B and C *do* seem at odds -- but I must admit I'm also confused. Seeing as the same zone file should be served by everyone, why wouldn't it be reported from a single, central system (instead of each reporting separately)? Or is that the proposal and I misunderstood? And if it is intended to ensure that everyone is using the same file, filesize and "number of resource records changed between zone updates" seems like an add way to do that and e.g SHA-xxx(zonefile) would be a better metric. D: I'm also confused here (again, apologies and happy to read documentation if you can point at it) -- what exactly does this mean / entail? I made some guesses, and it sounded like "calculate a ratio of number of queries for a TLD vs number of queries for second level or longer" -- this is, I think, very different to any of the other metrics. I don't think that any of the standard nameserver software reports this, and it seems tricky / onerous to do as a sidecar (as a side-note, it *does* seem like it might be a useful metric for nameserver implementations to start reporting though!). Perhaps I completely misinterpreted the suggestion though, so... Once again, apologies if I missed a "background" type mail... w
Early last year Jerry from DNS-OARC worked on an RSSAC002v3 implementation and found some areas of ambiguity and other things that could be fixed in the next revision. The thread is here: https://github.com/DNS-OARC/dnscap/issues/152. IMO it would be good to address these if possible.
DW
_______________________________________________ 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.
-- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf