Eliot Lear wrote:
The working group could analyze the requirements of a reputation service
based on IP address, determine whether and how any newly discovered
requirements could be met using DNS, and fill in any details that are
missing from the informational specification that are needed for
reliable and robust interoperation _of the mail transport system_ when
using DNSxBLs.
That's all rather nebulous, Keith. You then go on to cite examples
which in fact are addressed very specifically in the draft, and so I
suspect they are merely pretenses for what is really irking you, which
you have stated repeatedly, first in your initial message on this thread:
Under no circumstances should any kind of Blacklists or Whitelists be
accepted by IETF as standards-track documents. These lists are
responsible for huge numbers of illegitimate delivery failures. We
should no more be standardizing such lists than to be standardizing spam.
To clarify, I've backed off of that extreme position after being
persuaded that a well-designed reputation protocol can increase
accountability and transparency for blacklisting services. I feel like
if we put end-users into the feedback loop the system as a whole can
improve tremendously.
At the same time I think we've seen evidence in this discussion of a
fair amount of disconnect between operators and end-users - so am
absolutely convinced that such transparency and feedback are necessary
parts of a standard.
I am also convinced that the design of the reputation protocol has a
(perhaps subtle) effect on the reliability of a mail system that relies
on reputation services, and that this bears more examination.
and then in response to my note:
My belief is that among the goals of standardizing this practice would
be: To improve transparency and accountability of DNSBLs to end users
over what it is now, to improve security and reduce the potential for
use of DNSBLs for attack (including both DoS attack and thwarting of
spam blocking), to improve consistency in reporting between different
DNSBLs.
And what makes you think a technical standard would do that when it
never has in the past?
I strongly disagree that technical standards have never done this in the
past.
Once again, I think you are overstating the role of this
organization. The choices a DNSBL makes to list someone are entirely
its own. The choice to use a given DNSBL is entirely that of the MTA
administrator.
I don't disagree with either of those statements.
You cannot specify a standard to force a DNSBL to disgorge its logic.
I'm not even sure what you mean by that, but I don't think I wish to do
any such thing.
I hope the IESG will respect our established process, and recognize that
(a) there are indeed technical omissions in this document, and (b) the
document as currently written does not have rough consensus of the IETF
technical community, as shown already by the expressed concerns of
several contributors to this list.
(a) You complained about a lack of discussion on TTLs, which is in fact
in the draft. You complained about a lack of security considerations,
which is in fact in the draft, and you complained about TXT records not
being required, when in fact the draft makes use of a SHOULD. It is not
clear to me that a MUST meets the criteria listed in RFC 2119.
IMHO, The draft is woefully incomplete in both areas. And these are
just examples of things that are wrong
(b) I count three or four very vocal opponents versus an enormous
installed base.
The installed base is not the same thing as the IETF community. If "the
installed base" wants to lend its reputation to support this document,
that's its own business. But that's not the question at hand. What is
being asked is for IETF to lend _its_ reputation to this document,
despite obvious technical flaws, deviations from our usual criteria in a
number of areas, and significant objection from within the IETF
community. This is being requested on the basis of vague assertions of
some "installed base" by a small number of persons claiming to represent
that "installed base" - claims which, I might add, are fairly dubious
and which are irrelevant according to our established process.
At any rate, the purpose of IETF is not to recognize "the installed
base", the purpose of IETF is to specify what it believes will make the
Internet work well.
But even were it more, I would hope the IESG wouldn't only use rough
consensus to move forward, but also their judgment, for which we pay
them so much ;-) And that leads to my questions, which can be summed
up as follows:
* Are we better off with or without a proposed standard in this space?
* Is this document the right document to base that standard on?
* Is there sufficient benefit to be had by creating a working group?
For the record, my answer to these questions are Yes, Yes, and No.
I disagree. But more importantly, those answers are not relevant to the
question at hand - which is whether the current version of the current
document meets the criteria we've established for Proposed Standard.
And we've already seen plenty of evidence presented that it does not -
in either the technical quality or rough consensus categories.
A separate question to be addressed by IESG is how to further this work.
My personal opinion is that the best way to proceed is to first work
toward publishing this document of existing practice as Informational
and then form a WG to determine what kind of protocol (this or another
one) would be suitable for a standard. I believe this gives us the best
possible result - quick publication of a document that will improve
interoperability of what is being done today, to be followed by a
standards effort that should "raise the bar" and produce an improved
reputation service in the future. (do you really believe that DNSBLs in
their current form have no room for improvement?)
But there are lots of possible ways to proceed, and I'm sure IESG will
carefully consider that question.
Keith
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.175 / Virus Database: 270.9.0/1779 - Release Date: 11/10/2008 7:53 AM