I'm finally getting around to making the revisions for the DNSBL BCP
draft revision 3, since there's a possibility that the BCP may be
accepted at the upcoming Dublin IETF.
I'm going to try to get an 04 revision out today.
I'm working through all the NITs and minor wording changes, and
accepting almost all of them as given. Eg: the list of changes from Tony
Hansen. Thanks all!). _None_ of these change the BCP in any
substantive fashion.
However, apparently, the IETF document site has frozen all submissions
because of the impending IETF meeting, and won't unfreeze until Sunday
or Monday. Which means it won't be "officially visible" until then.
The only bit that generated a substantive discussion was Ian's mention
of this:
I'm not sure about this: "DNSBL providers SHOULD NOT be held
accountable in any way for the consequences of use of a DNSBL applied
in an un-intended way."
The implication is that providers may or even should be held accountable
for consequences of use of a DNSBL applied in an intended way.
My first reaction was "if I had meant that implication, I would have
stated it explicitly". But that's rather flippant.
There's an important point in that statement (eg: don't blame the PBL
for people doing deep received header tracing), so we can't lose it.
But subsequent wording suggestions didn't seem to quite fix the
perceptual problem.
I've come up with a different approach - rather than trying to do a
SHOULD/MUST etc, I'm just going to provide an existing example, worded
thusly:
------------------------------------------------------
For example, one DNSBL requires, if the DNSBL is used contrary
to their usage instructions, that the DNSBL user should not identify
the DNSBL being used, and further that it is the DNSBL user's
responsibility to mitigate the effect of the listing locally.
------------------------------------------------------
Whaddya think?
I could put a link into the specific DNSBL's policy that says that as a
informative reference, but I've avoided calling out specific DNSBLs so
far, and I'd like to keep it that way.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/asrg