Re: [dtn] Marking RFC5050 as Obsolete?

Carsten Bormann <> Tue, 24 September 2019 11:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9DFC6120118 for <>; Tue, 24 Sep 2019 04:33:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3grjEXBzCJl5 for <>; Tue, 24 Sep 2019 04:33:43 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A1D9212004A for <>; Tue, 24 Sep 2019 04:33:43 -0700 (PDT)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 46czbT498Sz10kQ; Tue, 24 Sep 2019 13:33:41 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <>
In-Reply-To: <>
Date: Tue, 24 Sep 2019 13:33:41 +0200
Cc: Colin Perkins <>,, "" <>
X-Mao-Original-Outgoing-Id: 591017619.371171-b2464d78f5e9d1ecdfd42b72b95c0573
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: "R. Atkinson" <>
X-Mailer: Apple Mail (2.3445.9.1)
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 11:33:46 -0000

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.


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
— 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.

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