Chris Lewis wrote:
I think the first go-round went to the IETF as
draft-irtf-asrg-bcp-blacklists-04 (file was actually 01).
I fixed the document so that this one says 02. Is this
going to be a problem?
02 after 01 is fine.
Should I call this 05 before distributing to IETF?
05 after 01 could mean trouble.
If you make comments on the draft, please trim out
the stuff you're not commenting on.
Please do NOT post complete drafts as mail, just go
to the Internet Draft Submit Web form and click on
"send". Integers are cheap - at least below 99 :-)
[non-procedural]
If you are going to allow a third party to make
blocking decisions for you, you MUST understand
the policies and practices of those third parties
because responsibility for blocking decisions
remain ultimately with you, the system administrator.
As reported in another mail: BLs don't make blocking
decisions. Users of BLs make blocking decisions based
on input from BLs, and on other factors. IANAL, but
for legal reasons I think it is important to have it
very clear who recommends (BL) and who blocks (user).
NOTE: This document is a product of the Anti-Spam Research Group
(ASRG) of the IRTF. As per section 3 of RFC 2014 [RFC2014]IRTF
groups do not require consensus to publish documents. Therefore
readers should be aware that this document does not necessarily
represent the consensus of the entire ASRG.
This Note is IMO irrelevant, a BCP needs the consensus
of the IETF determined by the IESG after an IETF Last
Call. The IRTF is not entitled to publish IETF BCPs,
and AFAIK there are no "IRTF BCPs".
NOTE: This document is intended to evolve, based on comments from
the Anti-Spam Research Group (ASRG) mailing list. It is certain
that the current draft is incomplete and entirely possible that it
is inaccurate. Hence, comments are eagerly sought, preferably in
the form of suggested text changes, and preferably on the ASRG
mailing list, at <asrg(_at_)ietf(_dot_)org>.
This note is apparently for the time while the draft is
discussed. Please make this clear, e.g. move temporary
stuff into a "document history" section, with a note
that this is not intended for publicataion in the BCP.
4. Security Considerations
You need also "IANA Considerations", especially BCPs
often create IANA registries. The IANA Considerations
must be there, even if the content is "nothing to do,
remove this section before publication".
A DNSBL manager that decided to list 0/0 (which has
actually happened)
Yes, that's why there should be a test item 127.0.0.1
or similar, that's never listed.
a DNSBL manager removes all of the entries (which
has also happened)
Yes, that's why there should be a test itme 127.0.0.2
that is always listed, even if a list with all IPs not
ending with "2" hates it. Maybe add a reference to the
technical RFC for details about test entries for these
security considerations, it's always good to propose a
way to mitigate identified threats.
[RFC2014] Weinrib, A. and J. Postel, "IRTF Research Group
Guidelines and Procedures", BCP 8, RFC 2014,
October 1996.
That's no normative reference, move it to informative.
[DNSBL-EMAIL]
Levine, J., "DNS-based blacklists and Whitelists for
E-Mail", November 2005, <http://www.ietf.org/
internet-drafts/draft-irtf-asrg-dnsbl-04.txt>.
OTOH that is IMO a normative reference IFF it ends up on
standards track, as it should.
Frank
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/asrg