Subject: [dtn] Regarding BPv7 Obsoleting BPv6

From: Magnus Westerlund <[email-masked]>
Date: Thu, 23 Jan 2020 17:50:55 +0000

WG,

The current BPv7 documents (BPbis, BPSec and TCPCLv4) where intending to
obsolete BPv6 and the corresponding RFCs. However, due to a mistake from my
side I would recommend that we split the whole obsoletion out from the
publication of the BPv7 specifications. 

There are several reasons for this recommendation:

*	First I missed to make an explicit call in the IETF last call about
the obsoletion and invoking the process. 
*	Secondly, as this would be the first time attempting to use the
process of obsoleting an IRTF stream document. It hasn't been discussed in
IETF in public, although IRSG has approved the IRTF part, and we discussed
it in IESG. However, there has been concerns about the lack of public
discussion in the IESG. Therefore, I have been recommended to first announce
this process and allow for discussion and reply to any concern over it
before applying it to avoid any appeals. 
*	Announcing the discussion, responding to any feedback, then redoing
the IETF last calls will result in a delay of at least month likely two.
This will be a significant delay. 

To ensure that we can make progress and don't delay the publication of BPv7
specifications my proposal is the following. 

*	BPbis, BPsec and TCPclv4 do not obsolete their BPv6 counter parts.
Thus, making it possible to progress these specification with minimal delay
if any. If the WG agrees to this plan and the authors BPbis and BPsec can
submit a new draft within a week (by 30 Jan) we should have no delay due to
this. 
*	Then the WG can write a separate document requesting making BPv6
historic. This document can then request the obsoletion of the relevant
RFCs. As there was a rough consensus on these obsoletion we can actually
ensure that this document correctly describe the situation that development
will occur in BPv7 and the fact that usage of BPv6 will continue. 

So I would very much appreciate rapid feedback on this. 

I am very sorry about the complications and my errors in processing this. 

Magnus Westerlund

TSV AD

---

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Thu, 23 Jan 2020 18:25:04 +0000

That sounds fine to me, Magnus.  I need to post a revised draft anyway.

Scott

From: dtn <[email-masked]> On Behalf Of Magnus Westerlund
Sent: Thursday, January 23, 2020 9:51 AM
To: [email-masked]
Subject: [EXTERNAL] [dtn] Regarding BPv7 Obsoleting BPv6

WG,

The current BPv7 documents (BPbis, BPSec and TCPCLv4) where intending to obsolete BPv6 and the corresponding RFCs. However, due to a mistake from my side I would recommend that we split the whole obsoletion out from the publication of the BPv7 specifications.

There are several reasons for this recommendation:
-          First I missed to make an explicit call in the IETF last call about the obsoletion and invoking the process.
-          Secondly, as this would be the first time attempting to use the process of obsoleting an IRTF stream document. It hasn't been discussed in IETF in public, although IRSG has approved the IRTF part, and we discussed it in IESG. However, there has been concerns about the lack of public discussion in the IESG. Therefore, I have been recommended to first announce this process and allow for discussion and reply to any concern over it before applying it to avoid any appeals.
-          Announcing the discussion, responding to any feedback, then redoing the IETF last calls will result in a delay of at least month likely two. This will be a significant delay.

To ensure that we can make progress and don't delay the publication of BPv7 specifications my proposal is the following.

-          BPbis, BPsec and TCPclv4 do not obsolete their BPv6 counter parts. Thus, making it possible to progress these specification with minimal delay if any. If the WG agrees to this plan and the authors BPbis and BPsec can submit a new draft within a week (by 30 Jan) we should have no delay due to this.
-          Then the WG can write a separate document requesting making BPv6 historic. This document can then request the obsoletion of the relevant RFCs. As there was a rough consensus on these obsoletion we can actually ensure that this document correctly describe the situation that development will occur in BPv7 and the fact that usage of BPv6 will continue.

Magnus Westerlund
TSV AD

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Thu, 23 Jan 2020 20:32:22 +0000

I appreciate Magnus' message that Scott is referring to here. Whether anything
formally says "obsoletes" or not, BPv7 can move forward but usage of BPv6 can
still continue where there is existing deployment.

The BPv6/BPv7 scenario is both like and unlike that for IPv6 and IPv4. Like the
IPv6/IPv4 experience, IPv6 did not obsolete IPv4 because they are incompatible
protocol versions. Unlike the IPv6/IPv4 experience, however, we are still at the
very earliest phases of DTN deployment, and IMHO new adopters will see the
value in starting out with BPv7 and the technical mindshare will naturally fall
in line. So, I concur with Magnus' plan, and let's just let nature take its course.

Thanks - Fred

From: dtn [mailto:[email-masked]] On Behalf Of Burleigh, Scott C (US 312B)
Sent: Thursday, January 23, 2020 10:25 AM
To: Magnus Westerlund <magnus.westerlund=[email-masked]>; [email-masked]
Subject: Re: [dtn] Regarding BPv7 Obsoleting BPv6

Scott

From: dtn <[email-masked]<mailto:[email-masked]>> On Behalf Of Magnus Westerlund
Sent: Thursday, January 23, 2020 9:51 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [EXTERNAL] [dtn] Regarding BPv7 Obsoleting BPv6

WG,

Magnus Westerlund
TSV AD

---

From: "Birrane, Edward J." <[email-masked]>
Date: Thu, 23 Jan 2020 20:40:19 +0000

That’s fine for BPSec.

-Ed

Sent with BlackBerry Work
(www.blackberry.com)

From: Magnus Westerlund <magnus.westerlund=[email-masked]<mailto:magnus.westerlund=[email-masked]>>
Date: Thursday, Jan 23, 2020, 12:51 PM
To: [email-masked] <[email-masked]<mailto:[email-masked]>>
Subject: [EXT] [dtn] Regarding BPv7 Obsoleting BPv6

WG,

  *   First I missed to make an explicit call in the IETF last call about the obsoletion and invoking the process.
  *   Secondly, as this would be the first time attempting to use the process of obsoleting an IRTF stream document. It hasn’t been discussed in IETF in public, although IRSG has approved the IRTF part, and we discussed it in IESG. However, there has been concerns about the lack of public discussion in the IESG. Therefore, I have been recommended to first announce this process and allow for discussion and reply to any concern over it before applying it to avoid any appeals.
  *   Announcing the discussion, responding to any feedback, then redoing the IETF last calls will result in a delay of at least month likely two. This will be a significant delay.

To ensure that we can make progress and don’t delay the publication of BPv7 specifications my proposal is the following.

  *   BPbis, BPsec and TCPclv4 do not obsolete their BPv6 counter parts. Thus, making it possible to progress these specification with minimal delay if any. If the WG agrees to this plan and the authors BPbis and BPsec can submit a new draft within a week (by 30 Jan) we should have no delay due to this.
  *   Then the WG can write a separate document requesting making BPv6 historic. This document can then request the obsoletion of the relevant RFCs. As there was a rough consensus on these obsoletion we can actually ensure that this document correctly describe the situation that development will occur in BPv7 and the fact that usage of BPv6 will continue.

Magnus Westerlund
TSV AD

---

From: Carlo Caini <[email-masked]>
Date: Fri, 24 Jan 2020 09:33:55 +0000

Dear Fred,
    I fully agree with you on your analysis and on the consequent 
decision of letting "the market" make the choice. In the past I 
"voted" in favor of obsoleting BPv6, but this, a posteriori, proved 
to be a wrong tactical decision (I take my quote of responsibility 
for this, having voted in favor). I hope this time to be right.
Yours,
     Carlo

At 21:32 23/01/2020, Templin (US), Fred L wrote:
>Content-Language: en-US
>Content-Type: multipart/alternative;
>  boundary="_000_04d4a18d4df24f41ab77e1f72c99b41bboeingcom_"
>
>To: Magnus Westerlund 
><magnus.westerlund=[email-masked]>; [email-masked]
>From: dtn <<mailto:[email-masked]>[email-masked]> On 
>Behalf Of Magnus Westerlund
>To: <mailto:[email-masked]>[email-masked]
>The current BPv7 documents (BPbis, BPSec and TCPCLv4) where 
>intending to obsolete BPv6 and the corresponding RFCs. However, due 
>to a mistake from my side I would recommend that we split the whole 
>obsoletion out from the publication of the BPv7 specifications.
>
>-          First I missed to make an explicit call in the IETF last 
>call about the obsoletion and invoking the process.
>-          Secondly, as this would be the first time attempting to 
>use the process of obsoleting an IRTF stream document. It hasn't 
>been discussed in IETF in public, although IRSG has approved the 
>IRTF part, and we discussed it in IESG. However, there has been 
>concerns about the lack of public discussion in the IESG. Therefore, 
>I have been recommended to first announce this process and allow for 
>discussion and reply to any concern over it before applying it to 
>avoid any appeals.
>-          Announcing the discussion, responding to any feedback, 
>then redoing the IETF last calls will result in a delay of at least 
>month likely two. This will be a significant delay.
>
>To ensure that we can make progress and don't delay the publication 
>of BPv7 specifications my proposal is the following.
>
>-          BPbis, BPsec and TCPclv4 do not obsolete their BPv6 
>counter parts. Thus, making it possible to progress these 
>specification with minimal delay if any. If the WG agrees to this 
>plan and the authors BPbis and BPsec can submit a new draft within a 
>week (by 30 Jan) we should have no delay due to this.
>-          Then the WG can write a separate document requesting 
>making BPv6 historic. This document can then request the obsoletion 
>of the relevant RFCs. As there was a rough consensus on these 
>obsoletion we can actually ensure that this document correctly 
>describe the situation that development will occur in BPv7 and the 
>fact that usage of BPv6 will continue.
>
>_______________________________________________
>dtn mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dtn

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 24 Jan 2020 14:10:31 +0100

> for this, having voted in favor). I hope this time to be right.

What Magnus wrote is not proposing to revisit the decision to obsolete RFC 5050, but to make sure we do it in the right way procedurally.
(FYI: On the IRTF side, we just decided in IRSG to agree to the request to obsolete.)

Of course BPv6 does not magically vanish from the face of the earth.
BPv6 will stay the Windows XP of bundle protocols for those who can’t upgrade.

Marking BPv6 obsolete is a signal to the market:
(1) BPv6 is not recommended for new work, having been replaced by BPv7.
(2) there no longer is an intention to “maintain” BPv6 (it having been maintained by replacing it with BPv7).

Maybe you can relate what was wrong, tactically, about your vote, so we can better understand what you are trying to say.

Grüße, Carsten