Re: [CFRG] Proposed CFRG process for handling errata

[Alexey Melnikov <[e-mail]>]

Hi Michael,

On 26/12/2020 00:59, Michael StJohns wrote:
> 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.
Colin already replied with most I had to say, but I will add one thing: 
we (CFRG chairs) are not trying to create extra process just for the 
process sake. We handled errata on ad-hoc basis in the past and we 
dropped the ball several times. We got a complain about lack of 
transparency, so the proposed process is to help address that.
>
> 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.

I was always told that IRTF RG can create own process that suites them.

Best Regards,

Alexey

>
> 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
>
>
>
> _______________________________________________
> CFRG mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg