Re: [Iasa20] draft-ietf-iasa2-rfc2418bis-01.txt

John C Klensin <john-ietf@jck.com> Sun, 21 October 2018 16:11 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF0412D4F0; Sun, 21 Oct 2018 09:11:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 C9rxpmtkGWyp; Sun, 21 Oct 2018 09:11:49 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E2C3127B92; Sun, 21 Oct 2018 09:11:49 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1gEGKQ-000K6u-9v; Sun, 21 Oct 2018 12:11:46 -0400
Date: Sun, 21 Oct 2018 12:11:41 -0400
From: John C Klensin <john-ietf@jck.com>
To: Bob Hinden <bob.hinden@gmail.com>, Scott Bradner <sob@sobco.com>
cc: IASA 2 WG <iasa20@ietf.org>, IETF <ietf@ietf.org>
Subject: Re: [Iasa20] draft-ietf-iasa2-rfc2418bis-01.txt
Message-ID: <E06878F39DD129B70AF5165B@PSB>
In-Reply-To: <DB25043B-1CE7-4455-9493-4C6E9A07EDC1@gmail.com>
References: <4915CD062D28D607D3D4AD44@PSB> <8906b727-f9c3-e7e1-164b-f7b88e48e74b@gmail.com> <1C77C07809EFB402E3E10907@PSB> <DE6E9C0D-C46B-4010-9E6D-8438DE687275@sobco.com> <DB25043B-1CE7-4455-9493-4C6E9A07EDC1@gmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/vylvMHk5DxMWFTkPAYBkLUYanlY>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: <https://mailarchive.ietf.org/arch/browse/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, 21 Oct 2018 16:11:52 -0000

Bob,

I don't think Scott suggested a consolidated update to all of
these documents.  Having started this thread, I certainly
didn't.   If there is a substantive reason to rework a document,
by all means do that... especially if the scope of the original
document is very narrow.  However, if the only change that is
required to a given document simple substitution, especially in
one place and especially if the document has very broad scope,
let's try to find a way to do a narrow update rather than
replacing/obsoleting the document.

Like Scott, I hope that could be done by a single document that
draws all of the trivial updates together.  But, if it cannot, I
believe we would be far better off with, using 2418 as an
example, with a one (substantive)-paragraph RFC changing the job
title rather than issuing a new, supposedly-complete, document
and obsoleting the original one.  That also minimizes the risk
of unintended consequences.  Or, while I had forgotten until
Rich's note caused me to review the history of 2418, for these
trivial cases, we could simply follow the POISSON/RFC Editor
precedent, treat the change of title as a simple editorial
matter, record it in an erratum identified as "save for
revision", and move on.  

If one wants to minimize the amount of community effort spent
per unit improvement, the latter is almost certainly the right
option for those simple cases.

  best,
     john

--On Sunday, October 21, 2018 08:39 -0700 Bob Hinden
<bob.hinden@gmail.com> wrote:

> Scott,
> 
>> On Oct 20, 2018, at 3:45 PM, Scott O. Bradner <sob@sobco.com>
>> wrote:
>> 
>> sure seems a lot more efficient to just have one short RFC
>> instead of a bunch of RFCs that wind up changing well known
>> RFC #s for almost no meaningful changes - i
> 
> I think it depends on the document.   While there are some
> that could be handled this way, others are more complicated.
> For example, Jason and I are working on RFC7437bis " IAB,IESG,
> and IETF LLC Selection, Confirmation, and Recall Process:
> Operation of the IETF Nominating and Recall Committees".
> That's gotten more complicated because the IETF Trust
> Trustees and LLC Directors are being (partially) selected by
> the NomCom under the IASA2.0 work.  The changes are not, for
> example, s/IAOC/LLC/.  There are other changes that make sense
> like having the chairs communicate direclty with the NomCom
> instead it going through the IETF Executive Director (now
> called Managing Director, IETF Secretariat).  Now starting to
> look at bringing in the Ombudsman changes from RFC7776.
> 
> I suspect we are going to have the new ISAS 2 model for a
> while, good to get this right where it matters.
> 
> Bob
> 
>> 
>> (never mind having to change training documents to point to
>> the changed RFC numbers)
>> 
>> Scott
>> 
>>> On Oct 20, 2018, at 5:27 PM, John C Klensin
>>> <john-ietf@jck.com> wrote:
>>> 
>>> 
>>> 
>>> --On Sunday, October 21, 2018 10:07 +1300 Brian E Carpenter
>>> <brian.e.carpenter@gmail.com> wrote:
>>> 
>>>> fwiw I agree. There is no reference to IASA in 2418, for
>>>> obvious reasons.
>>>> 
>>>> From a practical point of view, any terminology issue could
>>>> be handled
>>>> as an erratum with disposition "wait for update".
>>> 
>>> That, IMO, would be an even better solution than creating an
>>> updating document that says "any time earlier documents say
>>> 'IETF Executive Director' replace it with..." and similar
>>> things and then hunting down the relevant documents and
>>> marking them as updated.
>>> 
>>> Depending on how compulsive the WG and relevant AD are
>>> feeling, I think either would work.  But we really have
>>> better ways to spend our time than replacing a process
>>> document to change a title... or at least I hope we do.
>>> 
>>> Frankly, the only good reason I can see for generating all of
>>> these IASA2 documents just to change terminology is to create
>>> enough noise that the community doesn't notice and pay
>>> attention to changes that actually might be controversial.
>>> I trust and assume that is not the intent of anyone involved.
>>> 
>>>   john
>>> 
>>> 
>>> 
>> 
>> _______________________________________________
>> iasa20 mailing list
>> iasa20@ietf.org
>> https://www.ietf.org/mailman/listinfo/iasa20
>