Data Publishing Policy?
- Date: Mon, 12 Jul 1999 11:53:23 +0200 (CEST)
(Distribution list cut down a bit in order to avoid overlaps. Dimitrios
(and others), if you want to reply, please subscribe to tt-wg first.)
On Thu, 8 Jul 1999, Dimitrios Kalogeras wrote:
[...]
> So I would like you to grant me permission to publish the corresponding
> tt42 row of the matrix which shows the results to my downstream peers.
This is a detail, but you need to show both the row and column refering to
tt42. The row shows the one way delays from tt42 to another side, the
column the one-way delays from other sides to your test-box.
Anyway, more people have asked for this, so I think we should reconsider
the basic options that we have here:
1. Leave things as they are, only the host sites can look at the plots.
2. Change the passwork scheme such that the host sites get 2 passwords,
one for the full page and one for the page with their plots. They can
give the second password to their customers. Customers will be able
see the plots for their ISP, but cannot compare data between ISP's.
(Unless, of course, they use 2 providers). Some general information
will have to be made public in order to make it understandable (the
map of boxes, for example).
3. Keep one password and give ISP's the option to give it away to their
customers with some restrictions. (e.g. 1 contact person, with the
condition not to pass it further). Customers can then look at every
plot.
4. Remove the passwords altogether.
Personally, I'm in favor of either #2 or #3. There are more people who
have asked for this and I hope that we will move to a stage where our data
is actually used for practical purposes such as checking SLA's, so #1
seems too restrictive.
#4 has the disadvantage that sooner or later, plots will appear all over
the place, no doubt with serious misinterpretations which are hard to
correct after the fact.
#2 requires a bit of work from our side. First to set up the ACL's, then
to manage the passwords, though all this isn't exactly rocket-science. #3
is easier in that respect. Note that both schemes rely on the discipline
of people not to distribute passwords.
Regardless of whether we choose #2, #3 or #4, I don't see a problem with
translating the pages for the benefit of the target audience.
> As a last point towards permission , we commit ourselves to have the
> RIPE logo (or hyperlinks) wherever this is mentioned.
I'd think (but I haven't checked with our lawyers :-) that the plots
should contain something like:
(c) RIPE-NCC, 1999, these plots can only be used for the purposes
explicitly described in RIPE-180.
(and modify RIPE-180 (the data-disclosure policy) accordingly).
Anyway, this is, as far as I'm concerned, an implementation detail, I
think that we should first agree on the principle of giving access to
customers of the host sites to the plots.
Comments anyone? I'd really like to see some discussion in the next
weeks, so that we can prepare and approve an update for RIPE-180 by the
next RIPE meeting.
Henk
------------------------------------------------------------------------------
Henk Uijterwaal Email: henk.uijterwaal@localhost
RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk
Singel 258 Phone: +31.20.535-4414, Fax -4445
1016 AB Amsterdam Home: +31.20.4195305
The Netherlands Mobile: +31.6.55861746
------------------------------------------------------------------------------
The Committee (...) was unable to reach a consensus that substantial merit was
lacking. Thus, the appeal was deemed meritorious. (Orlando NABC #19).
