Re: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis
Russ Housley <housley@vigilsec.com> Thu, 19 June 2008 17:56 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 0AB073A694C; Thu, 19 Jun 2008 10:56:47 -0700 (PDT)
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 6F2763A6A1A for <ietf@core3.amsl.com>; Thu, 19 Jun 2008 10:56:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -88.998
X-Spam-Level:
X-Spam-Status: No, score=-88.998 tagged_above=-999 required=5 tests=[AWL=-6.400, BAYES_00=-2.599, URIBL_BLACK=20, USER_IN_WHITELIST=-100, WHOIS_NETSOLPR=0.001]
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 vn4eLNRXaWS5 for <ietf@core3.amsl.com>; Thu, 19 Jun 2008 10:56:45 -0700 (PDT)
Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by core3.amsl.com (Postfix) with SMTP id 0CA443A68C2 for <ietf@ietf.org>; Thu, 19 Jun 2008 10:56:44 -0700 (PDT)
Received: (qmail 23652 invoked by uid 0); 19 Jun 2008 17:50:52 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (207.168.80.186) by woodstock.binhost.com with SMTP; 19 Jun 2008 17:50:52 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Thu, 19 Jun 2008 13:50:45 -0400
To: dcrocker@bbiw.net
From: Russ Housley <housley@vigilsec.com>
Subject: Re: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis
In-Reply-To: <485A353B.30403@dcrocker.net>
References: <8832006D4D21836CBE6DB469@klensin-asus.vbn.inter-touch.net> <485590E2.3080107@gmail.com> <p06250116c47c330c7dd0@[75.145.176.242]> <4856DE3A.3090804@gmail.com> <C122F91B-59B0-49AC-ABBC-6752217C4E47@NOKIA.COM> <20080619024147.9146C3A6938@core3.amsl.com> <485A353B.30403@dcrocker.net>
Mime-Version: 1.0
Message-Id: <20080619175645.0CA443A68C2@core3.amsl.com>
Cc: ietf@ietf.org, iesg@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-Archive: <http://www.ietf.org/pipermail/ietf>
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
Dave: I'm not sure I did a wise thing by joining the discussion, but in for a penny, in for a pound ... >>- The examples in RFC 821 use different domains from the ones in RFC 2821. > >Where are the reports of problems with with that aspect of RFC 2821? > >Changes from Proposed to Draft are expected to be for fixing minor, >actual problems with the specification, and they are quite clearly >*not* for revisting old issues or playing around with new preferences. The first hint of this issue surfaces during Last Call. It was one small paragraph in the SecDir Review, but a casual observation might have missed it due to the volume of discussion around A and AAAA DNS records. The SecDir Review said: - "isif.usc.edu" is used as an example in section 4.3.1. Some of the examples in the appendices also use non-example hostnames. Personally, I don't care, the meaning is obvious and inoffensive, but since some of the examples have been rewritten in terms of example.com etc, this may have been an oversight. When I highlighted this paragraph, the document PROTO shepherd pointed out that the "isif.usc.edu" and "postel@isi.edu" were left in the document as a tribute to Jon. No one has objected to this. This lead to a discussion of the domain names in the rest of the document. >>If the document were being advanced to Draft Standard with no >>changes at all, then I think it would be unreasonable to anyone ask >>for a change to address this issue. However, other changes were >>deemed necessary. Given that situation, it seems appropriate to >>consider current guidance. This guidance is referenced in the >>appeal. The I-D Checklist (IDnits, >>http://www.ietf.org/ID-Checklist.html), Section 6, says: >> Addresses used in examples SHOULD preferably use >> fully qualified domain names instead of literal IP >> addresses, and preferably use example fqdn's such as >> foo.example.com instead of real-world fqdn's. > > >1. When did the nits list gain authoritative control as a source >directive for normative detail of IETF specification content? I was >under the impression that it was strictly a compendium of >requirements from elsewhere. > >2. You parsed the sentence incorrectly. The SHOULD applies only to >the first clause. The second clause notably repeats the >"preferably" but without the SHOULD. This type of parallel >constructive is used quite explicitly to set a different context >between clauses. Hence the second clause is not normative. (The >term "SHOULD preferably" also suggests some problematic -- or at >least odd -- writing, given the semantics of the SHOULD.") Upon detailed study, I see that the paragraph could be more clear. I've asked the author if he is willing to propose revised text. Vacation schedules will keep this from happening in the next few days. >>RFC 2119 has a pretty clear definition of "SHOULD". It says: >> This word, or the adjective "RECOMMENDED", mean that there >> may exist valid reasons in particular circumstances to ignore a >> particular item, but the full implications must be understood and >> carefully weighed before choosing a different course. > >Absent any explanation from you, you appear to be treating SHOULD >the same as MUST. I think I provided my thinking in the previous message. >As John noted, there was extensive Drums wg consideration of this >topic. This means that your requirement for changing the examples >seeks to override the explicit considerations of an IETF working group. > >If you feel that group was rogue, please explain. If you do not, >what is the basis for your view that its considerations were >sufficiently faulty to warrant being overridden? Prior to the appeal, this aspect of John's rationale was not raised. It was not raised by John, the document PROTO shepherd, or the IESG member sponsoring the document. >And most importantly, why is not of this explanation already >documented in the tracker? Since this issue has been use in DISCUSS ballot positions for more than 5 years, it seems to me like there is adequate context to not document every step in the though process. >>This document also uses "foo.com", "foo.org", "bar.org", >>"foo-u.edu", and "generic.com" in examples. I have not heard >>anyone offer "valid reasons" for using them instead of the ones in >>BCP 37. I have heard people say that they are not causing >>harm. That is not the same. We have seen examples that use real >>IP addresses and domain names cause harm. The excessive traffic >>sent to one NTP server comes to mind. > >First is the use of "valid", which implies there are arguments >deemed invalid. Which arguments are you dismissing and why? Since >the ietf list discussion has seen serious arguments put forward by >serious and experienced contributors, my question is not merely pro forma. > >Second is the logic error that some examples of harm elsewhere are a >sufficient basis for requiring the current change, independent of >the *absence* of problems with this heavily-used specification. The >direct absence of problems constitutes positive data in favor of >retaining the current text in rfc2821bis. > >Why should your indirect negative data override the direct positive data? You misunderstand my point. RFC 2119 uses "valid" in the definition of "SHOULD." That is the reason for quote marks in my text. Prior to the discussion of the appeal on this thread, lack of harm in this context was not raised. It was not raised by John or the document PROTO shepherd. This might be a reason to ignore the "SHOULD." That is a discussion could have happened, but it didn't. >>The IESG has been using DISCUSS positions since before 2003 to >>remove real domain names. I'm sure that some have slipped >>through. A couple have been pointed out in this thread. > >Yet, for all of the IETF's formal documentation of technical and >stylistic requirements, we do not seem to have any community >consensus document -- and not even an IESG document -- that >justifies asserting this as a requirement. That seems to be the crux of the appeal. Does every possible thing upon which an AD can raise a DISCUSS position need to align with a written rule? Don't we select leaders because we have some confidence in their judgement? Russ _______________________________________________ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
- Appeal against IESG blocking DISCUSS on draft-kle… John C Klensin
- Re: Appeal against IESG blocking DISCUSS on draft… Lakshminath Dondeti
- RE: Appeal against IESG blocking DISCUSS on draft… Eastlake III Donald-LDE008
- RE: Appeal against IESG blocking DISCUSS on draft… John C Klensin
- Re: Appeal against IESG blocking DISCUSS on draft… Brian E Carpenter
- Re: Appeal against IESG blocking DISCUSS on draft… Brian E Carpenter
- RE: Appeal against IESG blocking DISCUSS on draft… Eric Gray
- Re: Appeal against IESG blocking DISCUSS on draft… Pete Resnick
- Re: Appeal against IESG blocking DISCUSS on draft… Tony Hansen
- RE: Appeal against IESG blocking DISCUSS on draft… John C Klensin
- Re: Appeal against IESG blocking DISCUSS on draft… Robert Elz
- Re: Appeal against IESG blocking DISCUSS on draft… TSG
- Re: Appeal against IESG blocking DISCUSS on draft… TSG
- Re: Appeal against IESG blocking DISCUSS on draft… Brian E Carpenter
- RE: Appeal against IESG blocking DISCUSS on draft… John C Klensin
- Re: Appeal against IESG blocking DISCUSS on draft… Frank Ellermann
- Re: Appeal against IESG blocking DISCUSS on draft… Dave Crocker
- Re: Appeal against IESG blocking DISCUSS on draft… Dave Crocker
- Re: Appeal against IESG blocking DISCUSS on draft… Dave Crocker
- Re: Appeal against IESG blocking DISCUSS on draft… Brian Dickson
- Re: Appeal against IESG blocking DISCUSS on draft… Simon Josefsson
- Re: Appeal against IESG blocking DISCUSS on draft… eburger
- Re: Appeal against IESG blocking DISCUSS on draft… David Kessens
- Re: Appeal against IESG blocking DISCUSS on draft… Lakshminath Dondeti
- Re: Appeal against IESG blocking DISCUSS on draft… Fred Baker
- Re: Appeal against IESG blocking DISCUSS on draft… Fred Baker
- Re: Appeal against IESG blocking DISCUSS on draft… Lakshminath Dondeti
- RE: Appeal against IESG blocking DISCUSS on draft… Debbie Garside
- Re: Appeal against IESG blocking DISCUSS on draft… Marshall Eubanks
- Re: Appeal against IESG blocking DISCUSS on draft… Steven M. Bellovin
- Re: Appeal against IESG blocking DISCUSS on draft… Robert Elz
- RE: Appeal against IESG blocking DISCUSS on draft… Eastlake III Donald-LDE008
- Re: Appeal against IESG blocking DISCUSS on draft… Spencer Dawkins
- RE: Appeal against IESG blocking DISCUSS on draft… Scott O. Bradner
- Re: Appeal against IESG blocking DISCUSS on draft… John C Klensin
- Re: Appeal against IESG blocking DISCUSS on draft… Pete Resnick
- Re: Appeal against IESG blocking DISCUSS on draft… Marshall Eubanks
- Re: Appeal against IESG blocking DISCUSS on draft… Eliot Lear
- Re: Appeal against IESG blocking DISCUSS on draft… TSG
- example TLH (was: Appeal against IESG blocking DI… Frank Ellermann
- Re: Appeal against IESG blocking DISCUSS on draft… LB
- Re: Appeal against IESG blocking DISCUSS on draft… Marshall Eubanks
- Re: Appeal against IESG blocking DISCUSS on draft… Harald Alvestrand
- Re: Appeal against IESG blocking DISCUSS on draft… Simon Josefsson
- Limits of RFC 2606 (Was: Appeal against IESG bloc… Stephane Bortzmeyer
- Re: Appeal against IESG blocking DISCUSS on draft… Bob Hinden
- RE: Appeal against IESG blocking DISCUSS on draft… Debbie Garside
- RE: Appeal against IESG blocking DISCUSS on draft… Debbie Garside
- Re: Appeal against IESG blocking DISCUSS on draft… Robert Elz
- Re: Limits of RFC 2606 Frank Ellermann
- Re: Appeal against IESG blocking DISCUSS on draft… Frank Ellermann
- Re: Appeal against IESG blocking DISCUSS on draft… Robert Elz
- RE: Appeal against IESG blocking DISCUSS on draft… Dave Cridland
- RE: Appeal against IESG blocking DISCUSS on draft… Dave Cridland
- Re: Appeal against IESG blocking DISCUSS on draft… Frank Ellermann
- Re: Appeal against IESG blocking DISCUSS on draft… Ralph Droms
- Re: Appeal against IESG blocking DISCUSS on draft… Spencer Dawkins
- RE: Appeal against IESG blocking DISCUSS on draft… Dave Cridland
- Re: Appeal against IESG blocking DISCUSS on draft… Ned Freed
- Re: Appeal against IESG blocking DISCUSS on draft… Russ Housley
- RE: Appeal against IESG blocking DISCUSS on draft… Debbie Garside
- Re: Appeal against IESG blocking DISCUSS on draft… Russ Housley
- RE: Appeal against IESG blocking DISCUSS on draft… John C Klensin
- Re: Appeal against IESG blocking DISCUSS on draft… Ted Hardie
- RE: Appeal against IESG blocking DISCUSS on draft… Pete Resnick
- Re: Appeal against IESG blocking DISCUSS on draft… Frank Ellermann
- Re: Appeal against IESG blocking DISCUSS on draft… Eliot Lear
- Re: Appeal against IESG blocking DISCUSS on draft… Ted Hardie
- Re: Appeal against IESG blocking DISCUSS on draft… Robert Elz
- Re: Appeal against IESG blocking DISCUSS on draft… SM
- RE: Appeal against IESG blocking DISCUSS on draft… Debbie Garside
- RE: Appeal against IESG blocking DISCUSS on draft… Debbie Garside
- Re: Appeal against IESG blocking DISCUSS on draft… Russ Housley
- Re: Appeal against IESG blocking DISCUSS on draft… Randy Presuhn
- Re: Appeal against IESG blocking DISCUSS on draft… John Levine
- Re: Appeal against IESG blocking DISCUSS on draft… Dave Cridland
- Re: Appeal against IESG blocking DISCUSS on draft… Russ Housley
- Re: Appeal against IESG blocking DISCUSS on draft… Russ Housley
- Re: Appeal against IESG blocking DISCUSS on draft… John C Klensin
- Re: Appeal against IESG blocking DISCUSS on draft… John C Klensin
- Re: Appeal against IESG blocking DISCUSS on draft… Pete Resnick
- Re: Appeal against IESG blocking DISCUSS on draft… Russ Housley
- Re: Appeal against IESG blocking DISCUSS on draft… Bernard Aboba
- Re: Appeal against IESG blocking DISCUSS on draft… Harald Tveit Alvestrand
- Re: Appeal against IESG blocking DISCUSS on draft… Russ Housley
- RE: Appeal against IESG blocking DISCUSS on draft… Bernard Aboba
- RE: Appeal against IESG blocking DISCUSS on draft… Russ Housley
- Re: Appeal against IESG blocking DISCUSS on draft… Russ Housley
- Re: Appeal against IESG blocking DISCUSS on draft… Stewart Bryant
- Re: Appeal against IESG blocking DISCUSS on draft… Julian Reschke
- Measuring IETF and IESG trends (Was: Re: Appeal a… Jari Arkko
- Re: Appeal against IESG blocking DISCUSS on draft… Spencer Dawkins
- Re: Measuring IETF and IESG trends (Was: Re: Appe… Marshall Eubanks
- Qualitative Analysis of IETF and IESG trends (Re:… Lakshminath Dondeti
- Re: Qualitative Analysis of IETF and IESG trends … Melinda Shore
- RE: Qualitative Analysis of IETF and IESG trends … Ross Callon
- Re: Qualitative Analysis of IETF and IESG trends … Jari Arkko
- Re: Qualitative Analysis of IETF and IESG trends … Brian E Carpenter
- Re: Qualitative Analysis of IETF and IESG trends … Spencer Dawkins
- Re: Qualitative Analysis of IETF and IESG trends … John C Klensin
- Re: Qualitative Analysis of IETF and IESG trends … Lakshminath Dondeti
- Re: Qualitative Analysis of IETF and IESG trends … Dave Crocker
- Re: Appeal against IESG blocking DISCUSS on draft… Dave Crocker
- Re: Appeal against IESG blocking DISCUSS on draft… Dave Crocker
- Re: Appeal against IESG blocking DISCUSS on draft… Dave Crocker
- Re: Appeal against IESG blocking DISCUSS on draft… Dave Crocker
- Re: Qualitative Analysis of IETF and IESG trends … Lakshminath Dondeti
- Re: Qualitative Analysis of IETF and IESG trends … Lakshminath Dondeti
- Re: Qualitative Analysis of IETF and IESG trends … Lakshminath Dondeti
- Re: Appeal against IESG blocking DISCUSS on draft… SM
- Re: Appeal against IESG blocking DISCUSS on draft… John C Klensin
- Re: Qualitative Analysis of IETF and IESG trends … Brian E Carpenter
- Re: Qualitative Analysis of IETF and IESG trends … John C Klensin
- Re: Qualitative Analysis of IETF and IESG trends … SM
- Re: Qualitative Analysis of IETF and IESG trends Frank Ellermann
- Re: Qualitative Analysis of IETF and IESG trends Paul Hoffman
- Re: Qualitative Analysis of IETF and IESG trends … Lakshminath Dondeti
- Re: Qualitative Analysis of IETF and IESG trends … SM
- Re: Qualitative Analysis of IETF and IESG trends … Lakshminath Dondeti
- Re: Qualitative Analysis of IETF and IESG trends … Russ Housley
- Re: Qualitative Analysis of IETF and IESG trends … Brian E Carpenter
- Re: Qualitative Analysis of IETF and IESG trends … Jari Arkko
- Re: Qualitative Analysis of IETF and IESG trends … Ted Hardie
- Re: Qualitative Analysis of IETF and IESG trends … Joel M. Halpern
- Re: Qualitative Analysis of IETF and IESG trends … Brian E Carpenter
- Re: Qualitative Analysis of IETF and IESG trends … Jari Arkko
- RE: Qualitative Analysis of IETF and IESG trends … Romascanu, Dan (Dan)