Re: Observations on (non-technical) changes affecting IETF operations

["Eggert, Lars" <[e-mail]>]

Hi,

On 2016-03-23, at 10:08, [e-mail] wrote:
> rfc2014:
>  The IRTF does not set standards
> 
> rfc4440:
>  This is necessary to ensure that RGs don't become a part of
>  the standards process itself.
> [..]
>  IRTF groups are not trying to produce standards of
>  any kind
> 
> and yet, setting standards (blue book standards for the CCSDS
> ISO subgroup) is what the IPNRG, DTNRG, and their participants have
> been doing the work for all along:
> http://public.ccsds.org/publications/archive/734x2b1.pdf

the paragraph from RFC2014 that you quote one sentence from also goes on to say:

   In addition, it 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.

The "are not to produce standards of any kind" sentence from RFC4440 continues with "and that the output of IRTF groups does not require consensus within the RG, or broad consensus from the IETF."

The DTNRG has not set standards. It has not produced standards track RFCs. What has happened is EXACTLY what the two RFCs you quote prescribe as the route in which IRTF output can influence the standardization process: as input from the community. This is how the experimental protocols developed in the DTNRG ended up as input into the DTN WG in the IETF. And now we'll see if that output will see sufficient IETF consensus to become an IETF standard.

What you mean when you say "setting standards is what the IPNRG, DTNRG, and their participants have been doing" is that bodies OTHER than the IETF have taken some of the DTNRG output and decided to use them as if they were standards documents. And yes, this was probably promoted by some DRNRG participants. But this is not unusual. Participants who believe in a technical approach will try and promote it within the IETF/IRTF as well as outside.

What's the alternative? If an ISO group believes that IRTF output is suitable for them, how do you envision us stopping them using it as they see fit? We are not the network or protocol police. If an IRTF-developed protocol fits their needs, why would they not use it?

> So, how should the IRTF cooperate with other communities?
> Good question, worth asking for a research organisation
> cooperating with other peer research organisations,
> just as the IETF cooperates with W3C, 3GPP, et al. between
> peer standards bodies.

There aren't really any parallel organizations to the IRTF that I'm aware of. Sure, IEEE has a bunch of technical societies, but they are much more academic than the IRTF is. All other research organizations (ACM, USENIX, etc.) I'm familiar with are much more academic than the IRTF. Their output is peer-reviewed papers, and the ideas may make it into standards, but there is no defined route. So I don't know whom to ask.

> How should the IRTF do work for standards
> bodies, either the IETF or outside the IETF? The RFCs
> I've quoted seem clear. I don't think it's supposed to,
> and I don't think the IRTF should be trying to do standards
> development for anyone,

See above. That is not what the DTNRG in particular or the IRTF in general have done or are doing.

> as that immediately narrows the
> research focus to a single solution that can be standardised
> with intent to fast-track as a standard inside (and outside)
> the IETF, regardless of its merits.

"Immediately" - seriously? The DTNRG has been around since 2002, and has looked at a very wide variety of topics over the years.

> There's an immediate
> conflict of interest for the participants, especially
> those wearing more than one body's hat.

Everyone wears more than one hat. Open processes are how we deal with that fact of life.

> So, either the DTNRG is a spectacularly unique failure
> because it flouted the IRTF conventions put in place
> for good reason (and, oh yeah, those engineering
> decisions, partly driven by not wanting to disrupt
> the CCSDS standards process by revisiting anything),
> or it's an example of wider failings across the IRTF
> as a whole. Take your pick.

No, thank you. The two options you present are a little too removed from reality.

Lars