[rssac-caucus] Tweaks to RSSAC-002
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. 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. ;) 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. 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? 5. Most importantly, every page says "Measurements of the Root Sever System" at the top (s/Sever/Server/). Once seen, cannot be unseen. 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? 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.) Cheers, -- Shane
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-06ju...>
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.
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 ;-)
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.
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.
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. Ray
Ray and all, Thanks for some background and additional information. Replies inline, below... At 2016-08-31 09:17:55 +0100 Ray Bellis <ray@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-06ju...>
I was reading this one: https://www.icann.org/en/system/files/files/rssac-002-measurements-root-20no... 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-m...
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
Hi Shane, On 31/08/2016 10:42, Shane Kerr wrote:
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).
The one week delay is intentional. We have roughly 150 nodes, some of which may occasionally have issues connecting to our centralized storage and processing server, even though they are able to server DNS in there local area without interruption. This delay accounts for any temporary connectivity issue between the edge nodes and our central processing server as well as any scheduled maintenance that may delay transmission of the raw data from the edge nodes. We are constantly looking at ways to decrease the delay, however we need to balance the requirement for timely vs accurate data. Thanks John
John, At 2016-08-31 13:26:16 +0000 John Bond <john.bond@icann.org> wrote:
On 31/08/2016 10:42, Shane Kerr wrote:
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).
The one week delay is intentional. We have roughly 150 nodes, some of which may occasionally have issues connecting to our centralized storage and processing server, even though they are able to server DNS in there local area without interruption. This delay accounts for any temporary connectivity issue between the edge nodes and our central processing server as well as any scheduled maintenance that may delay transmission of the raw data from the edge nodes.
We are constantly looking at ways to decrease the delay, however we need to balance the requirement for timely vs accurate data.
Okay, it makes complete sense. Certainly the large number of nodes is a part of why L gets so much traffic. Does it make sense to document the delay in RSSAC-002? Well, not the entire explanation, but rather something like "Data is usually published within 7 days." Otherwise anyone using the data will have to do the same comparisons that I did and wonder about what they should be expecting. :) Cheers, -- Shane
On 01/09/2016 04:17, Shane Kerr wrote:
Does it make sense to document the delay in RSSAC-002? Well, not the entire explanation, but rather something like "Data is usually published within 7 days." Speaking for my self i don't think that the RSSAC document should contain statements from specific operators. perhaps a more generic statement like
'operators may delay publication of data by up to x days' or 'Operators are required to publish data within x days' Cheers John
John, At 2016-09-01 09:53:14 +0000 John Bond <john.bond@icann.org> wrote:
On 01/09/2016 04:17, Shane Kerr wrote:
Does it make sense to document the delay in RSSAC-002? Well, not the entire explanation, but rather something like "Data is usually published within 7 days."
Speaking for my self i don't think that the RSSAC document should contain statements from specific operators. perhaps a more generic statement like
'operators may delay publication of data by up to x days' or 'Operators are required to publish data within x days'
Oh, I totally agree. I didn't mean that the document should be about L or any other root specifically. :) I am also sensitive that the root operators don't work for ICANN (well, except for L), so the board can't really dictate to them. As such, RSSAC recommendations to the board probably can't say anything like "required". Perhaps we can do something based on your suggestion, like: For normal publication, operators may delay publication of data by up to 7 days. Occasionally publication may be delayed more than 7 days. I hope this says something like "normally you should get stuff in a week, but shit happens". :) Cheers, -- Shane
Shane Kerr <shane@time-travellers.org> writes:
I was reading this one:
https://www.icann.org/en/system/files/files/rssac-002-measurements-root-20no...
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".
And the inventor of Yahoo's original directory-based structure is somewhere trumpeting his horn, as is the inventor of wikipedia where you would always have the correct link rather than "the most popular" which does not always equate to "the most recent".
Where is the repository for RSSAC documents?
ICANN documents as a whole can be challenging to find, to the multiple-versions and archived nature combined with their web infrastructure, which is a typical CMS engine as far as I can tell. The results are searches that don't always point to the most recent document. Instead, I'd suggest searching for "RSSAC publications" which turns up the much more useful and should always be up to date publication list based on release dates: https://www.icann.org/resources/pages/rssac-publications-2014-05-12-en [Note: I have no role over the ICANN pages and the publication process] -- Wes Hardaker USC/ISI
Wes, At 2016-08-31 07:04:37 -0700 Wes Hardaker <hardaker@isi.edu> wrote:
Where is the repository for RSSAC documents?
ICANN documents as a whole can be challenging to find, to the multiple-versions and archived nature combined with their web infrastructure, which is a typical CMS engine as far as I can tell. The results are searches that don't always point to the most recent document.
Instead, I'd suggest searching for "RSSAC publications" which turns up the much more useful and should always be up to date publication list based on release dates:
https://www.icann.org/resources/pages/rssac-publications-2014-05-12-en
[Note: I have no role over the ICANN pages and the publication process]
Thanks for the pointer! My guess is that other people would try a similar process to the one that I used and also end up in the wrong place. Educating everyone in the world seems really hard. Fixing the ICANN pages and publication process is probably easier, but I can easily imagine it taking many months if not years. What seems relatively easy would be to put some text at the top of the document saying: "Please look for the latest version of this document at this page: https://www.icann.org/resources/pages/rssac-publications-2014-05-12-en" It's not great, because a human (or program) still has to search through the list and find the most recent copy, but it at least gives a hint about how to do this. BTW, I love the URL which includes a random date in it, although I am a bit disappointed that it doesn't have "pages/pages" in the path. ;) Cheers, -- Shane
Most date-in-path type things come from CMS systems (wordpress being the leader) that puts a date on every file / article it publishes. I suspect that's what's going on here. I hate to be "not helpful" after trying to be helpful, but I'm not sure who would be responsible for coming up with more permanent URLs for documents. I agree it's a good idea though. On Wed, Aug 31, 2016 at 8:15 PM, Shane Kerr <shane@time-travellers.org> wrote:
Wes,
At 2016-08-31 07:04:37 -0700 Wes Hardaker <hardaker@isi.edu> wrote:
Where is the repository for RSSAC documents?
ICANN documents as a whole can be challenging to find, to the multiple-versions and archived nature combined with their web infrastructure, which is a typical CMS engine as far as I can tell. The results are searches that don't always point to the most recent document.
Instead, I'd suggest searching for "RSSAC publications" which turns up the much more useful and should always be up to date publication list based on release dates:
https://www.icann.org/resources/pages/rssac-publications-2014-05-12-en
[Note: I have no role over the ICANN pages and the publication process]
Thanks for the pointer!
My guess is that other people would try a similar process to the one that I used and also end up in the wrong place.
Educating everyone in the world seems really hard. Fixing the ICANN pages and publication process is probably easier, but I can easily imagine it taking many months if not years.
What seems relatively easy would be to put some text at the top of the document saying:
"Please look for the latest version of this document at this page:
https://www.icann.org/resources/pages/rssac-publications-2014-05-12-en"
It's not great, because a human (or program) still has to search through the list and find the most recent copy, but it at least gives a hint about how to do this.
BTW, I love the URL which includes a random date in it, although I am a bit disappointed that it doesn't have "pages/pages" in the path. ;)
Cheers,
-- Shane
-- Wes Hardaker USC/ISI
Thanks Shane for this feedback! I think this is something staff can implement. "Please look for the latest version of this document at this page: https://www.icann.org/resources/pages/rssac-publications-2014-05-12-en" Best Steve On 8/31/16, 11:15 PM, "rssac-caucus-bounces@icann.org on behalf of Shane Kerr" <rssac-caucus-bounces@icann.org on behalf of shane@time-travellers.org> wrote: Wes, At 2016-08-31 07:04:37 -0700 Wes Hardaker <hardaker@isi.edu> wrote: > > Where is the repository for RSSAC documents? > > ICANN documents as a whole can be challenging to find, to the > multiple-versions and archived nature combined with their web > infrastructure, which is a typical CMS engine as far as I can tell. The > results are searches that don't always point to the most recent > document. > > Instead, I'd suggest searching for "RSSAC publications" which turns up > the much more useful and should always be up to date publication list > based on release dates: > > https://www.icann.org/resources/pages/rssac-publications-2014-05-12-en > > [Note: I have no role over the ICANN pages and the publication process] Thanks for the pointer! My guess is that other people would try a similar process to the one that I used and also end up in the wrong place. Educating everyone in the world seems really hard. Fixing the ICANN pages and publication process is probably easier, but I can easily imagine it taking many months if not years. What seems relatively easy would be to put some text at the top of the document saying: "Please look for the latest version of this document at this page: https://www.icann.org/resources/pages/rssac-publications-2014-05-12-en" It's not great, because a human (or program) still has to search through the list and find the most recent copy, but it at least gives a hint about how to do this. BTW, I love the URL which includes a random date in it, although I am a bit disappointed that it doesn't have "pages/pages" in the path. ;) Cheers, -- Shane
So, I realize that the answer is probably "No", but is there a way that we can get a less "ugly" URL? I have many complaints about the "new and improved" ICANN website, but the current RSSAC documents page URL makes it look like nothing has changed since May 2014... SSAC has https://www.icann.org/groups/ssac/documents -- might we be able to get a "simple" URL for RSSAC too? W On Thu, Sep 1, 2016 at 8:23 PM, Steve Sheng <steve.sheng@icann.org> wrote:
Thanks Shane for this feedback! I think this is something staff can implement.
"Please look for the latest version of this document at this page:
https://www.icann.org/resources/pages/rssac-publications-2014-05-12-en "
Best Steve
On 8/31/16, 11:15 PM, "rssac-caucus-bounces@icann.org on behalf of Shane Kerr" <rssac-caucus-bounces@icann.org on behalf of shane@time-travellers.org> wrote:
Wes,
At 2016-08-31 07:04:37 -0700 Wes Hardaker <hardaker@isi.edu> wrote:
> > Where is the repository for RSSAC documents? > > ICANN documents as a whole can be challenging to find, to the > multiple-versions and archived nature combined with their web > infrastructure, which is a typical CMS engine as far as I can tell. The > results are searches that don't always point to the most recent > document. > > Instead, I'd suggest searching for "RSSAC publications" which turns up > the much more useful and should always be up to date publication list > based on release dates: > > https://www.icann.org/resources/pages/rssac- publications-2014-05-12-en > > [Note: I have no role over the ICANN pages and the publication process]
Thanks for the pointer!
My guess is that other people would try a similar process to the one that I used and also end up in the wrong place.
Educating everyone in the world seems really hard. Fixing the ICANN pages and publication process is probably easier, but I can easily imagine it taking many months if not years.
What seems relatively easy would be to put some text at the top of the document saying:
"Please look for the latest version of this document at this page:
https://www.icann.org/resources/pages/rssac-publications-2014-05-12-en "
It's not great, because a human (or program) still has to search through the list and find the most recent copy, but it at least gives a hint about how to do this.
BTW, I love the URL which includes a random date in it, although I am a bit disappointed that it doesn't have "pages/pages" in the path. ;)
Cheers,
-- Shane
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
-- 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
Hi Warren, This has been changed. The new RSSAC publications URL is: https://www.icann.org/groups/rssac/documents The old URL still works and points to this new URL. Thanks, Andrew On Sep 1, 2016, at 20:35, Warren Kumari <warren@kumari.net<mailto:warren@kumari.net>> wrote: So, I realize that the answer is probably "No", but is there a way that we can get a less "ugly" URL? I have many complaints about the "new and improved" ICANN website, but the current RSSAC documents page URL makes it look like nothing has changed since May 2014... SSAC has https://www.icann.org/groups/ssac/documents -- might we be able to get a "simple" URL for RSSAC too? W On Thu, Sep 1, 2016 at 8:23 PM, Steve Sheng <steve.sheng@icann.org<mailto:steve.sheng@icann.org>> wrote: Thanks Shane for this feedback! I think this is something staff can implement. "Please look for the latest version of this document at this page: https://www.icann.org/resources/pages/rssac-publications-2014-05-12-en" Best Steve On 8/31/16, 11:15 PM, "rssac-caucus-bounces@icann.org<mailto:rssac-caucus-bounces@icann.org> on behalf of Shane Kerr" <rssac-caucus-bounces@icann.org<mailto:rssac-caucus-bounces@icann.org> on behalf of shane@time-travellers.org<mailto:shane@time-travellers.org>> wrote: Wes, At 2016-08-31 07:04:37 -0700 Wes Hardaker <hardaker@isi.edu<mailto:hardaker@isi.edu>> wrote: > > Where is the repository for RSSAC documents? > > ICANN documents as a whole can be challenging to find, to the > multiple-versions and archived nature combined with their web > infrastructure, which is a typical CMS engine as far as I can tell. The > results are searches that don't always point to the most recent > document. > > Instead, I'd suggest searching for "RSSAC publications" which turns up > the much more useful and should always be up to date publication list > based on release dates: > > https://www.icann.org/resources/pages/rssac-publications-2014-05-12-en > > [Note: I have no role over the ICANN pages and the publication process] Thanks for the pointer! My guess is that other people would try a similar process to the one that I used and also end up in the wrong place. Educating everyone in the world seems really hard. Fixing the ICANN pages and publication process is probably easier, but I can easily imagine it taking many months if not years. What seems relatively easy would be to put some text at the top of the document saying: "Please look for the latest version of this document at this page: https://www.icann.org/resources/pages/rssac-publications-2014-05-12-en" It's not great, because a human (or program) still has to search through the list and find the most recent copy, but it at least gives a hint about how to do this. BTW, I love the URL which includes a random date in it, although I am a bit disappointed that it doesn't have "pages/pages" in the path. ;) Cheers, -- Shane _______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org<mailto:rssac-caucus@icann.org> https://mm.icann.org/mailman/listinfo/rssac-caucus -- 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 _______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org<mailto:rssac-caucus@icann.org> https://mm.icann.org/mailman/listinfo/rssac-caucus
On Mon, Sep 19, 2016 at 9:52 AM, Andrew Mcconachie <andrew.mcconachie@icann.org> wrote:
Hi Warren,
This has been changed. The new RSSAC publications URL is: https://www.icann.org/groups/rssac/documents
The old URL still works and points to this new URL.
Awesome, thank you. The old URL was buggin' me... W
Thanks, Andrew
On Sep 1, 2016, at 20:35, Warren Kumari <warren@kumari.net> wrote:
So, I realize that the answer is probably "No", but is there a way that we can get a less "ugly" URL? I have many complaints about the "new and improved" ICANN website, but the current RSSAC documents page URL makes it look like nothing has changed since May 2014...
SSAC has https://www.icann.org/groups/ssac/documents -- might we be able to get a "simple" URL for RSSAC too?
W
On Thu, Sep 1, 2016 at 8:23 PM, Steve Sheng <steve.sheng@icann.org> wrote:
Thanks Shane for this feedback! I think this is something staff can implement.
"Please look for the latest version of this document at this page:
https://www.icann.org/resources/pages/rssac-publications-2014-05-12-en"
Best Steve
On 8/31/16, 11:15 PM, "rssac-caucus-bounces@icann.org on behalf of Shane Kerr" <rssac-caucus-bounces@icann.org on behalf of shane@time-travellers.org> wrote:
Wes,
At 2016-08-31 07:04:37 -0700 Wes Hardaker <hardaker@isi.edu> wrote:
> > Where is the repository for RSSAC documents? > > ICANN documents as a whole can be challenging to find, to the > multiple-versions and archived nature combined with their web > infrastructure, which is a typical CMS engine as far as I can tell. The > results are searches that don't always point to the most recent > document. > > Instead, I'd suggest searching for "RSSAC publications" which turns up > the much more useful and should always be up to date publication list > based on release dates: > > https://www.icann.org/resources/pages/rssac-publications-2014-05-12-en > > [Note: I have no role over the ICANN pages and the publication process]
Thanks for the pointer!
My guess is that other people would try a similar process to the one that I used and also end up in the wrong place.
Educating everyone in the world seems really hard. Fixing the ICANN pages and publication process is probably easier, but I can easily imagine it taking many months if not years.
What seems relatively easy would be to put some text at the top of the document saying:
"Please look for the latest version of this document at this page:
https://www.icann.org/resources/pages/rssac-publications-2014-05-12-en"
It's not great, because a human (or program) still has to search through the list and find the most recent copy, but it at least gives a hint about how to do this.
BTW, I love the URL which includes a random date in it, although I am a bit disappointed that it doesn't have "pages/pages" in the path. ;)
Cheers,
-- Shane
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
-- 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 _______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
-- 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
Well done, Andrew, this is very helpful!! Russ
On Sep 19, 2016, at 9:52 AM, Andrew Mcconachie <andrew.mcconachie@icann.org> wrote:
Hi Warren,
This has been changed. The new RSSAC publications URL is: https://www.icann.org/groups/rssac/documents <https://www.icann.org/groups/rssac/documents>
The old URL still works and points to this new URL.
Thanks, Andrew
On Sep 1, 2016, at 20:35, Warren Kumari <warren@kumari.net <mailto:warren@kumari.net>> wrote:
So, I realize that the answer is probably "No", but is there a way that we can get a less "ugly" URL? I have many complaints about the "new and improved" ICANN website, but the current RSSAC documents page URL makes it look like nothing has changed since May 2014...
SSAC has https://www.icann.org/groups/ssac/documents <https://www.icann.org/groups/ssac/documents> -- might we be able to get a "simple" URL for RSSAC too?
W
On Thu, Sep 1, 2016 at 8:23 PM, Steve Sheng <steve.sheng@icann.org <mailto:steve.sheng@icann.org>> wrote: Thanks Shane for this feedback! I think this is something staff can implement.
"Please look for the latest version of this document at this page:
https://www.icann.org/resources/pages/rssac-publications-2014-05-12-en <https://www.icann.org/resources/pages/rssac-publications-2014-05-12-en>"
Best Steve
On 8/31/16, 11:15 PM, "rssac-caucus-bounces@icann.org <mailto:rssac-caucus-bounces@icann.org> on behalf of Shane Kerr" <rssac-caucus-bounces@icann.org <mailto:rssac-caucus-bounces@icann.org> on behalf of shane@time-travellers.org <mailto:shane@time-travellers.org>> wrote:
Wes,
At 2016-08-31 07:04:37 -0700 Wes Hardaker <hardaker@isi.edu <mailto:hardaker@isi.edu>> wrote:
> > Where is the repository for RSSAC documents? > > ICANN documents as a whole can be challenging to find, to the > multiple-versions and archived nature combined with their web > infrastructure, which is a typical CMS engine as far as I can tell. The > results are searches that don't always point to the most recent > document. > > Instead, I'd suggest searching for "RSSAC publications" which turns up > the much more useful and should always be up to date publication list > based on release dates: > > https://www.icann.org/resources/pages/rssac-publications-2014-05-12-en <https://www.icann.org/resources/pages/rssac-publications-2014-05-12-en> > > [Note: I have no role over the ICANN pages and the publication process]
Thanks for the pointer!
My guess is that other people would try a similar process to the one that I used and also end up in the wrong place.
Educating everyone in the world seems really hard. Fixing the ICANN pages and publication process is probably easier, but I can easily imagine it taking many months if not years.
What seems relatively easy would be to put some text at the top of the document saying:
"Please look for the latest version of this document at this page:
https://www.icann.org/resources/pages/rssac-publications-2014-05-12-en <https://www.icann.org/resources/pages/rssac-publications-2014-05-12-en>"
It's not great, because a human (or program) still has to search through the list and find the most recent copy, but it at least gives a hint about how to do this.
BTW, I love the URL which includes a random date in it, although I am a bit disappointed that it doesn't have "pages/pages" in the path. ;)
Cheers,
-- Shane
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org <mailto:rssac-caucus@icann.org> https://mm.icann.org/mailman/listinfo/rssac-caucus <https://mm.icann.org/mailman/listinfo/rssac-caucus>
-- 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 _______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org <mailto:rssac-caucus@icann.org> https://mm.icann.org/mailman/listinfo/rssac-caucus
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
participants (8)
-
Andrew Mcconachie -
John Bond -
Ray Bellis -
Russ Mundy -
Shane Kerr -
Steve Sheng -
Warren Kumari -
Wes Hardaker