<<< Chronological >>> Author Index    Subject Index <<< Threads >>>

Re: Data Publishing Policy?

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
for the one direction (outgoing) being password free.  The other
direction could
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
same one for all of my customers ?. In the later case I have to admit
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

<<< Chronological >>> Author    Subject <<< Threads >>>