[rfc-i] "AUTH48" after format change draft-iab-rfc-framework-04.txt

Larry Masinter masinter at adobe.com
Wed Feb 17 12:15:51 PST 2016


To be more explicit, I suggest a discussion of the procedural issues and requirements be added to section 10 Transition Plan of draft-iab-rfc-framework, so they can be reviewed as well.



________________________________________
From: HANSEN, TONY L <tony at att.com>
Sent: Wednesday, February 17, 2016 11:57 AM
To: Heather Flanagan (RFC Series Editor); Larry Masinter; rfc-interest at rfc-editor.org; iab at iab.org
Subject: Re: [rfc-i] "AUTH48" after format change

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


More information about the rfc-interest mailing list