Re: [CFRG] CFRG does standards and that is a general problem. Was Re: OCB does not have an OID specified, that is a general problem

[Colin Perkins <[e-mail]>]

> On 8 Jun 2021, at 17:37, Michael StJohns <[e-mail]> wrote:
> On 6/7/2021 9:53 AM, Roman Danyliw wrote:
>> I would like to propose that in future assignment of relevant OIDs and             JOSE identifiers be considered a requirement for similar work. If a spec for a symmetric mode isn't sufficiently specified to enable interoperable implementation in CMS and JOSE, it is not sufficiently specified to be an RFC.
>> That’s a reasonable thing to ask for, and something that could be caught by SECDIR or AD review.
>> 
>> [Roman] Agreed in the general case for the IETF stream.  For RFC7253, this review would have been during IESG conflict review because that document was IRTF stream (which doesn’t have an SECDIR review, AD review or even an IESG ballot).
>> 
IRTF stream drafts do get IRSG review before publication, but equally one of the reasons we have IESG conflict review is to catch this sort of thing if it's missed.
> This seems to be yet another reason why the CFRG should be a WG and not an RG. 
> 
You’ve repeatedly raised this point. The IRSG considered it, and the CFRG chairs and IAB discussed it in the last IAB review of CFRG. Each time, we concluded that the CFRG is best placed be able to bridge the cryptographic research community and the IETF as an IRTF RG.
> I know this is not a popular opinion, but I think by keeping the CFRG in the IRTF, we're actually hurting the IRTF.   In the deep murky history of the IRTF, the organization was originally (post Kobe) meant to be a place for exploration of a lot of different points of view.  The concept of a RG "adopting a draft" was pretty much anathema - the idea was for lots of competing ideas to make it through the publication filters after some peer review and thence on to the broader community for consideration within the protocol development community.
> 
Kobe was a long time ago. Organisations and processes evolve. 
> It was not to come to a "consensus" on the one true way.  It should be possible to go into a RG with an idea that meets the general theme and is at least plausible, without having to "win" a race of competing proposals, and come out of it with an RFC in much less than 2 years - even as an individual contributor.  I'm not sure that's still possible.
> 
I note that draft-oran-icnrg-qosarch-06 is currently in the RFC Editor queue as a non-consensus document on the IRTF stream. The initial draft was submitted in August 2019. CFRG works in a particular way. Other RGs can, and do, work in different ways.
> At this point, the IRTF is looking more and more like a more closed version of the IETF with many procedures mostly indistinguishable from the IETF.  A number of RGs even have IANA actions for their documents and that suggests standards creation is bleeding into the IRTF in a way that will diminish the worth of the IRTF as a place for ideas rather than finished designs.
> 
One of the roles of IRTF is to publish experimental protocols, to document ideas that are being prototyped to see if they’re usable at Internet scale, and to help the research community conduct deployment experiments. Sometimes those experimental protocols need parameter registries, so other experiments can build on top of them without conflicts. This can be abused, like everything, but I don’t see the concept of IANA registries in IRTF RFCs as inherently problematic.
> In the instant discussion, OID assignment should be done using IETF procedures.  And discussions on changes to IETF procedures are (or should be?) probably out of scope for an RG.  

Changes to the IETF procedures can only be made by the IETF, certainly, but the participants an IRTF RG can discuss whether they think those procedures ought to change, and whether they want to propose such a change to IETF, same as participants in any other venue can have such a discussion. 

-- 
Colin Perkins
https://csperkins.org/