Re: [CFRG] Proposed CFRG process for handling errata

[[e-mail]]

Hi Mike,

On Sunday, 27 December 2020, Michael StJohns wrote:
> Hi Russ -
> 
> We ought to stop promoting the fiction that the CFRG isn't doing 
> standards and move the CWG part over to the IETF where it belongs.  I 
> don't actually have a problem with the errata by itself, but I do when 
> you add it to calls for adoption, group consensus, last calls and the 
> whole set of things more appropriate for the standards process than what 
> the IRTF was intended to be.
>

I disagree. We have what seems to me to be a setup that's worked these past years with technologists and academic cryptographers collaborating  and I see no reason to risk that success for possible process purity.

Cheers, 
S. 
 
> Mike
> 
> 
> On 12/27/2020 2:50 PM, Russ Housley wrote:
> > As you say, the CFRG is not like many other RGs.  Crypto algorithm 
> > specifications, while informational, ofter become normative references 
> > in standards.  For this reason, I think robust handling of errata is 
> > desirable.
> >
> > Russ
> >
> >> On Dec 25, 2020, at 7:59 PM, Michael StJohns <[e-mail] 
> >> <mailto:[e-mail]>> 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.
> >>
> >> 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
> >>
> >>
> >> _______________________________________________
> >> CFRG mailing list
> >> [e-mail] <mailto:[e-mail]>
> >> https://www.irtf.org/mailman/listinfo/cfrg
> >
> 
>