[rfc-i] "AUTH48" after format change
tony at att.com (HANSEN, TONY L) Wed, 17 February 2016 19:57 UTC
From: tony at att.com (HANSEN, TONY L)
Date: Wed, 17 Feb 2016 19:57:55 +0000
Subject: [rfc-i] "AUTH48" after format change
In-Reply-To: <56C4B2C0.8050408@rfc-editor.org>
References: <DM2PR02MB1322664EFEC93754524365A3C3AE0@DM2PR02MB1322.namprd02.prod.outlook.com>
<56C4B2C0.8050408@rfc-editor.org>
Message-ID: <27BA96BC-8564-4D03-921C-079BC1D2098C@att.com>
The "48" has always been an optimistic misnomer anyway. Perhaps we should go with "AUTH72"? Only half joking. Tony On 2/17/16, 12:49 PM, "rfc-interest on behalf of Heather Flanagan (RFC Series Editor)" <rfc-interest-bounces at rfc-editor.org on behalf of rse at rfc-editor.org> wrote: >Hello Larry, > >On 2/17/16 8:46 AM, Larry Masinter wrote: >> My apologies if this has been addressed. >> >> >> I wonder if the 'AUTH48' part of the RFC publication process and >> procedures will need changing because of the much larger set of things >> that need to be checked. > >This is something I've brought up with the IESG as the new features have >implications in the last call and stream manager (i.e., IESG, ISE, IAB, >IRSG) review process. If you haven't seen this message from Jari and the >IESG, it is useful context for the procedures question: > >https://mailarchive.ietf.org/arch/search/?email_list=ietf-announce&gbt=1&qdr=m > >> >> As it is, when doin complex layout for HTML and PDF opens the >> possibility of tooling errors or more clerical errors. > >If an error is introduced that is purely a tooling error that >incorrectly renders something from the XML, then we can re-render the >document when the bug is fixed. If an error is introduced because of a >problem with the XML itself, or if an error is introduced as part of the >editing process (which includes the clerical errors you mention) then an >errata needs to be filed. A -bis document is also a possible solution. > >-Heather > >> >> I could see >> >> >> a) changing Last Call notices to call out the expectation to review >> formatted editions as well >> >> b) extending the time >> >> c) extending the scope of final-final reviewers >> >> d) RFC editor assigning more review resources >> >> e) changing the rule that doesn't allow corrections (to the non-XML >> outputs) after publication. >> > >> >> By "tooling" "clerical errors" I mean >> >> Of the RFCs I've worked on, there have been tooling errors >> >> >> (RFC 2616 Errata ID: 1619, where for some reason Word-to-text dropped >> the first character of each line) >> >> >> and another case where a new RFC was issued because the date was the >> wrong year >> >> >> and clerical errors, for example RFC 4395 was listed as BCP 115 instead >> of BCP 35 >> >> >> Larry >>
- [rfc-i] "AUTH48" after format change Larry Masinter
- [rfc-i] "AUTH48" after format change Heather Flanagan RFC Series Editor
- [rfc-i] "AUTH48" after format change HANSEN, TONY L
- [rfc-i] "AUTH48" after format change draft-iab-rf… Larry Masinter
- [rfc-i] "AUTH48" after format change draft-iab-rf… Heather Flanagan RFC Series Editor