sks-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sks-devel] 2 out of 10 pool.sks-keyservers.net not responding to pi


From: Daniel Kahn Gillmor
Subject: Re: [Sks-devel] 2 out of 10 pool.sks-keyservers.net not responding to pings
Date: Mon, 29 Nov 2010 17:00:12 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101110 Icedove/3.1.6

On 11/29/2010 04:03 PM, Robert J. Hansen wrote:
> Many keyserver operators run under the aegis of larger networks, and are
> beholden to the decisions made by network administrators above them.
> Some networks block ping (usually because of claims that ping is a
> security concern).

i've heard these claims about ping, and i confess i've never properly
understood them, particularly for hosts with services operating on
well-known ports.

> I don't like the idea of the community adopting a SHOULD -- even
> informally -- when a large fraction of the community will lack all
> ability to conform with the SHOULD.

i don't understand this sentiment; if we think this is reasonable, it's
entirely acceptable to say so, even when not everyone can follow
through.  Moreover, if we think this is actually preferable, then
presumably we'd like to help our fellow keyserver operators get it
working where possible.  A clearly worded explanation of why this is
useful for the SKS network and a general endorsement of the practice
would be helpful for keyserver operators dealing with reasonable network
administrators.  (no, i don't know a way to help keyserver operators
deal with unreasonable network administrators)

I feel the same way about offering HKP access on port 80, for example,
and about encouraging the deployment of a reasonable webform for the
index.  Would you object to a community endorsement of these practices
on the grounds that not everyone is capable of implementing them?

        --dkg

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]