Re: several messages

"Tom.Petch" <sisyphus@dial.pipex.com> Tue, 18 November 2008 19:35 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 EF3B828C15A; Tue, 18 Nov 2008 11:35:42 -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 3F8513A6809 for <ietf@core3.amsl.com>; Tue, 18 Nov 2008 11:35:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.555
X-Spam-Level:
X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044]
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 piIMrJtvrdIE for <ietf@core3.amsl.com>; Tue, 18 Nov 2008 11:35:41 -0800 (PST)
Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id BBD633A67F4 for <ietf@ietf.org>; Tue, 18 Nov 2008 11:35:40 -0800 (PST)
X-Trace: 196213408/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.67/None/sisyphus@dial.pipex.com
X-SBRS: None
X-RemoteIP: 62.188.100.67
X-IP-MAIL-FROM: sisyphus@dial.pipex.com
X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106
X-IP-BHB: Once
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArsEAD+oIkk+vGRD/2dsb2JhbACDUUGJGsVvCIJx
X-IronPort-AV: E=Sophos;i="4.33,626,1220223600"; d="scan'208";a="196213408"
X-IP-Direction: IN
Received: from 1cust67.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.67]) by smtp.pipex.tiscali.co.uk with SMTP; 18 Nov 2008 19:35:36 +0000
Message-ID: <005b01c949ac$9518c1c0$0601a8c0@allison>
From: "Tom.Petch" <sisyphus@dial.pipex.com>
To: ietf@ietf.org
References: <Pine.LNX.4.64.0811121117180.8743@toro.popovich.net><008601c944fd$950335c0$6801a8c0@oemcomputer><20081113165601.GA2969@gsp.org><B81943909B5DD6BFD3A486B3@p3.int.jck.com><e0c581530811141051o9ce350fr2fbaf9903142e2d0@mail.gmail.com> <CD64C7B22B676275CC9B8E98@p3.int.jck.com>
Subject: Re: several messages
Date: Tue, 18 Nov 2008 16:17:41 +0100
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: "Tom.Petch" <sisyphus@dial.pipex.com>
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

IETF lists are sometimes criticised for their dominance by purveyors of boxes,
by the lack of involvement of those who deploy and depend on those boxes.

A striking feature of this Last Call is the (most welcome) contributions by
these other communities and the fact that, in this instance, an IETF proposed
standard would be most welcome, most helpful, to them.

Furthermore, the points made in favour of this I-D seem to me to be
fundamentally engineering, whereas those against seem more arcane, more
objections on the grounds that the underlying 'purity' of the Internet might be
compromised.

I tracked the lengthy gestation of this I-D on the asrg list and there too, it
struck me that we were engaged in engineering, in producing something that would
work and be of immediate benefit (not something I always see on the lists of
IETF WG)

So, I think that this is a positive and sound response to a major Internet
problem and would like to see it approved for the Standards Track.

Tom Petch

(responding to no message in particular)

----- Original Message -----
From: "John C Klensin" <john-ietf@jck.com>
To: "Al Iverson" <aiverson@spamresource.com>; <ietf@ietf.org>
Sent: Friday, November 14, 2008 8:50 PM
Subject: Re: several messages


>
>
> --On Friday, 14 November, 2008 13:51 -0500 Al Iverson
> <aiverson@spamresource.com> wrote:
>
> >...
> > This strikes me as unrelated to DNSBLs. Am I misunderstanding?
> > How is this DNSBL-specific?
>
> Al, and others,
>
> While many of us are less opposed to DNSBLs in principle than
> you or your colleagues may be assuming, we are opposed to
> creating IETF Standards for anything that interacts with the
> email environment without a relatively comprehensive
> understanding (and good documentation) of how the new bits
> interact with the rest of the system.  One of the implications
> of that is unwillingness to see DNSBL formats standardized
> without having any protocol or best-practice documents that are
> being assumed in front of us at the same time.   If there are
> failure cases, we expect to see descriptions of them and
> analyses of either their consequences or how they might be
> mitigated.
>
> When DNS experts claim that a particular approach is unhealthy
> for the DNS and give careful explanations for that, advocates of
> DNSBL standardization need to evaluate those arguments and
> propose remedies _in the relevant documents_, not just in
> flaming on the mailing list.
>
> When someone asserts that DNSBLs don't cause operational
> problems with the mail system if they are operated according to
> best practices, then it is reasonable for the IETF to require
> that documentation of the relevant best practices be put forward
> for standardization as part of the same logical package.
> Moreover, when a DNSBL advocate claims that his ISP organization
> is using best practices and not having problems or complaints,
> counterexamples that indicate that they are filtering complaints
> and/or that the supposed best practices are not sufficient or
> effective are very much in order.
>
> The purpose of IETF-wide review is precisely to bring out these
> "that has implications outside the particular focus of the
> developers" issues and force them to be discussed and resolved
> before a standards-track document can be approved.  Although
> this one has been, IMO, a little more hostile than necessary (on
> both sides), anyone who isn't interested in that type of review
> should not be looking for IETF Standardization.
>
> Put differently, some of us who might not be resistant to a
> collection of documents that made up a DNSBL standard are
> extremely resistant to getting documents piecemeal and maybe out
> of the order of logical dependencies and get even more resistant
> when people try to justify one of the pieces on the basis that
> all claimed operational problems are someone else's fault and
> therefore not relevant to the document under discussion.
>
> Your opinion may differ, but my personal impression of the rough
> consensus is that neither this document, nor any of the probably
> followups, should be approved for the standards-track or BCP
> until some fairly large set of issues are addressed in a
> meaningful way.  There have been a lot of suggestions about how
> to do that, most of which I consider constructive, and there may
> not be consensus about which ones of  them are optimal.  My own
> favorite starts with a draft WG charter whose function includes
> mapping out all of the documents needed to make a complete
> picture; others may have better (or other) ideas.  The next step
> is probably up to the advocates of this document and, IMO,
> further attempts to narrow the discussion or dismiss the various
> concerns without either a charter or one or more new or revised
> documents are not likely to result in the sort of progress you
> would like.
>
>    best wishes,
>     john
>
>
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

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