[rssac-caucus] Tweaks to RSSAC-002

[Shane Kerr]

Ray and all,

Thanks for some background and additional information. Replies
inline, below...

At 2016-08-31 09:17:55 +0100
Ray Bellis <ray at isc.org> wrote:

> On 31/08/2016 08:35, Shane Kerr wrote:
> > Hello all,
> > 
> > I love RSSAC-002, but have had a few small pain points consuming the
> > data that some of the root operators provide. I suggest that it might be
> > good to make RSSAC-002bis to improve things.  
> 
> We're already on v3 - is that the version you're reading?
> 
> <https://www.icann.org/en/system/files/files/rssac-002-measurements-root-06jun16-en.pdf>

I was reading this one:

https://www.icann.org/en/system/files/files/rssac-002-measurements-root-20nov14-en.pdf

That's the one that DuckDuckGo returns, the one that Google returns,
and the one that ICANN's web site returns when you search for "rssac
002".

Where is the repository for RSSAC documents?

The https://www.icann.org/en/system/files/files/ directory does not
return a file list. (BTW, I love "system/files/files" in a path...) :-D

In any case, I think that makes my first suggestion:

0. Include a URL where to find the latest version of the document.

   For consistency, I suggest:

   https://www.icann.org/en/system/files/files/latest/latest/latest/rssac-002-measurements-root-sever-system-files-latest-en.pdf

> > 1. It would be helpful if there was a standard starting URL for
> >    these. I know section 4.7 defines the standard, but the starting
> >    point is different with 5 different styles for 8 operators.
> > 
> >     'a': 'http://a.root-servers.org/rssac-metrics/raw/',
> >     'b': 'http://b.root-servers.org/rssac/',
> >     'c': 'http://c.root-servers.org/rssac002-metrics/',
> >     'd': 'http://droot-web.maxgigapop.net/rssac002/',
> >     'h': 'http://h.root-servers.org/rssac002-metrics/',
> >     'j': 'http://j.root-servers.org/rssac-metrics/raw/',
> >     'k': 'https://www-static.ripe.net/dynamic/rssac002-metrics/',
> >     'l': 'http://stats.dns.icann.org/rssac/',
> >     'm': 'https://rssac.wide.ad.jp/rssac002-metrics/',
> > 
> > 2. It would be nice if there was an SSL way to get the data everywhere.
> >    I know it may be hard for Verisign to get a certificate since they
> >    left the CA business, but we all have Lets Encrypt now. ;)  
> 
> DNS-OARC is collecting all of the data for central aggregation.  I can't
> tell from the site just now how access to that data is obtained.

Ah, now I see this:

    "RSSAC recommends that these measurements be collected in a central
    location and stored in a common format for ongoing analysis. The
    collection location, and the frequency this data is uploaded to the
    central location are out of scope of this document."

I searched just now and saw the DNS-OARC announcement:

https://www.dns-oarc.net/node/348

Is this related to the recommendation? Does anyone know?

As for where it is... maybe you have to ask for it if you are not a
member? I wonder if this shouldn't just be public? (Speaking
representing an OARC member, although I realize this is the wrong
forum...)

> > 3. Some operators seem to have stuff not defined by RSSAC-002 in their
> >    directories. For example, several have PNG files in them, others
> >    seem to have debugging or additional directories. It's not a big
> >    deal, but naive scripts have to filter stuff out.  
> 
> If you're parsing directory listings rather than asking for the specific
> named files that you expect, you're doing it wrong ;-)

I rather think more along the lines of using "wget" and then a for loop
over the files in a directory.

Not a big deal, but honestly I tend to think that added things make it
harder on users not easier. (I note that in the YAML itself per-root
extensions are explicitly marked, possibly for this very reason.)

> > 4. While RSSAC-002 says that frequency that reports are generated is
> >    out of scope, everyone but L does it daily so maybe it could just
> >    define that? Surely we can convince L to also generate daily?  
> 
> v3 of the doc does now specify that the data is reported on a 24 hour
> (UTC 00:00) basis.

Yes, but it explicitly doesn't say that it should be done every day.
I'm not sure why L is behind - it could be a policy, could be an
accident of the design, or it could be a bug. In any case, it means
that any comparisons within the 1-6 day time frame will be a bit skewed
since L is not in there (a pity since L is quite a busy server).

> > 5. Most importantly, every page says "Measurements of the Root Sever
> >    System" at the top (s/Sever/Server/). Once seen, cannot be unseen.  
> 
> And yet no one else saw it :p    Oops...
>
> > As a related issue, it sure would be nice if the remaining root
> > operators provided this information. Currently E, F, G, and I don't
> > have links on the http://www.root-servers.org site to this information
> > (I was surprised to see F and I missing, I admit). Maybe they have this
> > somewhere else? How would I know?  
> 
> F is "working on it" - since we don't use pcap for data collection we're
> dependent on the forthcoming 9.11 release of BIND and the stats channel
> (XML / JSON) which has new features to support RSSAC 002.

Cool! As I said I was surprised that F wasn't there, since F seems
relatively open and up to date with its operations. :)
 
> > Also, the web H site with statistics seems down right now. Maybe it
> > would be helpful if ICANN mirrored the data? (That might actually solve
> > my problem of inconsistent directories.)  
> 
> See above.

Yes indeed. Sorry I missed the mirroring recommendation!

Cheers,

--
Shane
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://mm.icann.org/pipermail/rssac-caucus/attachments/20160831/72135d02/attachment.sig>