On 02/27/2011 01:14 AM, Claus v. Wolfhausen wrote:
This is the official statement from the maintainers of the
UCEPROTECT-Network
about this section of your RFC - Draft:
2.2.5. Conflict of Interest
Some DNSBLs used for blocking/negative reputation have had a practise
of requiring fees or donations to charities from the listee for
delisting.
It is generally considered entirely appropriate for a DNSBL to charge
for access to it by its users - the definition of a commercial DNSBL.
However, the practise of requiring a listee to pay for delisting from
a negative connotation DNSBL steers perilously close to notions of
extortion, blackmail or a "protection racket". Even if such
accusations are entirely unjustified the practise causes uproar and
damage to the DNSBLs reputation, if not the entire DNSBL mechanism as
a whole. Colloquially, "it smells bad".
Therefore, negative-connotation DNSBLs MUST not charge fees or
require donations for delisting or "faster handling", and it is
RECOMMENDED that such DNSBLs that do charge fees or require donations
not be used.
We recommend that you remove the complete last sentence, because it reflects
only your personal opinion, how a DNSBL should be operated.
Charging to remove a negative reputation is also more or less equiv to
charging to add a positive reputation (such as a commercial whitelist or
vouching service). Both have merits, both sometimes smell bad or leave
a bad taste, both are sometimes *incorrectly* termed as "extortion" or
similar. -1 * -1 == +1 * +1 its the identical adjustment, merely
expressed differently.
If one expression of this type of adjustment is discouraged (ie pay to
delist) so should the equivalent expressions (paid whitelistings,
vouching services, accreditations etc) be discouraged.
That said, it is a business policy decision more than a technical policy
decision, and it does not make sense to recommend one way or the other.
Since you claim the document would be intended to provide guidance to
DNSBL operators so that they may be able to identify what features users
would be interested in seeing as a part of a high-quality, well-managed
DNSBL,
it is not your business to tell the operators they "MUST NOT" charge
delisting or "faster handling" fees.
I would tend to agree with you on this. Particularly, this usage seems
to go against RFC 2119 (section 6) which in relation to key words such
as MUST, MUST NOT, etc, states:
|> 6. Guidance in the use of these Imperatives
|>
|>
|> Imperatives of the type defined in this memo must be used with care
|> and sparingly. In particular, they MUST only be used where it is
|> actually required for interoperation or to limit behavior which has
|> potential for causing harm (e.g., limiting retransmisssions) For
|> example, they must not be used to try to impose a particular method
|> on implementors where the method is not required for
|> interoperability.
Charging for listing/delisting is not an interoperability issue per se,
and "it smells bad" is on not the same type of harm as retransmissions
or similar.
OTOH, the draft does not source BCP 14 / RFC 2119, so perhaps changing
the "MUST" to lowercase "must" or even a lowercase "should" for the sake
of clarity would be an equally good option.
The recommendation that such DNSBLs which are charging for removals
should not be used is a personal opinion and as such it has also no place
in a guidance which is addressed to DNSBL operators.
Under the heading of conflict of interest it does make sense to at least
recommend disclosure of such policies, if in place.
Any opportunity for the subject of reputation data to alter that
reputation data by means of payment, could pose a conflict of interest,
and is therefore something of which a DNSxL's users or potential users
should be aware. As long as users of a DNSxL are fully informed of the
potential conflict of interest, they can make informed decisions as to
the trustworthiness and usefulness (or lack thereof) of the data provided.
--
Joe Sniderman <joseph(_dot_)sniderman(_at_)thoroquel(_dot_)org>
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg