Re: [dtn] Marking RFC5050 as Obsolete?

Carsten Bormann <cabo@tzi.org> Mon, 23 September 2019 10:28 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: dtn@ietfa.amsl.com
Delivered-To: dtn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D04CA1202DD for <dtn@ietfa.amsl.com>; Mon, 23 Sep 2019 03:28:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mn6b06MVuexH for <dtn@ietfa.amsl.com>; Mon, 23 Sep 2019 03:28:57 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2AAC120105 for <dtn@ietf.org>; Mon, 23 Sep 2019 03:28:56 -0700 (PDT)
Received: from [192.168.217.110] (p548DCE50.dip0.t-ipconnect.de [84.141.206.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (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 <cabo@tzi.org>
In-Reply-To: <1376435003.14731004.1569226573419@mail.yahoo.com>
Date: Mon, 23 Sep 2019 12:28:54 +0200
Cc: irtf-chair@irtf.org
X-Mao-Original-Outgoing-Id: 590927333.11558-2f492f46b550992376d873e4677ee401
Content-Transfer-Encoding: quoted-printable
Message-Id: <7DC9F8DB-00E1-47C6-8F05-93771AEE4B0C@tzi.org>
References: <ecc5ee275929440b8b70d570451219a77dc5a176.camel@tropicalstormsoftware.com> <1376435003.14731004.1569226573419@mail.yahoo.com>
To: "dtn@ietf.org" <dtn@ietf.org>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/7KwKKj41RwoctmHTjX0Amt9GWMM>
Subject: Re: [dtn] Marking RFC5050 as Obsolete?
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." <dtn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtn>, <mailto:dtn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dtn/>
List-Post: <mailto:dtn@ietf.org>
List-Help: <mailto:dtn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtn>, <mailto:dtn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Sep 2019 10:29:00 -0000

On Sep 23, 2019, at 10:16, lloyd.wood@yahoo.co.uk <lloyd.wood=40yahoo.co.uk@dmarc.ietf.org> wrote:
> 
> Explicitly obsolete RFC5050? Do you really want to do this?

Yes.

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.