Subject: [dtn] on obsoleting RFC5050

From: "Marc Blanchet" <[email-masked]>
Date: Thu, 17 Oct 2019 06:18:31 -0400

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

---

From: Carlo Caini <[email-masked]>
Date: Thu, 17 Oct 2019 13:28:59 +0000

I am in favor to your proposal.
Yours,
    Carlo Caini

At 12:18 17/10/2019, Marc Blanchet wrote:

>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.
>
>    * 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 
>    * 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.
>        * 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 
>        * 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, …
>_______________________________________________
>dtn mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dtn

---

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Thu, 17 Oct 2019 14:11:57 +0000

I enthusiastically support this proposal.

Scott

From: dtn <[email-masked]> On Behalf Of Marc Blanchet
Sent: Thursday, October 17, 2019 3:19 AM
To: DTN WG <[email-masked]>
Cc: [email-masked]
Subject: [EXTERNAL] [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.

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

---

From: Mehmet Adalier <[email-masked]>
Date: Fri, 18 Oct 2019 10:53:02 -0700

I support this proposal.

Mehmet Adalier

Antara Teknik LLC

From: dtn <[email-masked]> on behalf of Marc Blanchet <[email-masked]>
Date: Thursday, October 17, 2019 at 3:18 AM
To: DTN WG <[email-masked]>
Cc: <[email-masked]>
Subject: [dtn] on obsoleting RFC5050

Hello,

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, …
_______________________________________________ dtn mailing list [email-masked] https://www.ietf.org/mailman/listinfo/dtn

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 18 Oct 2019 18:19:43 +0000

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

Fred

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

Hello,

---

From: "Birrane, Edward J." <[email-masked]>
Date: Fri, 18 Oct 2019 18:25:51 +0000

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 <[email-masked]>
Sent: Friday, October 18, 2019 2:20 PM
To: Marc Blanchet <[email-masked]>; DTN WG <[email-masked]>
Cc: [email-masked]
Subject: RE: [dtn] on obsoleting RFC5050

Fred

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

Hello,

---

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Fri, 18 Oct 2019 21:20:57 +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.

Scott

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

I also support.

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

Fred

Hello,

---

From: "Marc Blanchet" <[email-masked]>
Date: Sat, 19 Oct 2019 16:47:02 -0400

On 18 Oct 2019, at 17:20, Burleigh, Scott C (US 312B) wrote:

> 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.

up to now, everybody who spoke up on the chairs’ proposal agreed, so 
it looks good. Let’s wait a little bit more before declaring 
consensus!

However, I think we are not yet done for the IANA considerations 
section. I started creating a email with proposed changes for the IANA 
sections and registries, but it became very convoluted. So I reverted to 
a google doc, so people can better see my comments, rationale, etc…  I 
have not yet finished comments on all registries, but would like to 
share right away my thinking.

https://docs.google.com/document/d/13ubTaPOUp1F0-3W1F5zFCumi-U5-awQBRJqq3eZIyX8/edit?usp=sharing

Marc.