Re: Data Publishing Policy?
- Date: Mon, 12 Jul 1999 14:55:02 +0300
- Organization: National Technical University of Athens
I apologize in case you receive this twice.
"Henk Uijterwaal (RIPE-NCC)" wrote:
> (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.
>
You are right the complete network's view comes form the row and the
column view..
However I do sympathize the other's concernd. So at this intial step I
would only
ask
for the one direction (outgoing) being password free. The other
direction could
be
password protected in any of the following ways, since it does not
originates from
my domain.
>
> 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.
>
I have fifty different customers.. Do I use personalized passwords or
the
same one for all of my customers ?. In the later case I have to admit
that
the password checking procedure is not so straight forward.
>
> 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.
>
I am in favor of #2.
#3 Difficult to implement.
>
> #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).
--
Dimitrios K. Kalogeras
Electrical Engineer Ph.D.
Network Manager
NTUA/GR-Net Network Management Center
_____________________________________
voice: +30-1-772 1863
fax: +30-1-772 1866
e-mail: D.Kalogeras@localhost
