Re: [CFRG] Proposed CFRG process for handling errata

[Michael StJohns <[e-mail]>]

Hi Alexey -

 From a general philosophy, this seems to conflict with the general 
guidance for RGs - specifically (RFC 2014 "IRTF Research Group 
Guidelines and Procedures" - section 1.1 ):

>   Even more than the IETF, the work of the IRSG is expected to be
>     marked by informality.  The goal is to encourage and foster valuable
>     research,*_not to add burdensome bureaucracy to the endeavo_*r.

I brought up a while back that the CFRG has taken on more of the 
characteristics of a WG than an RG and it may be appropriate to 
recharter the group under the IETF as a WG or even co-charter it as both 
an RG and WG.  Let me make that point again.

Also in section 1.1:
>   The IRTF does not set standards, and thus has somewhat different and
>     complementary philosophy and procedures.  In particular, an IRTF
>     Research Group is expected to be long-lived, producing a sequence of
>    "products" over time._*The products of a Research Group are research results*_  that may be disseminated by publication in scholarly journals
>     and conferences, as white papers for the community, as Informational
>     RFCs, and so on.  In addition, i_*t is expected that technologies developed in a Research Group will 
> be brought to the IETF as input to IETF Working Group(s) for possible 
> standardization.*_    However,
>     Research Group input carries no more weight than other community
>     input, and goes through the same standards setting process as any
>     other proposal.

Errata is appropriate for standards - less so for research papers.

Or to put it more succinctly - I object to the addition of more process 
to the RG.  I further suggest that if this isn't apropriate as  IRTF 
wide process, then it's probably not within the remit of the CFRG to 
create its own processes - no more than it would for a WG.

Later, Mike

ps - feel free to propose amendments to RFC2014, but at AFAICT that 
document  is the one that describes the current general contract for RGs.


On 12/24/2020 5:25 AM, Alexey Melnikov wrote:
> Dear CFRG participants,
>
> Below is the proposed process that CFRG chairs would follow when 
> handling errata submitted on CFRG documents.
>
> Please let chairs know by January 16th if you have comments or 
> concerns. Statements of support for this proposal are also welcome.
> ------------
>
> An erratum is submitted through www.rfc-editor.org website An erratum 
> on a CFRG document results in email to [e-mail] (+authors/editors 
> of the RFC) with subject like "[Technical Errata Reported] RFCXXXX 
> (YYYY)", where XXXX is the relevant RFC number and YYYY is the 
> corresponding erratum number (assigned automatically by RFC Editor's 
> website).
>
> Note that the current errata system is not designed for reporting of 
> extensions and things that were not known or intended at the time the 
> document was written. It is only designed for reporting problems/bugs 
> in documents.
>
>
> One of CFRG chairs becomes the response CFRG chair for the erratum. 
> He/she verifies that the erratum designation (Technical versa 
> Editorial) is correct. (Note that the designation can be changed later 
> and it is Ok if initially it is unclear for some errata which one it 
> is.) The CFRG chair can also request deletion of obviously bogus 
> erratum, such as submitted by spammers.
>
> The CFRG chair then can optionally request review from the Crypto 
> Review Panel 
> <https://trac.ietf.org/trac/irtf/wiki/Crypto%20Review%20Panel>, by 
> emailing [e-mail] and asking for comments on how to 
> resolve the erratum. A proposed resolution can be suggested, if 
> available. The request should specify a deadline, typically 2 weeks. 
> This deadline can be extended by request from Crypto Review Panel 
> members. Note that feedback from Crypto Review Panel is advisory in 
> nature.
>
> The CFRG chair then emails the CFRG mailing list <[e-mail]> 
> asking for comments on how to resolve the erratum. (Possible subject 
> to use: "Proposed resolution for erratum YYYY on RFC XXXX") A proposed 
> resolution can be suggested, if available. The proposed resolution 
> takes into consideration feedback received from the Crypto Review 
> Panel (if requested). The request should specify a recommended 
> deadline for discussions.
>
> The CFRG chair follows the CFRG mailing list discussion of the erratum 
> resolution and posts a summary email after the deadline expires. If 
> there is a clear resolution ("accept", "reject" or "hold for document 
> update") the suggested resolution (and possible changes to the erratum 
> text) are included in the summary email. The IRTF Chair should be 
> notified about the proposed resolution for the erratum.
>
> The IRTF Chair verifies outcome of the process and either acts on the 
> erratum as proposed by the CFRG chair or delegates this decision to 
> another person (who might be the CFRG chair). (The IRTF chair can 
> provide technical feedback on the erratum in his/her personal 
> capacity. The IRTF Chair can also restart discussion of the erratum on 
> the CFRG mailing list.)
>
> ------------
>
> Best Regards,
>
> Alexey, for the CFRG chairs
>
> _______________________________________________
> CFRG mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg