Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)

Dave CROCKER <dhc2@dcrocker.net> Fri, 07 November 2008 15:57 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 3EB6E3A6A98; Fri, 7 Nov 2008 07:57:35 -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 403863A6A98 for <ietf@core3.amsl.com>; Fri, 7 Nov 2008 07:57:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.8
X-Spam-Level:
X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799]
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 YgxJVGLV1ph0 for <ietf@core3.amsl.com>; Fri, 7 Nov 2008 07:57:32 -0800 (PST)
Received: from sbh17.songbird.com (mail.mipassoc.org [IPv6:2001:470:1:76:0:ffff:4834:7146]) by core3.amsl.com (Postfix) with ESMTP id D56C93A69BF for <ietf@ietf.org>; Fri, 7 Nov 2008 07:57:31 -0800 (PST)
Received: from [192.168.0.3] (adsl-67-124-149-194.dsl.pltn13.pacbell.net [67.124.149.194]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id mA7FvJge005938 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Nov 2008 07:57:20 -0800
Message-ID: <4914655E.40701@dcrocker.net>
Date: Fri, 07 Nov 2008 07:57:18 -0800
From: Dave CROCKER <dhc2@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>
Subject: Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
References: <20081107111744.GA31018@nic.fr> <20081107141821.79303.qmail@simone.iecc.com> <20081107145257.GA28398@nic.fr>
In-Reply-To: <20081107145257.GA28398@nic.fr>
X-Virus-Scanned: ClamAV 0.92/8586/Thu Nov 6 20:55:22 2008 on sbh17.songbird.com
X-Virus-Status: Clean
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 07 Nov 2008 07:57:20 -0800 (PST)
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: dcrocker@bbiw.net
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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


Stephane Bortzmeyer wrote:
> On Fri, Nov 07, 2008 at 02:18:21PM -0000,
>  John Levine <johnl@iecc.com> wrote 
>> All of these questions have come up before on the various lists
>> where this draft was developed, but I suppose it's worth going
>> through
> 
> That's the point of an IETF-Wide Last Call. I'm not a participant in
> the ASRG.


Stephane,

Your view of the role of IETF Last Call does not match my reading of RFC 2418, 
"IETF Working Group Guidelines and Procedure":

    Last-Call is intended as a brief, final check with the
    Internet community, to make sure that no important concerns have been
    missed or misunderstood. The Last-Call should not serve as a more
    general, in-depth review.

You seem to be calling for an in-depth review.

Last Call gives the community a chance to actively put forward concerns, not to 
passively wait and require a detailed exposition by the working group. You note 
that you were not a participant. Yet that is exactly how someone who is 
concerned about the detailed history is supposed to obtain information about the 
detailed process (and affect its outcome.)

Sometimes, specification do contain rationales.  This is one of the things that 
distinguishes IETF specifications from most other standards groups.  But there 
is no requirement for this in IETF documents.  They are specifications, not 
tutorials.


>> Incidentally, although it may still be the conventional wisdom in the
>> IETF that DNSBLs don't work and aren't useful, 
> 
> No, it's just experience. The last funny case is inside France Telecom
> (French largest ISP) where one mail server refused another one because
> it was blacklisted :-)

That's a problem with administration and operation, not with specification of 
the format.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf