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]>]

Mike,

> On 11 Jun 2021, at 22:00, Michael StJohns <[e-mail]> wrote:
> 
> Hi Colin - thanks for the note.
> 
> On 6/9/2021 10:15 AM, Colin Perkins wrote:
>>> On 8 Jun 2021, at 17:37, Michael StJohns <[e-mail] <mailto:[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.
> Personally, I think that's a bug, not a feature.  If something shows up at the IRTF that might conflict with the IETF, it should be pretty obvious at the beginning and ideally moved over to the IETF by the RG chair or the IRTF chair at that point rather than waiting to the point of publication.  More below.
> 
I believe it’s sensible that the IESG has procedures in place to catch any conflicts that might be missed by the other publication streams.
>>> 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.
> Just to satisfy my curiosity:  Did the topic of Anti-Trust with respect to standards come up in that discussion? 
> 
No.
>   For my own edification, I asked Jay Daley whether or not the IETF insurance policies related to this covered the IRTF and whether there were any terms and conditions that needed to be followed to retain coverage?   I haven't gotten an answer to that question yet, but it was a topic he will probably bring up with the underwriters when they review coverage.
> 
> Some of the byzantine structure of the IETF processes are related to providing a structure of institutionalized protections related to avoiding anti-trust violations in the standardization process.  Those include the IPR disclosure requirements, open participation requirements and things like the appeal process - none of which necessarily or consistently apply to the IRTF.  Even IETF stream Informational documents go through that process making the question of whether or not they are standards in truth less fraught if we get it wrong.
> 
As I’m sure you’re aware, the IRTF has IPR disclosure requirements in place. While RFC 2014 allows for IRTF research groups with closed membership, all the current research groups have open membership (and that has been the case for many years now). Decisions made by the IRTF Chair can be appealed to the IAB, and concerns about research group operations may be raised with the IRTF Chair.
>>> 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. 
> Unfortunately, they sometimes evolve in directions that weren't expected, nor were actually best for the community.  See below.  In any event, your current charter and guidelines were set back in 1996 (RFC2014) and haven't yet been revised even though Lars submitted a draft to do so a few years back.
> 
>> The IRTF is a composed of a number of focused, long-term, small
>>    Research Groups.  These groups work on topics related to Internet
>>    protocols, applications, architecture and technology. Research Groups
>>    are expected to have the stable long term membership needed to
>>    promote the development of research collaboration and teamwork in
>>    exploring research issues.  Participation is by individual
>>    contributors, rather than by representatives of organizations.
> Note the "focused" and "small" adjectives.  It might be useful to review sections 1 and 1.1 of RFC 2014 and figure out if the IRTF is still following the spirit of that guidance.  There's also the "stable long term membership" which implies an enumeratable group of core members actively involved on a long term basis (e.g., not just a member of the mailing list...) .  There are multiple statements throughout 2014 that refer to a core active membership.
> 
I’m familiar with RFC 2014. It’s not clear what point you are trying to make here.
>>> 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.
> Thanks for pointing out this document. The datatracker history is pretty much an indictment of the IRTF publication process.   As I read this document (both reading and reading the diffs), Dave submitted it for publication April 2020 (the -04 draft), and - my opinion - that document was probably 95%+ ready for publication at that time.   There were a number of minor but substantive revisions made after the designated IRTF reviewer reviewed the document.  Had it not taken 2.5 months to assign a reviewer, the document would have been pretty much ready for publication as a thought piece (its intended role) no later than mid to late May 2020.  The IRSG then tacked on a second review, a conflict review, two votes (IESG and IRSG) including a large number of delays (about 4-5 months total including that 2.5 months mentioned prior) where the datatracker shows it in a state waiting for you to       dispatch.  There was some small amount of explanatory material added after the IRSG review - but IMO didn't add anything substantive to the document or for later readers.
> 
> I was surprised by Mirja's comment that this document was more appropriate for the ISE - that suggests there may be a misunderstanding of the IRTF model - either on her part or on mine.  As I understand the document, it was well within the research area of the ICNRG and 6.2 of RFC2014 applies.
> 

If an IRSG member has a question about the suitability of a document for publication on the IRTF stream, then they should raise it for discussion. Mirja did this, the IRSG discussed the issue and agreed publication on the IRTF stream was appropriate.
> It finally got to the RFC editor in late June this year.     
> 
> I'm not a member of ICNRG, so maybe this is just the way they like things... but Dave's document could have been useful as an RFC as early as June or July last year.  I see a pretty bad balance of time delay/benefit here.
> 
As you note, you’re not a participant in ICNRG and hence are not familiar with all the discussion and context around this draft. 

I also remind you that there's an ongoing pandemic that's caused significant delay and disruption for many activities over the past year or so.
>>> 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.
> That mostly doesn't hold water.  If the experimental protocols are so wide spread  that the IRTF documents no longer are sufficient to document the research, and/or there are non-IRTF members implementing them - it's a standard or well on its way to becoming one.   One answer is to draw a bright line at the registry or even at something that looks like a usable implementation and transfer the work to the IETF at that point.   I do note there are cases where you're just adding stuff to existing registries (the "ham" URI for example) and that will be useful to prevent collisions.
> 
> The registries are a symptom, not necessarily the problem.
> 
The Internet research community has long made use of research testbeds and deployment experiments, sometimes at large scale, to validate ideas. As part of this, the community sometimes needs experimental protocols and parameter registries to be documented to help coordination between researchers. It's appropriate that IRTF supports such research.

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