Re: [Sks-devel] IPv6 peering; keydumps annoyingly large

[Scott Grayban]

Maybe I'm the rookie here but not a linux "rookie", I have been using
linux for the past 15 years, just google my name, and I always run into
the group that would rather take the "easiest way" and ignore a issue
that is bound to come up.

At some point the current DB is going to be to large to handle muchless
transport it via plastic media whether its dvd, blue-ray or flash drive.
Sure we have cheap TB drives now but that isn't going to be practicable
in the future to transport/share/copy the DB dump. I hear that some
people are already running into corrupt PTree db's and have to rebuild
them every few weeks... just this alone should be a warning.

PGP (keyserver.pgp.com) has been allowing keys to be deleted for years
and they even scrub their DB of revoked and expired keys and that hasn't
degraded the trust yet. It's just practicable to remove stuff like this.
You wouldn't keep moldy old bread would you ?

Regards,
Scott Grayban

 /"\
 \ /     ASCII RIBBON
  X        FIGHT BREAST CANCER
 / \


John Clizbe said the following on 06/01/2011 07:47 AM:
> Robert J. Hansen wrote:
> >> So just wait and see until the last minute to clean it up when DB does
> >> become a issue ?
>
> > No.  Wait for it to become any kind of a problem, and then solve it
> -- not
> > before.
>
> > Fixing things that are not problems and are not projected to become
> problems
> > is an inefficient use of a highly limited resource.
>
> >> Why wait ? Why can't we run a script that will at least delete keys
> that
> >> have expired and revoked ? And then prevent such keys from being
> >> re-imported back into the db ? That would be the sensible thing to
> do now
> >> when we don't have any emergencies.
>
> > At risk of pointing out the obvious, you've just added to the keyserver
> > network a way to delete keys and keep them from getting re-entered
> into the
> > DB.
>
> > This is exactly what the keyserver network is meant to avoid.  If that's
> > possible, the keyserver system will have failed.  For your idea to be
> > adopted, the network must fail.  This may explain some of the
> pushback you're
> > receiving...
>
> The idea of subsetting keys to different servers completely breaks
> what makes
> SKS so great - the FAST reconciliation of differences between two sets
> of data
> (servers).
>
> - From the Google Code page (http://code.google.com/p/sks-keyserver/ ):
> > The foundation of SKS is an efficient algorithm for reconciling
> remote data
> > sets. That algorithm is described in the following papers:
>
> >     * Set Reconciliation with Nearly Optimal Communication Complexity
> >       http://ipsit.bu.edu/documents/ieee-it3-web.pdf
> >     * Practical Set Reconciliation
> >       http://ipsit.bu.edu/documents/BUTR2002-01.ps
>
> Keep in mind that the goal of reconciliation is to produce identical
> data sets
> on each machine. You can't take that away, subset the data, and still
> call it SKS.
>
> Why the need to wait for Blu-Ray burners? DL-DVD writers are available
> for <$40,
> and as pointed 8GB USB sticks are under $10. Note: Whatever the
> choice, all the
> dump files _must_ be in one directory (no splitting to two DVDs).
>

_______________________________________________
Sks-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/sks-devel