Keith,
1. Would declining to publish as a standard harm or hurt the
community? Would refusing to publish as a standard stop implementations
or merely create potential interoperability issues that could lead to
more legitimate messages being dropped?
How are either of these questions relevant to the criteria in RFC 2026?
Since the request to advance in this case is for PS, there is a
relatively low threshold to move the thing forward, as documented in
Section 4 of RFC 2026. Section 6 of RFC 2026 requires the IESG to use
its collective judgment in reviewing requests for advancement. I am
attempting with both questions to provide guidance to the IESG as to how
to how they might judge.
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.
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? 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. You cannot specify a standard to force a DNSBL
to disgorge its logic. When we have tried this in the past we ended up
with superfluous information undermining confidence in any useful
information that may be out there. One need look no further than the
value of old WKS records.
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.
(b) I count three or four very vocal opponents versus an enormous
installed base. 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
believe the onus is on those who would want a working group to come up
with at least a plausible outcome that could improve the document. Thus
far I've heard no such thing, and there are risks for delaying
publication, one of which would be calling into question the IETF's
relevance.
Eliot
ps: for the astute, we are nearly back to a NAT argument. The IETF
version of Godwin's Law may apply.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf