Re: The IETF, Standards process, and the impact on the RFC series document production
John C Klensin <john@jck.com> Fri, 04 October 2019 16:52 UTC
Return-Path: <john@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 DA73B120103 for <ietf@ietfa.amsl.com>; Fri, 4 Oct 2019 09:52:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 gdZFMsI6WWvu for <ietf@ietfa.amsl.com>; Fri, 4 Oct 2019 09:52:11 -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 42F9C120114 for <ietf@ietf.org>; Fri, 4 Oct 2019 09:52:11 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john@jck.com>) id 1iGQoM-000JV8-0L; Fri, 04 Oct 2019 12:52:10 -0400
Date: Fri, 04 Oct 2019 12:52:04 -0400
From: John C Klensin <john@jck.com>
To: Michael StJohns <mstjohns@comcast.net>
cc: ietf@ietf.org
Subject: Re: The IETF, Standards process, and the impact on the RFC series document production
Message-ID: <129409C7570FA140156D110C@PSB>
In-Reply-To: <87a3e050-6e94-fcb0-70b8-cb907a029a0f@comcast.net>
References: <394203C8F4EF044AA616736F@PSB> <4097464f-d038-2439-5ca5-70bac46b25ea@huitema.net> <69DAA6BBBE243BAD98926154@PSB> <371c3b14-8bfc-a476-3ff9-7268485bad12@huitema.net> <87a3e050-6e94-fcb0-70b8-cb907a029a0f@comcast.net>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/UZPYYqwy7H8JUiO3qxJKUKwDTes>
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: Fri, 04 Oct 2019 16:52:14 -0000
Mike, Strongly +1. We are attributing too many things to the RFC Editor Function that are really issues with the standards process. Two small additional comments: (1) You wrote "not (only?) the actual document production that takes time, but the authoring, and then getting through WG, then various twiddles by the IESG, and then finally IETF last call, all before it ever gets to the RFC editor for publication.". But it isn't "finally IETF Last Call" because there is another round of IESG twiddling. In my recent experience, that takes a minimum of three weeks just to get a document scheduled for a call. Then IESG members make comments and vote, typically within 24 hours of the call time. If any of those is a DISCUSS or contains comments of significance, there are further delays, with a month or more after the Last Call closes not being unusual. As you point out, the RFC Production Center gets the document only after that. My experience has been that, For a well-written and reasonably short document that doesn't have "cluster" entanglements with others, the time they take is usually trivial relative to everything else. (2) While I agree that there are document marking issues with other SDOs that are not hugely different from ours, their specific review cycles tend to keep them out of the problems we get into by a collection of extensions, amendment documents that don't quite replace the originals, replacements that don't address all outstanding issues, and so on. While not technical standards, the IASA2 work has illustrated many of those problems: ANSI, IEEE, and ISO procedures would make it nearly impossible to publish a new document that said "this revision does not address the following problems that are believed or known to be significant". While not a perfect solution, the work of the NEWTRK WG tried to address some of the issues associated with our collections of related documents but was never formally considered outside the WG because the IESG refused to issue a Last Call, so we are not making much progress in that area. best, john --On Friday, October 4, 2019 12:11 -0400 Michael StJohns <mstjohns@comcast.net> wrote: > Hi Christian - I thought I'd dive down into some of your > specific comments on the standardization process. Subject > changed appropriately. > > On 10/4/2019 3:51 AM, Christian Huitema wrote: >> >> At the same time, there is a tension between the tradition >> and the need to serve and recruit a wider community. Our >> document production time is counted in years, and that does >> not help convincing open source projects to work with us. > > To be clear, it's not (only?) the actual document production > that takes time, but the authoring, and then getting through > WG, then various twiddles by the IESG, and then finally IETF > last call, all before it ever gets to the RFC editor for > publication. > > A while back I managed to move RFC5011 from Proposed to > Standard without a document action. From Last Call to the > announcement of the standards action was about 6 months. > Let me repeat that - 6 months. And there were no RFC editor > actions AFAICT. I think it was most of a year from the > time I requested the upgrade until it was done. > > WRT to Open Source projects: I keep running afoul of these > in that the code tends to be where the standard is documented. > That's not what we do here. I do understand we need to > work with this community, but we also need to avoid being > captured by any one community. We also need to have people > willing to do the hard part of writing the documents and > shepherding them through the system. > > >> Our documents are cast for eternity, errors included, >> which does not help the part the part of the readership who >> wants to implement standards. > > Generically, erratas cover non-interoperable errors (and the > occasional error of a constant or a value). It's pretty rare > that not implementing an errata will break something > AFAICT. Or do you have a few counter examples with > implementation experience? > > >> Implementing our standards involves a treasure hunt >> to find how many RFC have to be read before understanding the >> whole picture. > This is problematic, but inherent, not so much in the RFC > series, but in the way we've chosen to do our standards > process. We extend, we rarely amend, and we run into > problems when we amend. DNS being the most egregious example > of this (amend -> DNSSEC, extend -> more RFCs than I care to > think about) that I can think of with possibly TLS a close > second. I think that's more of a standards discussion than > an RFC series discussion. Also, it is possible (and has been > done) to write a "here's what you need to do to implement" > RFC. Perhaps we (the IETF - at some cost) might think of > paying someone to do that for a few of the more extensive > cases? >> And that's before we even consider the potential of >> confusion between standards, experiments, independent >> efforts, and drafts. > > I rarely have a problem differentiating between the relative > values and quality of each of these, although I'm getting a > little concerned with the Informational RFCs coming out of the > CFRG that are actually cryptographic standards of first > publication. Each and every RFC (or at least in the last > 10-15 years or so) has the disclaimer to "go check XXX to find > out what the status of this document is and what > 'informational' or 'experimental' actually means". > > Note that this is NOT specific to the IETF. Every time I > delve into the worlds of ANSI, IEEE or ISO standards I have to > refresh my memory on their various varieties of document > markings. > >> The >> IETF community will need to solve that over time. I assume >> that this will imply some sharing of the work between the RFC >> Editor and the "superstructure" of the IETF, and I wait to >> see the discussion happening in the ad hoc working group. And >> yes, of course the discussion process should be open and fair. > > Nothing I've seen above really has an impact on the RFC editor > as an separate institution. Perhaps I'm misreading this, but > perhaps what you're implying is that more attention to > cleaning up (and speeding up) the standards process > pre-submission-to-the RFC Editor is warranted? What do you > see as the RFC Series Editor's role in that? > > Later, Mike
- New proposal/New SOW comment period Sarah Banks
- Re: New proposal/New SOW comment period Michael StJohns
- Re: New proposal/New SOW comment period Stephen Farrell
- Re: New proposal/New SOW comment period Sarah Banks
- Re: New proposal/New SOW comment period Matthew A. Miller
- Re: New proposal/New SOW comment period Eliot Lear
- RE: [rfc-i] New proposal/New SOW comment period Adrian Farrel
- Re: New proposal/New SOW comment period S Moonesamy
- Sergeant-at-Armss and New proposal/New SOW commen… John C Klensin
- Re: Sergeant-at-Armss and New proposal/New SOW co… Bob Hinden
- Re: Sergeant-at-Armss and New proposal/New SOW co… Keith Moore
- Re: Sergeant-at-Armss and New proposal/New SOW co… Adam Roach
- Re: Sergeant-at-Armss and New proposal/New SOW co… Keith Moore
- Re: Sergeant-at-Armss and New proposal/New SOW co… Adam Roach
- Re: Sergeant-at-Armss and New proposal/New SOW co… Bob Hinden
- Re: Sergeant-at-Armss and New proposal/New SOW co… Adam Roach
- Re: Sergeant-at-Armss and New proposal/New SOW co… Michael StJohns
- Re: Sergeant-at-Armss and New proposal/New SOW co… Keith Moore
- Re: Sergeant-at-Armss and New proposal/New SOW co… Michael
- Re: Sergeant-at-Armss and New proposal/New SOW co… Adam Roach
- Re: Sergeant-at-Armss and New proposal/New SOW co… Michael
- Re: Sergeant-at-Armss and New proposal/New SOW co… Masataka Ohta
- Re: Sergeant-at-Armss and New proposal/New SOW co… Keith Moore
- Re: Sergeant-at-Armss and New proposal/New SOW co… Benjamin Kaduk
- Re: Sergeant-at-Armss and New proposal/New SOW co… Eric Rescorla
- Re: Sergeant-at-Armss and New proposal/New SOW co… Randy Bush
- Re: Sergeant-at-Armss and New proposal/New SOW co… Benjamin Kaduk
- Re: Sergeant-at-Armss and New proposal/New SOW co… John C Klensin
- Re: Sergeant-at-Armss and New proposal/New SOW co… Keith Moore
- Re: Sergeant-at-Armss and New proposal/New SOW co… Eric Rescorla
- Re: Sergeant-at-Armss and New proposal/New SOW co… Randy Bush
- Re: Sergeant-at-Armss and New proposal/New SOW co… Eric Rescorla
- Re: Sergeant-at-Armss and New proposal/New SOW co… Randy Bush
- Re: Sergeant-at-Armss and New proposal/New SOW co… Keith Moore
- Re: Sergeant-at-Armss and New proposal/New SOW co… Eric Rescorla
- Re: Sergeant-at-Armss and New proposal/New SOW co… Melinda Shore
- Re: [rfc-i] New proposal/New SOW comment period Eliot Lear
- Re: Sergeant-at-Armss and New proposal/New SOW co… Masataka Ohta
- Re: Sergeant-at-Armss and New proposal/New SOW co… Masataka Ohta
- Re: Sergeant-at-Armss and New proposal/New SOW co… Leif Johansson
- Re: Sergeant-at-Armss and New proposal/New SOW co… Masataka Ohta
- Re: [rfc-i] New proposal/New SOW comment period S Moonesamy
- Re: Sergeant-at-Armss and New proposal/New SOW co… Bob Hinden
- Re: New proposal/New SOW comment period Michael StJohns
- Re: [rfc-i] New proposal/New SOW comment period Michael StJohns
- SAA Do's and Don'ts Michael StJohns
- Re: SAA Do's and Don'ts Keith Moore
- Re: SAA Do's and Don'ts Melinda Shore
- tone policing (was: SAA Do's and Don'ts) Keith Moore
- Re: Sergeant-at-Armss and New proposal/New SOW co… Theodore Y. Ts'o
- Re: [rfc-i] New proposal/New SOW comment period Adam Roach
- Re: SAA Do's and Don'ts John C Klensin
- Re: SAA Do's and Don'ts Masataka Ohta
- Re: tone policing (was: SAA Do's and Don'ts) Mark Nottingham
- Re: tone policing Keith Moore
- Re: tone policing Mark Nottingham
- Re: SAA Do's and Don'ts Keith Moore
- Re: tone policing Keith Moore
- Re: tone policing Masataka Ohta
- Re: tone policing Mark Nottingham
- Re: tone policing Keith Moore
- Re: tone policing Mark Nottingham
- Re: tone policing Rob Sayre
- Re: tone policing Stephen Farrell
- Re: tone policing Keith Moore
- Re: tone policing Melinda Shore
- Re: tone policing Masataka Ohta
- Re: tone policing Masataka Ohta
- Re: tone policing Keith Moore
- Re: tone policing Adam Roach
- Re: tone policing Keith Moore
- Re: tone policing Ted Lemon
- Re: tone policing Keith Moore
- Re: [rfc-i] New proposal/New SOW comment period Michael StJohns
- Re: tone policing lloyd.wood@yahoo.co.uk
- Re: tone policing Rob Sayre
- Re: [rfc-i] New proposal/New SOW comment period Adam Roach
- Re: tone policing Adam Roach
- Re: tone policing Masataka Ohta
- Re: tone policing Dan Harkins
- Re: tone policing Rob Sayre
- Re: tone policing Ted Lemon
- Re: tone policing Keith Moore
- Re: tone policing Ted Lemon
- Re: tone policing Keith Moore
- Re: tone policing Christer Holmberg
- Re: tone policing Ted Lemon
- Re: tone policing Paul Wouters
- Re: tone policing Keith Moore
- Re: tone policing Nick Hilliard
- Re: tone policing Keith Moore
- Re: tone policing Nick Hilliard
- Re: tone policing Ted Lemon
- Re: tone policing Dirk-Willem van Gulik
- Re: tone policing Ted Lemon
- Re: tone policing Dan Harkins
- Re: tone policing Adam Roach
- Re: tone policing Keith Moore
- Re: tone policing ned+ietf
- Re: tone policing Dan Harkins
- Re: tone policing Randy Bush
- Re: tone policing Theodore Y. Ts'o
- Re: Sergeant-at-Armss and New proposal/New SOW co… Spencer Dawkins at IETF
- Re: tone policing Masataka Ohta
- Re: tone policing Patrik Fältström
- Re: [rfc-i] New proposal/New SOW comment period Sarah Banks
- Re: [rfc-i] New proposal/New SOW comment period Sarah Banks
- Re: [rfc-i] New proposal/New SOW comment period Sarah Banks
- RE: [rfc-i] New proposal/New SOW comment period Adrian Farrel
- Re: tone policing lloyd.wood
- Re: [rfc-i] New proposal/New SOW comment period Michael StJohns
- Re: [rfc-i] New proposal/New SOW comment period Michael StJohns
- Re: [rfc-i] New proposal/New SOW comment period Sarah Banks
- Re: [rfc-i] New proposal/New SOW comment period Spencer Dawkins at IETF
- Re: tone policing Salz, Rich
- Re: tone policing Keith Moore
- Re: tone policing Ted Lemon
- Re: tone policing Keith Moore
- Re: tone policing Ted Lemon
- Re: tone policing Viktor Dukhovni
- Re: tone policing Keith Moore
- Re: tone policing Ted Lemon
- Re: tone policing Keith Moore
- Re: tone policing Paul Wouters
- Re: tone policing Salz, Rich
- Re: tone policing Doug Royer
- Re: tone policing Keith Moore
- Re: tone policing Dan Harkins
- Re: tone policing Joel M. Halpern
- Re: tone policing Salz, Rich
- Re: tone policing Salz, Rich
- Re: tone policing Bron Gondwana
- Re: tone policing Dan Harkins
- Re: tone policing Stephen Farrell
- Re: tone policing Brian E Carpenter
- Re: tone policing Dan Harkins
- Re: tone policing Bron Gondwana
- Re: tone policing Masataka Ohta
- Re: tone policing Dan Harkins
- Re: tone policing Ted Lemon
- Re: tone policing Randy Bush
- Re: tone policing Leif Johansson
- Agenda Denial Was: tone policing Phillip Hallam-Baker
- Re: Agenda Denial Was: tone policing Ted Lemon
- Re: Agenda Denial Was: tone policing Paul Wouters
- BIMI: Re: tone policing Phillip Hallam-Baker
- Re: Agenda Denial Was: tone policing Keith Moore
- Re: Agenda Denial Was: tone policing Keith Moore
- Re: Agenda Denial Was: tone policing Ted Lemon
- Re: tone policing Keith Moore
- Re: Agenda Denial Was: tone policing Keith Moore
- Re: Agenda Denial Was: tone policing Stan Kalisch
- Re: Agenda Denial Was: tone policing Dan Harkins
- Re: Agenda Denial Was: tone policing Nico Williams
- Re: Agenda Denial Was: tone policing Phillip Hallam-Baker
- Re: Agenda Denial Was: tone policing Phillip Hallam-Baker
- Re: Agenda Denial Was: tone policing Keith Moore
- Re: tone policing Bron Gondwana
- Re: New proposal/New SOW comment period John C Klensin
- Re: New proposal/New SOW comment period Michael Richardson
- Re: New proposal/New SOW comment period John C Klensin
- Re: New proposal/New SOW comment period Sarah Banks
- Re: New proposal/New SOW comment period Sarah Banks
- Re: [rfc-i] New proposal/New SOW comment period Ted Lemon
- Re: [IAB] New proposal/New SOW comment period Christian Huitema
- Re: [rfc-i] New proposal/New SOW comment period Sarah Banks
- Re: [rfc-i] New proposal/New SOW comment period Ted Lemon
- Re: [rfc-i] New proposal/New SOW comment period Brian E Carpenter
- Re: [rfc-i] New proposal/New SOW comment period Henrik Levkowetz
- Re: [rfc-i] New proposal/New SOW comment period Leif Johansson
- Re: New proposal/New SOW comment period John C Klensin
- Re: New proposal/New SOW comment period (off-topi… S Moonesamy
- Re: New proposal/New SOW comment period Sarah Banks
- Re: [IAB] New proposal/New SOW comment period John C Klensin
- Re: [IAB] New proposal/New SOW comment period Stephen Farrell
- Re: [rfc-i] [IAB] New proposal/New SOW comment pe… Brian E Carpenter
- "community" for the RFC series (was: Re: [rfc-i] … Stephen Farrell
- Re: "community" for the RFC series Brian E Carpenter
- Re: "community" for the RFC series (was: Re: [rfc… John C Klensin
- Re: [IAB] New proposal/New SOW comment period Christian Huitema
- Re: "community" for the RFC series Stephen Farrell
- The IETF, Standards process, and the impact on th… Michael StJohns
- Re: The IETF, Standards process, and the impact o… Nico Williams
- Re: The IETF, Standards process, and the impact o… John C Klensin
- Re: The IETF, Standards process, and the impact o… John C Klensin
- Re: The IETF, Standards process, and the impact o… John C Klensin
- Re: The IETF, Standards process, and the impact o… Nico Williams
- Re: The IETF, Standards process, and the impact o… Michael StJohns
- Re: "community" for the RFC series Christian Huitema
- Re: The IETF, Standards process, and the impact o… Nico Williams
- Re: The IETF, Standards process, and the impact o… Keith Moore
- Re: The IETF, Standards process, and the impact o… John C Klensin
- Re: The IETF, Standards process, and the impact o… Nico Williams
- Re: "community" for the RFC series Leif Johansson
- Re: "community" for the RFC series Stephen Farrell
- Re: "community" for the RFC series Randy Bush
- Re: "community" for the RFC series Brian E Carpenter
- Re: The IETF, Standards process, and the impact o… Brian E Carpenter
- Re: The IETF, Standards process, and the impact o… Keith Moore
- Re: [rfc-i] "community" for the RFC series Henrik Levkowetz
- Re: "community" for the RFC series John C Klensin
- Re: "community" for the RFC series Stephen Farrell
- Re: The IETF, Standards process, and the impact o… Randy Presuhn
- Re: The IETF, Standards process, and the impact o… Christian Huitema
- Re: "community" for the RFC series S Moonesamy
- Re: "community" for the RFC series Brian E Carpenter
- Re: "community" for the RFC series Michael StJohns
- Re: "community" for the RFC series Stephen Farrell
- Re: "community" for the RFC series Stephen Farrell
- Re: "community" for the RFC series Brian E Carpenter
- Re: The IETF, Standards process, and the impact o… Michael Richardson
- Re: "community" for the RFC series Christian Huitema
- Re: "community" for the RFC series Christian Huitema
- Re: "community" for the RFC series Brian E Carpenter
- Re: "community" for the RFC series Stephen Farrell
- Re: "community" for the RFC series Keith Moore
- Re: "community" for the RFC series Christian Huitema
- Re: "community" for the RFC series Stephen Farrell
- Re: [IAB] "community" for the RFC series Colin Perkins
- Re: "community" for the RFC series Brian E Carpenter
- Re: "community" for the RFC series Keith Moore
- Re: "community" for the RFC series Brian E Carpenter