[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
>>