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

[Michael StJohns <[e-mail]>]

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.


>> 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?   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.

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

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

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.

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

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

Sure, but it's a pointless discussion unless the result reaches over to 
the right set of people.  E.g. SAAG is probably the right set for this 
discussion not CFRG.  That would have been a good point for chair of the 
CFRG or you to make that suggestion.

Later, Mike



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