Re: RFC2418bis (was - Re: What is a "management position? [Last Call: <draft-farrresnickel-harassment-05.txt> (IETF Anti-Harassment Procedures) to Best Current Practice])

Dave Crocker <dhc@dcrocker.net> Sun, 15 March 2015 20:19 UTC

Return-Path: <dhc@dcrocker.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D15E71A1B74; Sun, 15 Mar 2015 13:19:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HaU81f37w8sh; Sun, 15 Mar 2015 13:19:15 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C46771A1B6D; Sun, 15 Mar 2015 13:19:15 -0700 (PDT)
Received: from [192.168.1.87] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t2FKJ1Pk008745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 15 Mar 2015 13:19:15 -0700
Message-ID: <5505E933.4030100@dcrocker.net>
Date: Sun, 15 Mar 2015 13:18:59 -0700
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: IETF Discussion List <ietf@ietf.org>
Subject: Re: RFC2418bis (was - Re: What is a "management position? [Last Call: <draft-farrresnickel-harassment-05.txt> (IETF Anti-Harassment Procedures) to Best Current Practice])
References: <20150116152211.25947.49086.idtracker@ietfa.amsl.com> <20150117174430.9A0471ACE15@ietfa.amsl.com> <20150306163724.GA32205@verdi> <tsl385im2yp.fsf@mit.edu> <781553AA-EA2C-4057-9888-491C80A780DA@piuha.net> <54FE045D.3080606@qti.qualcomm.com> <tslr3sxep1l.fsf@mit.edu> <54FE6297.4090008@qti.qualcomm.com> <tslzj7i2wid.fsf@mit.edu> <55019E72.4090004@qti.qualcomm.com> <tslfv9a2t6p.fsf@mit.edu> <36671C44-DE53-4AC9-B8EA-465BF97B2FDB@piuha.net> <tsly4n0zo6g.fsf@mit.edu> <550350C4.9040201@qti.qualcomm.com> <5503914A.7060209@gmail.com> <5503BF22.5020902@gmail.com> <2AE2D092-C32A-46EB-88CA-71366965F4D7@cisco.com> <5505D873.1040203@gmail.com> <5505E6A4.8040802@dcrocker.net>
In-Reply-To: <5505E6A4.8040802@dcrocker.net>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Sun, 15 Mar 2015 13:19:15 -0700 (PDT)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/8I0jirf7kt75DF4alsPnRcJY4Zg>
Cc: "iesg@ietf.org" <iesg@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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>
X-List-Received-Date: Sun, 15 Mar 2015 20:19:17 -0000

On 3/15/2015 1:08 PM, Dave Crocker wrote:
> Ralph Droms and I recently undertook to bring RFC2418 up to current IETF
> practices.

To save further folk time and effort trying to compare RFC2418 with
draft--2418bis:

   0.  The document cites the 'nature' of the changes it made.  There is
no intent -- and I believe no content -- that changes any existing
practice; to the contrary the intent was to better document current
practice.

   1.  In textual terms, changes to the document are massive.  A diff
isn't possible.

   2.  No, I didn't maintain a log of specific changes.  Yes, that means
the document requires a completely fresh read.

   3.  The approach in making the changes had these goals:

   *  The previous document has a bunch of IETF tutorial material, as
background to the document's substance.  There is now more and maybe
better text the IETF uses.  We've replaced such text with pointers to
the other web pages and documents.

   *  The document expands upon various common and/or desirable
practices that are established in the IETF but possibly not treated as
thoroughly in the previous version.

   *  The document moves things around quite a bit, so that a newbie can
learn the meat of working group operation, separate from the surrounding
IETF formalities (bureaucracy). The intent is for the document to
function better both as introduction and for reference.

   *  The document adds information, such as pointers to new tools and
documents, that have become integrated into working group life.

   *  The document draws a line between what is formally required,
versus what is common or otherwise permitted.  So it teaches a 'core'
and then quite a few 'options'.

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net