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

[Xian Stannard]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

OK. I think I missed some design decisions here. I'm asking questions
here not because I think particularly think we should go down these
routes but because I'm interested in why vs. why not.

On 01/06/2011 14:39, Robert J. Hansen wrote:
> 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.
I can see that it is bad to loose keys that are in use, but why must
every key from day zero be kept? The deletion need not be probibitive of
the key being uploaded again: that could trigger it to be re-propagated.

On 01/06/2011 15:47, John Clizbe wrote:
> 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).
If the complete set were to be split into clearly defined subsets,
couldn't the fast set reconciliation could occur between these subsets
just as quickly. Servers could carry multiple subsets to make sure that
no particular subset lacked in redundancy? Could the current servers be
thought of as holding all subsets?

I'm guessing that one of the design aims is that the network of servers
needs to be redundant enough so that it is very hard to kill enough of
them to start losing access to keys.

- -- 
/Xian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJN5nN6AAoJEEPJptmhzueQJ1gH/3//agq2EU25ufsSAryg/0Zj
ngXAHutPpNNTGOwHnYNnZm4H59/q1sLIg++chyD2Ww2ieq+qpbuPevkMyRvtlOIA
+fUNAI7myoWbOiTf2S4arT75bVD0fHRUaK1wI9ak1cxEu41/xTVNvuCoUSC34Bvn
kb8vlQgBLi6dJ5ytGjKFGlC1lKk/wg7wbS7gHexic/RBOSwkrlAMLNMqUgI0R0qz
OwB06pqlbQu0cSpPhmHHMKwGrhlr5Q3npakJBzL6lVE9stSsuYyUhONGEZvLULC8
LpXnhE++ou2vPfwEAa0cIPIWPpba31jxXzbxijrB92ZWwO/bZb0MVVDWTz/AjCI=
=olVL
-----END PGP SIGNATURE-----