Re: [dtn] Marking RFC5050 as Obsolete?

"Burleigh, Scott C (US 312B)" <> Tue, 01 October 2019 14:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C293012083B for <>; Tue, 1 Oct 2019 07:19:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9tgyqyvJHsB7; Tue, 1 Oct 2019 07:19:47 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D9FDA120829; Tue, 1 Oct 2019 07:19:41 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id x91EH1bE039741; Tue, 1 Oct 2019 07:19:39 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=InSight1906; bh=/tItFaqmZrARd/Jmb/D+lBA2kBr+ifMyn6YapWBvoKE=; b=ZtFa1MqXww9ytpl373TRkJUxcw0g2OySgG4AWUmbldc/jM6f/Ijy8K3D+mA06gfeQBSs 6ZFZ/4if01AgDxCCOrhCEAWmcbOe8DY3GqeTDwlzrWcH0MmZxZzoN0eLdO6wl5Uuquqt XSO2UjihSjZhaeAf6RzAMZMbPFHiy5TAH/S31RtF8e2loRDcfdEaAK+wK/82h9EfXlM9 sfc7RBYoQYpk9BgOLOf5f4bK62owRBA6ROGSu14Zfw8AJaL5xGXSA6+QW72gqObr6LVi OXRGVVeFGmpy234FB3G6kdElE6y6BknmFWjYmQyYsBJs2UQOv42U8WHgArv2WiW20AtE 5A==
Received: from ( []) by with ESMTP id 2vbuuf9pdj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 01 Oct 2019 07:19:39 -0700
Received: from ap-embx16-sp40.RES.AD.JPL ( []) by (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id x91EJc4p026476 (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128 bits) verified FAIL); Tue, 1 Oct 2019 07:19:38 -0700
Received: from ap-embx16-sp10.RES.AD.JPL (2002:8095:8953::8095:8953) by ap-embx16-sp40.RES.AD.JPL (2002:8095:8956::8095:8956) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Tue, 1 Oct 2019 07:19:38 -0700
Received: from ap-embx16-sp10.RES.AD.JPL ([fe80::4:f430:47b5:767b]) by ap-embx16-sp10.RES.AD.JPL ([fe80::4:f430:47b5:767b%17]) with mapi id 15.01.1591.008; Tue, 1 Oct 2019 07:19:38 -0700
From: "Burleigh, Scott C (US 312B)" <>
To: "Templin (US), Fred L" <>, Carsten Bormann <>
CC: "" <>, "" <>
Thread-Topic: [dtn] Marking RFC5050 as Obsolete?
Thread-Index: AQHVdHJqn24+zFZv00C16o/ri+5Dq6dF2oDw
Date: Tue, 1 Oct 2019 14:19:38 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Source-IP: []
X-AUTH: Authorized
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-01_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910010128
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, 01 Oct 2019 14:19:49 -0000

Maybe one additional consideration here is that IPv4 was (and remains) a standard, while BPv6 is not; RFC 5050 is an experimental RFC, not a standards-track RFC.  Is it reasonable to infer from this that IETF has no responsibility to sustain BPv6 in any event, that the clear intent of IETF is simply to establish and sustain BPv7 as a new standard?  In which case it is perhaps just unnecessary to mark RFC 5050 as obsolete?


-----Original Message-----
From: dtn <> On Behalf Of Templin (US), Fred L
Sent: Thursday, September 26, 2019 6:58 AM
To: Carsten Bormann <>
Subject: [EXTERNAL] Re: [dtn] Marking RFC5050 as Obsolete?

Actually, I like the IPv4 / IPv6 analogy but if you don't consider also that IPv4 did not "obsolete" OSI yet there are still small pockets of OSI deployment worldwide. (For that matter, I don't think anyone ever claimed to "obsolete" DECnet.) In this sense, by going out of our way to say "obsoletes" BPv7 would going against the precedence set by a number of significant earlier examples.


> -----Original Message-----
> From: Carsten Bormann []
> Sent: Thursday, September 26, 2019 12:39 AM
> To: Templin (US), Fred L <>
> Cc:;
> Subject: Re: [dtn] Marking RFC5050 as Obsolete?
> On Sep 25, 2019, at 21:52, Templin (US), Fred L <> wrote:
> >
> > It is the same with BPv6 and BPv7 - there is a non-negligible 
> > deployment of BPv6 that will still continue after BPv7 is published whether we say "obsoletes" or not.
> > There is operational experience with BPv6 that will continue onwards 
> > the same as happened with IPv4, and that is not a bad thing.
> There will always be protocols in real world use that have been replaced by newer ones.
> The question here is one of expressing intent.  Is BPv7 intended to supersede BPv6 or not?
> I’m not talking about “deployment realities” here (heck, I still have 
> some Python v2 on my system), I’m talking about intent going forward.  
> Either the intent is to sustain both versions indefinitely (with bug 
> fixes and extensions still going into BPv6), or the intent is to move 
> to BPv7.  Like with Python v3, which ultimately needed a strong statement (and even a deadline) that it is now time to stop using Python v2 (and even then, the Python v2 is not going to vanish from my systems magically, and there will likely be some people hacking v2 and keeping it alive even beyond 2020-01-01).
> (We don’t need a deadline here, but we need to be clear about the 
> intent.)
> I don’t think IPv4 vs. IPv6 is a good analogy here, but if you have a 
> massive infrastructure processing BPv6 bundles, it may seem to be that way to you.
> Grüße, Carsten

dtn mailing list