Re: [Ext] Re: [rfc-i] Evolving document sources over a long time (Re: Comments on draft-roach-bis-documents-00)

Carsten Bormann <cabo@tzi.org> Thu, 23 May 2019 11:17 UTC

Return-Path: <cabo@tzi.org>
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 4A7221200D6 for <ietf@ietfa.amsl.com>; Thu, 23 May 2019 04:17:07 -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 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 VaCa801z18K1 for <ietf@ietfa.amsl.com>; Thu, 23 May 2019 04:17:06 -0700 (PDT)
Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFBF5120019 for <ietf@ietf.org>; Thu, 23 May 2019 04:17:05 -0700 (PDT)
Received: from [192.168.217.106] (p54A6CC75.dip0.t-ipconnect.de [84.166.204.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 458n5W5m1hzys2; Thu, 23 May 2019 13:17:03 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Subject: Re: [Ext] Re: [rfc-i] Evolving document sources over a long time (Re: Comments on draft-roach-bis-documents-00)
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <CAA=duU1=nJbz-rcCnDJ0Bq6xqbPGjS1rJ5azcnX3m7e_63fnzA@mail.gmail.com>
Date: Thu, 23 May 2019 13:17:03 +0200
Cc: Julian Reschke <julian.reschke@gmx.de>, Michelle Cotton <michelle.cotton@iana.org>, IETF Discussion Mailing List <ietf@ietf.org>, David Noveck <davenoveck@gmail.com>
X-Mao-Original-Outgoing-Id: 580303021.309374-27e5a1a18568860ba68a0928120099eb
Content-Transfer-Encoding: quoted-printable
Message-Id: <0EA39B2C-5F34-4FD9-92DF-7D705137BBC7@tzi.org>
References: <CADaq8jdRMUZAN3rRXoActXqvGpkgx_-kW67uwzGLtVPoh7LfAQ@mail.gmail.com> <6E787E2A-18F2-4EFE-BFBA-61B1B4300930@tzi.org> <CADaq8jc1KJwC=Ypoo9a+-=Me=GP5tgX=2kcfUd56o53Mcu05kw@mail.gmail.com> <9179590B-C513-44DC-906C-16534DA8EC51@tzi.org> <1852d84b-48cc-0129-3564-6ec9b92c4315@gmx.de> <8A7B4E94-DBCD-4EE3-8FEA-EA642F1071BF@tzi.org> <CADaq8jeLwELxGM_zWG_OhiZ3nkm_F_a7A71B7aEv+xDdBmhYqg@mail.gmail.com> <CADaq8jciU-yC1KDmXfYc7rqc9vtS0c3D_fWeFN=GEw4bxchMkA@mail.gmail.com> <74f72a19-a400-1cf2-a2a0-5abbf3646b43@nostrum.com> <866F6E4F-C640-46A6-AADF-EC4C81F44B7D@iana.org> <CADaq8jcARXdm=x5xcCurPnRfORApcnHQL2-n-ccfSSQT3V1Twg@mail.gmail.com> <CAA=duU1+Re=EiAiPkLCm3MHrHthwy4OUhzx0qvKxam2GVnd=fA@mail.gmail.com> <00df01d5113d$49183c60$4001a8c0@gateway.2wire.net> <CAA=duU1PyCRgnm3ip8GkTzEuLRC3hquvJRv_K511Xd45DCEd7A@mail.gmail.com> <d3a0b3bd-ba90-1655-a0cf-ad2af3cc6202@gmx.de> <CAA=duU1=nJbz-rcCnDJ0Bq6xqbPGjS1rJ5azcnX3m7e_63fnzA@mail.gmail.com>
To: "Andrew G. Malis" <agmalis@gmail.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/6RB1Jvfu5m7zlDTqgSXThdu2xnU>
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: Thu, 23 May 2019 11:17:07 -0000

On May 23, 2019, at 13:05, Andrew G. Malis <agmalis@gmail.com> wrote:
> 
> bis RFC as close to the original as possible

In a case we are looking at right now, that would actually be true with respect to the contribution of the spec to the registry content (the registry probably should be updated to point to the bis).  But it is a bit weird to talk about the initial assignments for a registry that has since gained dozens of additional entries…

I think the IANA considerations should contain:
— all “new” registries defined by this spec
— all procedures/policies for these (might want to update)
— registry entries (in old or new registries) that should now point to the bis document as documentation (need not be wholesale — maybe the bis is dropping some cobwebs)

Usually, for RFCs the IANA considerations should already be in past tense, so that will not be a big change.  If the diff is manageable, IANA should be able to see from that what the actual actions are (new new registries, new new entries…).

Note that the documentation of the existing registered entry might very well be updated in the bis document, so updating the pointer from IANA to the bis is important.

Grüße, Carsten