Re: [dtn] on obsoleting RFC5050

["Burleigh, Scott C (US 312B)" <[e-mail]>]

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.

Scott

From: dtn <[e-mail]> On Behalf Of Birrane, Edward J.
Sent: Friday, October 18, 2019 11:26 AM
To: DTN WG <[e-mail]>
Cc: [e-mail]
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 <[e-mail]<mailto:[e-mail]>>
Sent: Friday, October 18, 2019 2:20 PM
To: Marc Blanchet <[e-mail]<mailto:[e-mail]>>; DTN WG <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: [dtn] on obsoleting RFC5050

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

Fred

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


Hello,
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, …