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

<> Wed, 23 March 2016 09:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E971912DB7C for <>; Wed, 23 Mar 2016 02:11:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jFDtww728DCA for <>; Wed, 23 Mar 2016 02:11:08 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3A05212DB74 for <>; Wed, 23 Mar 2016 02:11:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s2048; t=1458724267; bh=Spcx3P1+P2RzP8AIuVeWE96SHu+xKnj5M1d4221lF/4=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=X1RLPdC2bUUgZlM9lkt+q3ZSMXMnU4vnwScKCxt3Nv6JVmX/s8f9TCWkY8+xrXVBpl3KCwKH/JbNsFyNHQDW89uEUeqsCv96HG/90bm8lThzj/OXJjnnYLncQX++zPlUhr08KkErhj8vFEu2tzsT3/W++4qP32/Th9h3YbB1dlEtCGX+BwNVYyZ9V/WWJ/rhkT/ZHvsapbmhWFx9Jg/n4xl3XTtpmAVDszHCJGHUNSF+jgpc+hxDJWwfulmzTewvS/S79BbV60GmMGO082KYRQ1ZGgTNRNx5auE4e7tiWRJA5kNQ49/SzDxmlS30rB0bdPiDYRRdNGeEQY2ranO3Vg==
Received: from [] by with NNFMP; 23 Mar 2016 09:11:07 -0000
Received: from [] by with NNFMP; 23 Mar 2016 09:08:07 -0000
Received: from [] by with NNFMP; 23 Mar 2016 09:08:07 -0000
Received: from [] by with NNFMP; 23 Mar 2016 09:08:07 -0000
Received: from [] by with NNFMP; 23 Mar 2016 09:08:07 -0000
X-Yahoo-Newman-Property: ymail-4
X-YMail-OSG: SrQVELMVM1mFcKdD0i9HVuGmy7k7x.9zllKkWRhKR88MmfL.Tf2KiRHSiSVYJ_C 8XGG6aokc28zc71bA5WFh1WKTgB7fyzVevkPpvIx5Zh638aiU__l40HOT9czlro.pmcvzz77c3nY fkm4jYvvOEdIjGWJWLgh61ltIkw179LYqJj8bd5s6IU.8nh6ZKsrWMqgrHN0ONRYZco.GmMuurgo rACmcYuNdSKchFiOInrR9jQyFoiEaKYXSbe9PoSixCPjvLyTnNgcec8WmeqR1DAWENhxSqEToA7b FwsZJCWafR7CZlOSe34jbR5zL9tER10wgGLk5wdSCNZduuBsRK9Op4TprpxxK5y1RR9OSrfoJ2Pw jh98AeK_ZCnEGuY8wBhSTn0B3YVGfiUHkpiSQ.giaqa5Ks0tmTXOVmSizpMUOwVIbqcobVUIhoaM h4WmzfNGIt_5ioBrYG5VwutCoWnzbpJxzsxfMMoSZoShGGy_tMDP_abqbgDN._vS3NWVa3LE8SDv nK2AbaKww55BtTg5krhhAQt2.LpMTtl8-
Received: by; Wed, 23 Mar 2016 09:08:06 +0000
Date: Wed, 23 Mar 2016 09:08:05 +0000
To: "Eggert, Lars" <>, "" <>
Message-ID: <>
In-Reply-To: <>
References: <>
Subject: Re: Observations on (non-technical) changes affecting IETF operations
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Cc: "" <>, "" <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 23 Mar 2016 09:11:10 -0000


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

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

  The IRTF does not set standards

  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:

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

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

On 2016-03-22, at 2:03, 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.