Re: [dtn] Marking RFC5050 as Obsolete?

Colin Perkins <> Tue, 24 September 2019 14:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E863E120147 for <>; Tue, 24 Sep 2019 07:04:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id odsqFoxrvdAR; Tue, 24 Sep 2019 07:04:43 -0700 (PDT)
Received: from ( [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8597C1200B3; Tue, 24 Sep 2019 07:04:43 -0700 (PDT)
Received: from [] (port=20451 by with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.2) (envelope-from <>) id 1iClQj-0001t7-EJ; Tue, 24 Sep 2019 15:04:41 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Colin Perkins <>
In-Reply-To: <>
Date: Tue, 24 Sep 2019 15:04:28 +0100
Cc: "R. Atkinson" <>,, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <>
To: Carsten Bormann <>
X-Mailer: Apple Mail (2.3445.104.11)
X-BlackCat-Spam-Score: 14
Archived-At: <>
Subject: Re: [dtn] Marking RFC5050 as Obsolete?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 24 Sep 2019 14:04:46 -0000

> On 24 Sep 2019, at 12:33, Carsten Bormann <> wrote:
> On Sep 24, 2019, at 13:18, R. Atkinson <> wrote:
>> If the DTN WG chairs believe, after they decide this thread is finished, that there is WG consensus to obsolete RFC-5050, then I’d suggest that the DTN WG chairs ask the IRTF Chair (with CC: to the IESG) to obsolete RFC-5050 while noting the WG consensus to do so.  If that request were made, then I would hope the IRTF Chair then would do so.
> Sounds like a good approach to me.
>> It is EASY to follow the correct process here.  We need not leave the well trod path and go bushwhacking to create a new path.
> Agreed.  

Indeed – it seems we’re in vigorous agreement on the principle, but perhaps differ in how to make the process concrete.

> Translating this to a useful process from the point of the WG that creates the obsoleting specification:
> — WG agrees that the RFC-to-be should obsolete the experimental RFC; write this into the I-D (“obsoletes” attribute + mention in abstract/introduction)
> — confirm the consensus for this in the WGLC

I agree with all this.

> — put out the formal request to the IRTF chair at the time the document is submitted to the IESG (i.e., “leaves the WG”) — as always, an early heads up is probably appreciated, but the IRTF chair’s decision should be based on what actually leaves the WG.

An early heads-up from working group would be appreciated, and might be useful to avoid late surprises, but I'd expect the formal request to change the status of the IRTF RFC to come from the IESG, not the working group.


> The IESG should probably check before approval that such a process was followed (oh no, another line item in the shepherd’s writeup), but, really, the RFC editor should be the gating point here.
> Grüße, Carsten

Colin Perkins