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

[<[e-mail]>]

Lars, 


My distaste for the bundle protocol and DTNRG is more
a distaste for both poor engineering decisions and poor
process.


the DTNRG (formerly the Interplanetary Internet IPNRG, now 
the DTNWG - third time's the charm, eh?) played fast and
loose with IRTF conventions:


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


and the motivation for transitioning to DTNWG is to finally
get to the holy grail of a CCSDS book standard and an IETF
standard that might gain popular adoption, because the last
two attempts haven't managed to do so.


Partly because of poor engineering design
decisions that have to be revisited ("should a protocol
intended for the harshest of conditions have any internal
error detection or sanity-checking? No, of course not!"),
partly because of a whole bunch of other debatable factors.


But, since you've just finally closed down DTNRG, this
problem and the question of hewing to what the IRTF is
supposed to do for a now-closed research group is no longer
your problem as IRTF chair. Be thankful.


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.


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, 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. There's an immediate
conflict of interest for the participants, especially
those wearing more than one body's hat.


There isn't a win-win in doing that, as much as the
participants might wish there was.



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.
 

Lloyd Wood
http://sat-net.com/L.Wood/dtn

----- Original Message -----
From: "Eggert, Lars" <[e-mail]>
To: "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>; "[e-mail]" <[e-mail]>
Sent: Tuesday, 22 March 2016, 21:02
Subject: Re: Observations on (non-technical) changes affecting IETF operations

On 2016-03-22, at 2:03, [e-mail] wrote:

>> The mode of failure I keep seeing in IETF is the following:
>> 
>> 1) A very narrow scope is decided 'to focus'
>> 
>> 2) Poorly thought out aspects of the proposal are defended because the
>> problems they cause are 'out of scope'
>> 
>> 3) The resulting RFC describes a protocol that is worse than useless.
>> 
>> 4) The proposal fails in the market.
>> 
>> 5) The experience is used as 'proof' that the problem is insoluble. (optional)
> 
> This holds for the IRTF too - though step 5 there is 'let's form an IETF workgroup to push it into adoption! This time for sure!'

No, it doesn't "hold for the IRTF." Please don't generalize from your dislike of the DTNRG's bundle protocol to the DTNRG as a whole, and then to the entire IRTF.

Lars