Re: uncooperative DNSBLs, was several messages

John C Klensin <john-ietf@jck.com> Thu, 13 November 2008 18:40 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E72A828C0E1; Thu, 13 Nov 2008 10:40:21 -0800 (PST)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22AB93A69CB for <ietf@core3.amsl.com>; Thu, 13 Nov 2008 10:40:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.633
X-Spam-Level:
X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9BKxGTn0vC8 for <ietf@core3.amsl.com>; Thu, 13 Nov 2008 10:40:20 -0800 (PST)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 04B253A69C5 for <ietf@ietf.org>; Thu, 13 Nov 2008 10:40:20 -0800 (PST)
Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1L0h75-000B9i-Ce; Thu, 13 Nov 2008 13:40:19 -0500
Date: Thu, 13 Nov 2008 13:40:18 -0500
From: John C Klensin <john-ietf@jck.com>
To: Chris Lewis <clewis@nortel.com>
Subject: Re: uncooperative DNSBLs, was several messages
Message-ID: <998D0038DCFA6A3145D93A7C@p3.int.jck.com>
In-Reply-To: <491C699B.4000702@nortel.com>
References: <Pine.LNX.4.33.0811121942450.12067-100000@egate.xpasc.com> <20081113112302.38928.qmail@simone.iecc.com> <e0c581530811130740g1db5cbfehbcdad361660bf48b@mail.gmail.com> <491C5339.8090801@dcrocker.net> <20081113163833.GN76118@shinkuro.com> <491C699B.4000702@nortel.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Disposition: inline
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


--On Thursday, 13 November, 2008 12:53 -0500 Chris Lewis
<clewis@nortel.com> wrote:

>> 2.  DNSBLs are in themselves bad, because there is no way to
>> guarantee that they won't contain false positives; they are
>> nevertheless possibly useful, but the trade-offs are
>> inadequeately described in the current document.
> 
> If all that's missing is a few sentences in the Security
> Considerations section, I'm sure that we can get somewhere
> with that, on the other hand, discussion of those types of
> tradeoffs probably don't belong in this draft, but a BCP.

But there is no BCP.  There is a draft that has been cited a few
times, but no request for the IETF to review and publish it.  It
has never been the practice for the IETF to approve a
standards-track document that is known to be too weak without
some material with the promise that material will appear at some
point in the future and will be adequate.

Chris, I can't promise success, but let me at least suggest how
to have a very different, and potentially more constructive,
discussion.

(1) This document gets withdrawn, or at least suspended, in its
current form. 

(2) You and your colleagues ask for a WG.  If there is as much
consensus and work done already as we have been told, it could
have a very aggressive schedule.   However, the draft charter
should reflect the set of documents you think are needed, how
they connect to each other, and what topics they cover.  It
should also permit a clear discussion about the community's
expectations and conditions for approach of DNSBL documents,
independent of trying to pick apart (or advance) one particular
document.

(3) If you can get that charter approved, you submit documents
that are closely related either together or in some sequence
consistent with the charter and/or their relationships.  

If you cannot get the charter approved, then I think this is
hopeless unless you decide to simply publish a series of
Informational documents with clear statements about what they
represent.

Just my opinion of course, but it appears to me that the present
discussions are going nowhere that is likely to lead to
standardization of the current document in its present form.
The observation that both those who favor standards-track
publication of the document and those who dislike it (or RBLs
generally) for one reason or another are kicking the same dead
horse  (Lisa has already posting a note indicating that she
doesn't see sufficient consensus to support the document for
standardization in its current form, which makes it dead unless
another IESG member comes forward to sponsor it) moves neither
the document nor the discussion forward.

      john

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf