Re: [dtn] Marking RFC5050 as Obsolete?

"R. Atkinson" <> Tue, 24 September 2019 11:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8F0F612018B for <>; Tue, 24 Sep 2019 04:18:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.998
X-Spam-Status: No, score=-0.998 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, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id W78ypCXIfXvf for <>; Tue, 24 Sep 2019 04:18:37 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::82c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E75B4120106 for <>; Tue, 24 Sep 2019 04:18:36 -0700 (PDT)
Received: by with SMTP id r5so1644084qtd.0 for <>; Tue, 24 Sep 2019 04:18:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XR52qaYJUDLv3G01oQBjTBiuMrlhoBT4wlscdPiUpf0=; b=R6eTm1HZSSuDV+YApE6DHoNBrhqklOnVCfG9XROpD2riiMvvB9Enml/1QhYtBNjanf 9EZz0Lp67Q2H/wuTNeK4Kjty3og/6LmHBqslBO1/FEqdwywRKyGkRSkzpyu/RbTP7MXq kxYj77zrAoC0Pz3ZtpruB/mNWVCTt1wQfL3mx2i3dmC8ASQDJr6y4KCTOgAdW1eZ0ma5 rkf5lVK5HaP8kSeq30KV8LbCjsHbN3qiaPCflDP+rpZF3zCVBT/CKDh4zG1VMfLn6BHT wMgL5WQHCvMfgmWFHMypaQG1xqdaMSMg42Gj0cSfsbBGKksF59sbHKRLLLwc93YAu4WC 3GSw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XR52qaYJUDLv3G01oQBjTBiuMrlhoBT4wlscdPiUpf0=; b=Y6405ZRaXvhQI6DQ0IBWNhyvNLm0gvZgqXo/kXrahaFqj8AGRZVwBnbFEvLg9UdbkP 9UK/4GPm1p4NsOLHzEREHu2XdLAu805YcJ9bjPCHznYNH9k/LlMWO6L3aBmY4CbFBXKQ 6GDTONGy/NywIOGxbO0+KW8mA07uG6LXEKfUHDvqShoBTBgEnc1KhadtF8UQ+gdyUklH yj6gEB42Irdm/4WNDtTIM6swE53lKPm4YuWmnjDx26bGKP8ehUEG4pEAa9ywhVH6trum hMh7f81bhz03Nv2WcS3itxK+kEswU/U8ShwASmRhZ/Qf0vguHou4EOnsBxyH7YNwwhXe 8oXw==
X-Gm-Message-State: APjAAAXN6u+oin907McXej7SVrjIv9MscKh+YrwDEL7YEAc/pGL/OtmC B9ykZtwM4BJX+6o+YVSGr8Iyyx0b
X-Google-Smtp-Source: APXvYqzBR0HaRgbHNj3qkSvFsF0/Fb/nfaqV34Rxl4eeL2WwpVFuADbW2DriWit6pcQIFVpfr4XDyA==
X-Received: by 2002:ad4:4cc6:: with SMTP id i6mr1992943qvz.166.1569323915988; Tue, 24 Sep 2019 04:18:35 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id o8sm832285qte.47.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Sep 2019 04:18:35 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: "R. Atkinson" <>
In-Reply-To: <>
Date: Tue, 24 Sep 2019 07:18:34 -0400
Cc:, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: Colin Perkins <>
X-Mailer: Apple Mail (2.3445.104.11)
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:18:39 -0000


Procedurally, the IETF lacks authority over IRTF documents, just as the IETF lacks authority over IAB documents and the IETF lacks authority over Independent Submission documents.  

— This all was well understood when I was on the IAB about 20 years ago.  

— No subsequent process document has changed the above as the correct process.

That noted, the IRTF Chair (or IRSG) could make RFC-5050 (or any other IRTF track RFC) obsolete, and the IRTF process for doing so is WILDLY simpler — an email from IRTF Chair would be sufficient to make it happen.

> On Sep 23, 2019, at 07:37, Colin Perkins <> wrote:
>> On 23 Sep 2019, at 11:28, Carsten Bormann <> wrote:
>> On Sep 23, 2019, at 10:16, <> 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.

Disagree — based on the I* community's actual process documents.

However, the end result is easily accomplished, an email from you in your role as IRTF Chair would be sufficient to make RFC-5050 obsolete and would maintain compliance with the correct procedure.

>>  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.
> The RFC stream managers and RFC Editor had a discussion about this recently. It doesn’t seem problematic for a standards track RFC published on the IETF stream to obsolete an experimental RFC published by the IRTF, provided there’s coordination between the RFC stream managers and agreement that such a status change is appropriate. I’d expect the IESG to check with the IRTF Chair and IRSG before approving such a draft, for example.

Existing correct process would not merely “expect”, but would actually “require”, such coordination.  Further, the authority to obsolete an IRTF document procedurally rests with the IRTF Chair and/or IRSG, not with the IETF or IESG.  In practice, I imagine it is unlikely for the IESG to request anything silly of the IRTF Chair or IRSG, but PLEASE let us follow the correct process.  It is EASY to follow the correct process here.

IRTF is not a subsidiary of the IETF.  The IRTF is a subsidiary of the IAB.  The IAB also is not a subsidiary of the IETF — indeed, the IAB has to review and approve/disapprove IESG nominations coming from NOMCOM.  

And for the avoidance of doubt, that IAB review & approve/disapprove responsibility is NOT a rubber stamp.  I personally know of more than 1 case where the IAB declined to confirm a NOMCOM nomination of someone for the IESG.  I believe this is rare, but it has happened for particular cases where that decline really was the correct answer.

I assume that the ISOC folks who approve/disapprove of NOMCOM nominations for the IAB take equal care in deciding whether to approve/disapprove particular candidates.

> I’ve not read the documents in question, so I won’t comment on this specific case. 

In the specific case, I concur with the numerous folks who believe that RFC-5050 ought to be obsoleted by the publication of the standards-track RFC(s).

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.

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.