Chris Lewis <clewis(_at_)nortel(_dot_)com> wrote:
On 1/18/2011 3:45 PM, John Leslie wrote:
Douglas Otis<dotis(_at_)mail-abuse(_dot_)org> wrote:
This draft should caution against assumptions that suggest IPv4
practices can be extended for use with IPv6!
+1
(I didn't stumble upon any exactly contrary statement; but I think we
need an explicit explanation that IPv6 DNSBLs are a work-in-progress at
best, and this documents cannot make recommendations specific to IPv6.)
This is suggestive of a disclaimer to that effect up in the introduction.
It could go in Section 1.4 "Background", for example.
I'm, however, hesitant in doing so. My reasoning is as follows:
a) If IPv6 DNSBLs are impractical as some suggest, no useful ones will
exist, the issue is moot, and no disclaimers are necessary.
Not a helpful argument. It supposes this document being read much
later than it's being issued (which could be true, but isn't our main
intent).
b) If IPv6 DNSBLs are practical, then most of the policies are entirely
IPvX neutral (and are in fact extensible to non-DNSBLs at that), and a
disclaimer of that type would unnecessarily deprecate the useful
policies that _should_ still apply to IPv6.
This is false.
c) If IPv6 DNSBLs are practical, but some of the policies don't make
technical sense, again the issue is moot, and no disclaimers are
necessary. Eg: rescan intervals: there's nothing that implies that
rescans are necessary. Hence, comments about rescanning of IPv6 entries
being impractical or impossible doesn't invalidate a "minimum rescan
interval" policy. If you can't rescan, then, the minimum rescan
interval policy is moot - by not rescanning at all, you still meet the BCP.
We don't even know what "rescan" will mean in an IPv6 world -- it's
just too darn premature. I asked for a statement that IPv6 DNSBLs are
"a work in progress" and that this document "cannot make recommendations
specific to IPv6" -- both inarguably true.
And we see plenty of evidence _within_ this RG that folks are thinking
s/4/6/ is an adequate heuristic -- which is inarguably false.
So, I don't see a hard conflict nor a necessity for such a disclaimer -
at least not a blanket one. Is there any MUST/SHOULD that _cannot_ be
met by a plausible IPv6 DNSBL implementation and needs a specific
disclaimer?
We don't know. We don't even know what a "plausible IPv6 DNSBL
implementation" may turn out to be. (But it is very suggestive that
there is essentially nothing keeping a compromised IPv6 host from using
a different /128 for every connection it makes...)
Other than that, I stumbled upon some of the MUSTard.
In general, we cannot enforce any behavior on list maintainers.
No, but we can encourage, and note/discourage what behaviours cause
problems in the real world.
MUSTard isn't about "encouraging" and "discouraging".
Actually, MUSTard is an IETF thing, not an IRTF thing. We incorporate
RFC 2119 by reference, but we can't entirely know what baggage our
readers will bring.
Specifically, the "MUST NOT charge" in Section 2.5 is inappropriate.
DNSBLs that do not charge for access will necessarily need to recover
costs for manual actions that exceed de-minimis, or simply not do them.
There are DNSBLs that do not charge for access and do not charge for
manual actions.
For the most part, they don't _do_ manual actions.
In fact, there's only one DNSBL that I know of that still imposes
financial costs surrounding delistings. It ain't SORBS...
Michelle _herself_ suggested "MUST NOT".
And I disagree with Michelle -- though that's really not the point.
Chances are, the "offending" DNSBL will abandon that business model
soon, quite regardless of what we write here. The practice is being
abandoned because it's an unprofitable business model.
But charging for removals demonstrably causes problems, such as people
who refuse to bother with perhaps mistaken DNSBL listings because they
view it as extortion.
That's a business choice on their part. Even in IPv4, renumbering a
SMTP client/server is simple enough -- and I find myself willing to do
this to avoid even a $10 charge. (This is _not_ a particularly rational
tradeoff for my time!)
Thus increasing the FP rate and impairing the accuracy for everyone else.
"Everyone" ???
Not to mention the harm to the reputation of the mechanism as a whole.
(That sounds like a null set to me...)
A strong statement that this isn't acceptable behaviour can do nothing
but good.
I don't mind a strong statement (though I don't expect it to have any
effect) -- I mind MUSTard which makes us look foolish.
Specifically, consider:
"
" 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.
(Why is there a need to RECOMMEND not using what we declare to be a
null set?)
You're letting your emotions rule here. There's a perfectly reasonable
business model I call "Vouching Service" where human judgment is needed
to verify that an event or practice which violated the rules has been
sufficiently rectified to again vouch for the offending whatever.
This sort of service _really_should_not_ be prohibited. But to say
there may be no charge involved comes arbitrarily close to prohibiting
it. :^(
A strong "SHOULD NOT charge" is appropriate.
We could probably even get away with a "MUST NOT use" such DNSBLs
in that paragraph, although personally I'd prefer "SHOULD NOT charge"
and "SHOULD NOT use".
The goal of the BCP is to strongly encourage the best practises on the
DNSBL admin side, but at the same time recognize that receivers can do
anything they feel like as long as they know what they're doing.
"MUST" in 2119-speak isn't "strongly encourage". Surely you can find
words (such as "strongly" and "encourage") to say what you mean.
IOW: a receiver can be in compliance even while using a DNSBL that's out
of compliance. Splitting between strong prohibition aimed at DNSBL
admins and mild discouragement aimed at receivers was quite deliberate
here.
(I wasn't asking for "MUST NOT use"...)
Given that the "MUST NOT" only puts one known DNSBL out of compliance
that I'm aware of, I'm comfortable with it.
I'm uncomfortable "putting one out of compliance" in order to make a
statment likely to rather-soon reference the null set.
If we say "MUST NOT charge", we should be talking about future
practices, not past ones. I feel pretty strongly about Vouching Services
being a useful tool.
In Section 3.4, the "MUST NOT list the entire Internet" is a bit
strong as well. While I think you have given plenty of suggested
alternatives to this, folks _do_ paint themselves into corners where
such a doomsday-weapon becomes needed. (Listing the entire Internet
_does_ mean they're outside the specification we're writing; but it
comes across as an attempt to control a behavior we can't control.
Perhaps we could suggest alternatives, not use the MUSTard, and say
that listing the entire Internet puts a DNSBL list out of conformance
with this set of practices.)
Isn't that exactly what the section means?
To whom ??
Seriously, it bothers me how often a reviewer notes a point of
confusion, and the response amounts to "What kind of fool could ever
be confused by that?" and not a single word of the document changes.
Another set of eyeballs looking at a document is a Good Thing (TM).
A good Document Editor welcomes the opportunity to reduce confusion,
even at the expense of adding words to a document.
Besides, heretofore, any DNSBL utilizing such a doomsday weapon was
heralding their own doom - compliance becomes moot.
Quite true -- so why do we need any MUSTard here?
We have to really really _really_ discourage the practise so that
receivers will know that listing-world is something they should not
need to worry about.
Is "Pollyanna" your middle name?
Face it: this happens. MUSTard won't change that. Receivers will
be better off to understand what happened _when_ they are hit by a
case of this.
But in the end, a DNSBL having to resort to it ain't going to care
about compliance,
Agreed.
and some of the provisioning recommendations are about making sure
that list-the-world scenarios are not necessary.
Howzzat?
Whatever, we should make sure that language about testing for
list-the-entire-Internet SHOULD be done is found within this Section.
It's the next section ... isn't that enough?
A forward-reference would be plenty.
--
John Leslie <john(_at_)jlc(_dot_)net>
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg