Re: [openpgp] rfc4880bis and draft-openpgp-iana-registry-updates-01

Benjamin Kaduk <kaduk@mit.edu> Sat, 01 December 2018 00:19 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 458F7130EF7 for <openpgp@ietfa.amsl.com>; Fri, 30 Nov 2018 16:19:51 -0800 (PST)
X-Quarantine-ID: <VmFTtn7P9Ypz>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by outgoing.mit[...]
X-Spam-Flag: NO
X-Spam-Score: -3.999
X-Spam-Level:
X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001, URIBL_CSS=0.1, URIBL_CSS_A=0.1] 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 VmFTtn7P9Ypz for <openpgp@ietfa.amsl.com>; Fri, 30 Nov 2018 16:19:49 -0800 (PST)
Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67CB3126F72 for <openpgp@ietf.org>; Fri, 30 Nov 2018 16:19:49 -0800 (PST)
X-AuditID: 1209190d-58fff70000005ec4-58-5c01d3a37037
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id CB.CF.24260.4A3D10C5; Fri, 30 Nov 2018 19:19:48 -0500 (EST)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.14.7/8.9.2) with ESMTP id wB10Jk5p031449; Fri, 30 Nov 2018 19:19:46 -0500
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) œby outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id wB10JgMq032130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 30 Nov 2018 19:19:44 -0500
Date: Fri, 30 Nov 2018 18:19:41 -0600
From: Benjamin Kaduk <kaduk@mit.edu>
To: "openpgp@ietf.org" <openpgp@ietf.org>
Cc: Ronald Tse <tse@ribose.com>, "Mark D. Baushke" <mdb@juniper.net>, Derek Atkins <derek@ihtfp.com>
Message-ID: <20181201001941.GE87441@kduck.kaduk.org>
References: <87y3aosju2.fsf@wheatstone.g10code.de> <B64F4A5B-1894-4B01-9DAE-3C7A19C772BF@ribose.com> <14036.1543342928@contrail-ubm16-mdb.svec1.juniper.net> <B6F2B98A-E960-4189-A579-E29916079904@ribose.com> <875zwhvef3.fsf@wheatstone.g10code.de> <sjmmuptyszn.fsf@securerf.ihtfp.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <sjmmuptyszn.fsf@securerf.ihtfp.org>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupileLIzCtJLcpLzFFi42IR4hRV1l1ymTHG4NNSAYuVk3awW3Tduc5m 0fDvIbtF67YjbA4sHkuW/GTyWP71AYvH9aar7B5X509hC2CJ4rJJSc3JLEst0rdL4MrobZUu +CBe0XBxM0sD4zmhLkZODgkBE4lVNy6ydDFycQgJrGGS6Hh2gwnC2cgo0bHgIBuEc5dJ4uqG GUBlHBwsAqoSs+bqgXSzCahINHRfZgaxRQQ0Jfp2LGcDsZkFciUeL78DZgsL+Ejcb90IVsML tG31uiaomUuYJHr7/7BDJAQlTs58wgLRrCVx499LJpBdzALSEsv/cYCEOQUMJX6d2wJWLiqg LLG37xD7BEaBWUi6ZyHpnoXQvYCReRWjbEpulW5uYmZOcWqybnFyYl5eapGukV5uZoleakrp JkZwMEvy7mD8d9frEKMAB6MSD++EHMYYIdbEsuLK3EOMkhxMSqK8fyWAQnxJ+SmVGYnFGfFF pTmpxYcYJTiYlUR4Sy8C5XhTEiurUovyYVLSHCxK4ry/RR5HCwmkJ5akZqemFqQWwWRlODiU JHgXXgJqFCxKTU+tSMvMKUFIM3FwggznARq+DKSGt7ggMbc4Mx0if4pRl+PFjI4ZzEIsefl5 qVLivDkgRQIgRRmleXBzQElIInt/zStGcaC3hHkFQKp4gAkMbtIroCVMQEtiev5HAy0pSURI STUw7jj85cLMX4nTJXbfm6f28ElAbYjVvc23Zy/uKz7ncDR37hnBxLwTjA6paQphL+8JaZQn RrQfVK3atu7AlkuXBa1O+apJPP6rHBj0pag/qj22X+6N16I70caC6t6CverXtAza/mf25Ias +DGjoGT577utsWwvbnxb3XRv7U5XDwOG3zrXeuV+KrEUZyQaajEXFScCAJY579odAwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/XMuFVkQ_Jq-jsuJ5CmXaPQdvnoE>
Subject: Re: [openpgp] rfc4880bis and draft-openpgp-iana-registry-updates-01
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 01 Dec 2018 00:19:51 -0000

On Wed, Nov 28, 2018 at 01:09:00PM -0500, Derek Atkins wrote:
> Hi,
> 
> Werner Koch <wk@gnupg.org>; writes:
> 
> > On Wed, 28 Nov 2018 06:00, tse@ribose.com said:
> >
> >> The question raised by Werner (as I understood it) was more about how
> >> to align the IANA considerations given in 4880bis with this document,
> >> and whether to merge the said document into 4880bis. For the intended
> >
> > Right.  I am not sure what is the right procedure here.  Are the tables
> > with the various ids in rfc4880bis normative or are the informational
> > and the IANA registry is the normative reference for them.  For
> > practical point of view I would like to have the tables in rfc4880bis
> > to be normative with the note that the IANA registry defines updates to
> > these tables.

Generally you want the IANA registry to be the single normative place to
consult.  It's fairly common to have a table in an RFC and have the initial
IANA registry populated from that (also normative) table, and perhaps less
common but still plausible to have an update document with a table and
instructions for IANA to resync to that table at time of publication (but
still be able to add/change things later).

> > I agree with Ron that the procedures on how to update the IANA registries
> > do not belong into rfc4880bis.  We need some advice from IETF procedures
> > experienced people (or a pointer to an RFC describing these procedures).
> 
> Speaking for myself (but with the knowledge of being a former chair of
> the OpenPGP WG), it's perfectly fine to put the one-time IANA process
> details into the 4880bis draft.  What is often done is to add an
> RFC-Editor note to remove the IANA actions section(s) upon publication.
> 
> What happens is that the draft will get approved with all the IANA
> actions in it, but when it gets edited into an actual RFC, the one-time
> IANA actions can be removed.
> 
> There is still the historical record of the one-time actions in the i-d
> history, but it de-clutters the RFC.
> 
> I recommend we take this approach, because getting TWO I-D through the
> process will be twice as much work for everyone involved than getting
> only one through the process.  We have enough trouble with just the
> one.  So I would recommend we integrate in the one-time actions with a
> note to remove it upon publication.

Derek is absolutely right, here.

I'll note that for TLS 1.3 we did separate documents, RFCs 8446 and 8447,
since there were a *lot* of registry changes and we did want a permanent
record of them, but that split caused a lot of extra work to ensure things
were synchronized during AUTH48.

-Ben

> > Salam-Shalom,
> >
> >    Werner
> 
> -derek
> -- 
>        Derek Atkins                 617-623-3745
>        derek@ihtfp.com             www.ihtfp.com
>        Computer and Internet Security Consultant
> 
> _______________________________________________
> openpgp mailing list
> openpgp@ietf.org
> https://www.ietf.org/mailman/listinfo/openpgp