Re: [dtn] on obsoleting RFC5050

"Burleigh, Scott C (US 312B)" <> Fri, 18 October 2019 21:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BE10A120074; Fri, 18 Oct 2019 14:21:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 DhcBGKmQz1xG; Fri, 18 Oct 2019 14:21:00 -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 1BE8512008C; Fri, 18 Oct 2019 14:21:00 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id x9ILAVMl123058; Fri, 18 Oct 2019 14:20:59 -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 : mime-version; s=InSight1906; bh=hPoh2XL9BCDkLww3/tuKEncHCJ+aBHIVgChsvBH0nZ0=; b=Web7m+pMZbVwvbkUkhsCOM27cJbAiaBlkjTUPW0lnRgwuGvKA/ElDPcTNR9po0JUtohC zg2vDQcXUT374v+MFp5rHHnVad39ir2k9/F0vYMHvF28KI8rcteqyc4khao8nxjcxHZ1 sQYJYB3MU84MP04sSXBv/WXmuB8+viusNdrz39FMq9fZXF+/ULkMg5Oz4lZXXRdDjyW7 D/z5wkiyNyqqutR2P0I9w4lOXth6Brmg+DcHyHfUcjZP7ZMJQnhv6ZPjGiFsg12AqOK7 0Pl2+FP+wrTDPTGwUSVmb3qCzR17EJtBnSqAbcQiD+uwHSQKIAj51m73Pt55ff5reFem 1A==
Received: from ( []) by with ESMTP id 2vq95d2frc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 18 Oct 2019 14:20:59 -0700
Received: from ap-embx16-sp20.RES.AD.JPL ( []) by (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id x9ILKwbC014347 (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128 bits) verified FAIL); Fri, 18 Oct 2019 14:20:58 -0700
Received: from ap-embx16-sp10.RES.AD.JPL (2002:8095:8953::8095:8953) by ap-embx16-sp20.RES.AD.JPL (2002:8095:8954::8095:8954) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Fri, 18 Oct 2019 14:20:58 -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; Fri, 18 Oct 2019 14:20:58 -0700
From: "Burleigh, Scott C (US 312B)" <>
To: DTN WG <>
CC: "" <>
Thread-Topic: [dtn] on obsoleting RFC5050
Thread-Index: AQHVheCty75vzoGW2Ui47fbj9MiMwKdhLIiA//+2wGA=
Date: Fri, 18 Oct 2019 21:20:57 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_49c470969e454a4892734173fb56a028jplnasagov_"
MIME-Version: 1.0
X-Source-IP: []
X-AUTH: Authorized
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-18_05:, , 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=1015 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-1910180187
Archived-At: <>
Subject: Re: [dtn] on obsoleting RFC5050
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: Fri, 18 Oct 2019 21:21:03 -0000

Hello.  Jumping the gun a little bit, I have posted an updated Internet Draft (version 15) for BPbis.  I believe this draft reflects all of the agreements we have reached since the start of the Area Director’s review, and it anticipates consensus on the question of obsoleting RFC 5050 as discussed below.

This draft also incorporates two other adjustments:

·         In a couple of places the previous draft did not make it absolutely clear that data items in the bundle blocks were to be encoded in CBOR representation.  I’ve added some text that I hope agrees with everybody’s understanding.

·         In Step 5 of section 5.4 I have added some text that explicitly authorizes behavior that is already included in some BP implementations (e.g., ION): if convergence-layer transmission is found to have failed for some reason, the BPA is authorized (definitely not required) to make another forwarding attempt, possibly selecting a different route.  I think this sort of implementation policy was not explicitly prohibited in earlier drafts, but I think an explicit okay would be helpful all the same: it reflects some of the original intent of the custody transfer concept, without imposing the custody transfer protocol machinery that has raised issues in the past.  (Formal custody transfer is still preserved in the new bundle-in-bundle encapsulation specification, as we have discussed.)

Please speak up if you object to either or both of these tweaks, and I will post another revised I-D reflecting the consensus of the WG.


From: dtn <> On Behalf Of Birrane, Edward J.
Sent: Friday, October 18, 2019 11:26 AM
To: DTN WG <>
Subject: [EXTERNAL] Re: [dtn] on obsoleting RFC5050

I also support.

Edward J. Birrane, III, Ph.D.
Embedded Applications Group Supervisor
Principal Staff, Space Exploration Sector
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423<tel:(443)%20778-7423> / (F) 443-228-3839<tel:(443)%20228-3839>

From: Templin (US), Fred L <<>>
Sent: Friday, October 18, 2019 2:20 PM
To: Marc Blanchet <<>>; DTN WG <<>>
Subject: RE: [dtn] on obsoleting RFC5050

I appreciate the well thought-out rationale and support this proposal.


From: dtn [] On Behalf Of Marc Blanchet
Sent: Thursday, October 17, 2019 3:19 AM
To: DTN WG <<>>
Subject: [dtn] on obsoleting RFC5050

based on the various inputs and good discussion on the mailing list regarding obsoleting RFC5050, the chairs have come to this conclusion. Please state your support or not so we can move forward.

Regards, Marc&Rick, co-chairs.

  *   RFC5050 is an experimental RFC, done in IRTF, while draft-ietf-dtn-bpbis will be a Standard track RFC, done in IETF. Different streams, different processes.
  *   we believe there is a strong consensus to not continue working on RFC5050 and not try to be backward compatible. RFC5050 implementations and deployments can continue as they see fit.
  *   IANA registries have their own life, whatever the stream or type of RFC they were created from. They can always be updated by a new RFC.
  *   Given that, we suggest the following steps:

     *   1) draft-ietf-dtn-bpbis would not obsolete RFC5050. Instead we would notify IRTF that draft-ietf-dtn-bpbis is an update of RFC5050. IRTF will decide what they want to do, if anything, with RFC5050.
     *   2) in the new version of the charter that we are currently working on, we will state clearly that there is no intent to work on or make compatible work with RFC5050 and related RFCs
     *   3) DTN working group document authors will review the IANA registries as they are today and request whatever modifications needed, which may include changing the policies, the content, the rules, …