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
- Re: several messages der Mouse
- Re: several messages David Morris
- Re: several messages Dean Anderson
- Re: several messages Randy Presuhn
- Re: several messages David Morris
- Re: several messages Matthias Leisi
- Re: several messages Steve Linford
- Re: several messages Peter Dambier
- Re: several messages Steve Linford
- Re: several messages Keith Moore
- Re: several messages der Mouse
- Re: several messages Chris Lewis
- Re: several messages Mark Andrews
- Re: several messages der Mouse
- Re: several messages Chris Lewis
- Re: several messages David Romerstein
- Re: several messages Randy Presuhn
- Re: several messages Chris Lewis
- Re: several messages David Romerstein
- Re: several messages David Romerstein
- Re: several messages Keith Moore
- Re: several messages Chris Lewis
- Re: several messages Al Iverson
- More anti-spam (was: Re: several messages) John C Klensin
- RE: several messages michael.dillon
- Re: several messages Matthias Leisi
- Re: several messages Mark Andrews
- Re: several messages David Morris
- Re: several messages Al Iverson
- Re: uncooperative DNSBLs, was several messages John Levine
- Re: uncooperative DNSBLs, was several messages Jim Hill
- Re: several messages John C Klensin
- Re: several messages Al Iverson
- RE: several messages Hallam-Baker, Phillip
- Re: uncooperative DNSBLs, was several messages Matthias Leisi
- Re: uncooperative DNSBLs, was several messages Al Iverson
- RE: several messages Anthony Purcell
- Re: uncooperative DNSBLs, was several messages Dave CROCKER
- Re: several messages der Mouse
- Re: uncooperative DNSBLs, was several messages Andrew Sullivan
- Re: uncooperative DNSBLs, was several messages David Romerstein
- Re: uncooperative DNSBLs, was several messages Jim Hill
- Re: several messages Chris Lewis
- Re: uncooperative DNSBLs, was several messages Chris Lewis
- Re: uncooperative DNSBLs, was several messages John C Klensin
- Re: uncooperative DNSBLs, was several messages Dave CROCKER
- Re: uncooperative DNSBLs, was several messages Tony Finch
- Re: uncooperative DNSBLs, was several messages Andrew Sullivan
- Re: uncooperative DNSBLs, was several messages John C Klensin
- Re: uncooperative DNSBLs, was several messages Matthias Leisi
- Re: uncooperative DNSBLs, was several messages Al Iverson
- Re: uncooperative DNSBLs, was several messages Andrew Sullivan
- Re: uncooperative DNSBLs, was several messages John C Klensin
- Re: uncooperative DNSBLs, was several messages Ted Hardie
- Re: uncooperative DNSBLs, was several messages Matthias Leisi
- Re: uncooperative DNSBLs, was several messages Ted Hardie
- Re: uncooperative DNSBLs, was several messages Tony Finch
- Context specific semantics was Re: uncooperative … Ted Hardie
- Clarifying harm to DNS (was: uncooperative DNSBLs… Andrew Sullivan
- Re: Context specific semantics was Re: uncooperat… Ted Hardie
- Re: uncooperative DNSBLs, IETF misinformation (wa… Steve Linford
- RE: Context specific semantics was Re: uncooperat… Hallam-Baker, Phillip
- Re: uncooperative DNSBLs, was several messages Peter Dambier
- Re: uncooperative DNSBLs, was several messages David Romerstein
- Re: uncooperative DNSBLs, was several messages Peter Dambier
- Re: uncooperative DNSBLs, was several messages Keith Moore
- Re: uncooperative DNSBLs, was several messages Chris Lewis
- RE: uncooperative DNSBLs, IETF misinformation (wa… michael.dillon
- Re: uncooperative DNSBLs, IETF misinformation (wa… Steve Linford
- RE: uncooperative DNSBLs, IETF misinformation (wa… michael.dillon
- Re: Context specific semantics was Re: uncooperat… Tony Finch
- Re: Context specific semantics was Re: uncooperat… John Levine
- RE: Context specific semantics was Re: uncooperat… Hardie, Ted
- RE: Context specific semantics was Re: uncooperat… Tony Finch
- Re: several messages Rich Kulawiec
- Re: uncooperative DNSBLs, was several messages Rich Kulawiec
- Re: uncooperative DNSBLs, IETF misinformation (wa… Al Iverson
- Re: Context specific semantics was Re: uncooperat… Ted Hardie
- RE: Context specific semantics was Re: uncooperat… Ted Hardie
- Re: several messages John C Klensin
- Re: several messages Al Iverson
- Re: Context specific semantics was Re: uncooperat… John L
- RE: uncooperative DNSBLs, IETF misinformation (wa… michael.dillon
- Re: uncooperative DNSBLs, IETF misinformation (wa… Al Iverson
- RE: uncooperative DNSBLs, IETF misinformation (wa… michael.dillon
- Re: several messages John C Klensin
- Re: several messages Chris Lewis
- Re: uncooperative DNSBLs, IETF misinformation (wa… Keith Moore
- Re: several messages Al Iverson
- RE: several messages michael.dillon
- Re: uncooperative DNSBLs, IETF misinformation (wa… Al Iverson
- Re: Context specific semantics was Re: uncooperat… Ted Hardie
- Re: Context specific semantics was Re: uncooperat… Douglas Otis
- Re: uncooperative DNSBLs, IETF misinformation (wa… Theodore Tso
- Re: Context specific semantics was Re: uncooperat… Theodore Tso
- Re: uncooperative DNSBLs, IETF misinformation (wa… Chris Lewis
- Re: more bad ideas, was uncooperative DNSBLs, was… John Levine
- Re: more bad ideas, was uncooperative DNSBLs, was… Chris Lewis
- Re: Context specific semantics was Re: uncooperat… John L
- Detecting and disabling bad DNSBLs Peter Dambier
- Re: Detecting and disabling bad DNSBLs Steve Linford
- Re: several messages Pekka Savola
- Re: more bad ideas, was uncooperative DNSBLs, was… Keith Moore
- Re: several messages Rich Kulawiec
- Is USA qualified for 2.3 of draft-palet-ietf-meet… YAO
- RE: [73attendees] Is USA qualified for 2.3 ofdraf… Song Haibin
- Re: several messages Tom.Petch
- Re: [73attendees] Is USA qualified for 2.3 of dra… Phillip Hallam-Baker
- Re: [73attendees] Is USA qualified for 2.3 of dra… james woodyatt
- Re: several messages John C Klensin