Hi,
On 2016-03-23, at 10:08, lloyd(_dot_)wood(_at_)yahoo(_dot_)co(_dot_)uk 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
signature.asc
Description: Message signed with OpenPGP using GPGMail