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

Heather Flanagan (RFC Series Editor) rse at rfc-editor.org
Sun Mar 6 15:06:25 PST 2016


Hello Larry,

I don't think I explicitly responded to this. I don't think defining the
draft review process or AUTH48 belongs in the framework draft, though I
agree it is a conversation worth having (and already started) with the
stream approving bodies and the community.

I propose to add the following to section 10. Will this resolve your
concern in the context of this draft?

---
NEW:
Any modifications to the draft review process, up to and including
AUTH48, will happen with the community and the stream approving bodies
as we learn more about the features and outputs of the new publication
tools. Defining those processes is out of scope for this document.
---

-Heather

On 2/17/16 12:15 PM, Larry Masinter wrote:
> 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
>>>
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
> 



More information about the rfc-interest mailing list