Re: [dtn] Marking RFC5050 as Obsolete?

Carsten Bormann <> Mon, 23 September 2019 10:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D04CA1202DD for <>; Mon, 23 Sep 2019 03:28:59 -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=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Mn6b06MVuexH for <>; Mon, 23 Sep 2019 03:28:57 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F2AAC120105 for <>; Mon, 23 Sep 2019 03:28:56 -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 46cLCB75YMzykY; Mon, 23 Sep 2019 12:28:54 +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: Mon, 23 Sep 2019 12:28:54 +0200
X-Mao-Original-Outgoing-Id: 590927333.11558-2f492f46b550992376d873e4677ee401
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: "" <>
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: Mon, 23 Sep 2019 10:29:00 -0000

On Sep 23, 2019, at 10:16, <> wrote:
> Explicitly obsolete RFC5050? Do you really want to do this?


Generally, when experimental protocols are replaced by standards-track protocols, we mark the RFC documenting the experimental protocol as obsoleted by the RFC documenting the standards-track protocol.  E.g., see RFC 3940(*) and RFC 5740.  That, of course, doesn’t mean the *experiment* is “obsolete”, the experiment is done and was a great success, and has led to the standards-track protocol.

The fact that the obsoleted protocol specification was documented in a different process (here, in the IRTF stream) is not really relevant.  Of course, obsoleting the document in the RFC series doesn’t mean that other SDOs (here: CCSDS) magically also consider it obsoleted; that may be work that needs to be done.

I’m CCing the IRTF chair for another opinion on whether there is a problem with a IETF specification obsoleting an experimental IRTF protocol specification.  To me, it is obvious that the DTN WG was set up to do exactly that, and there were a few years to stop this process if this outcome wasn’t desired.

Grüße, Carsten

(*) which came out of an IRTF effort as well, but was completed as an experimental protocol by an IETF working group, so it is not an all-out analog to the situation here.