Re: [dtn] Regarding BPv7 Obsoleting BPv6

"Birrane, Edward J." <Edward.Birrane@jhuapl.edu> Thu, 23 January 2020 20:40 UTC

Return-Path: <Edward.Birrane@jhuapl.edu>
X-Original-To: dtn@ietfa.amsl.com
Delivered-To: dtn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7988120823 for <dtn@ietfa.amsl.com>; Thu, 23 Jan 2020 12:40:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level:
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jhuapl.edu
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AvsjVxtaYetH for <dtn@ietfa.amsl.com>; Thu, 23 Jan 2020 12:40:22 -0800 (PST)
Received: from aplegw01.jhuapl.edu (aplegw01.jhuapl.edu [128.244.251.168]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A740212089B for <dtn@ietf.org>; Thu, 23 Jan 2020 12:40:22 -0800 (PST)
Received: from pps.filterd (aplegw01.jhuapl.edu [127.0.0.1]) by aplegw01.jhuapl.edu (8.16.0.27/8.16.0.27) with SMTP id 00NKWhFt190887; Thu, 23 Jan 2020 15:40:20 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhuapl.edu; h=from : to : date : message-id : references : in-reply-to : content-type : mime-version : subject; s=JHUAPLDec2018; bh=0YU+b7V5aoZKJfwJgCUtzcPe0lKyt15ZwE/7v3B/V5Y=; b=Yv3wHL/IuJfc87YWDu64WFLpNbutiE5uehiQtLFB/js9ubtKCJWf0QJXFuzX1hp72ZD1 TRyfSgnRtk7zVfjfTlNgLTwT3dVp/l9GVoaWwSqMAJcRHnumO33u5W3C0Q6P2/uO1h70 C9istn/LSABhTz7MFYvb8/J5BgdZ7MYdq81w8gLAwaGQ2SLCK04H+sEIcuq3BqRNFDhw +y6fzatnvPEgbKJo7R+vMjmSiEjYBIQtV4fhnAKWweO7Ce3PTFxhEAlWw1/ksdys/ccC C6EH/oE4j+0d9C5SVVR1FNb/EZfv78ZQiFXnZ+H24lgwsVzECqpNlP4FnsdqiwN0Q1VG tg==
Received: from aplex05.dom1.jhuapl.edu (aplex05.dom1.jhuapl.edu [128.244.198.135]) by aplegw01.jhuapl.edu with ESMTP id 2xqdn1hb7q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 23 Jan 2020 15:40:20 -0500
X-CrossPremisesHeadersFilteredBySendConnector: aplex05.dom1.jhuapl.edu
Received: from aplex01.dom1.jhuapl.edu (128.244.198.5) by aplex05.dom1.jhuapl.edu (128.244.198.135) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 23 Jan 2020 15:40:19 -0500
Received: from aplex01.dom1.jhuapl.edu ([fe80::19f5:dcc5:c696:1a50]) by aplex01.dom1.jhuapl.edu ([fe80::19f5:dcc5:c696:1a50%25]) with mapi id 15.00.1473.003; Thu, 23 Jan 2020 15:40:19 -0500
From: "Birrane, Edward J." <Edward.Birrane@jhuapl.edu>
To: Magnus Westerlund <magnus.westerlund=40ericsson.com@dmarc.ietf.org>, "dtn@ietf.org" <dtn@ietf.org>
Thread-Topic: [EXT] [dtn] Regarding BPv7 Obsoleting BPv6
Thread-Index: AQHV0i1THr3FC0pty0iXjZo2TJY8Ww==
Date: Thu, 23 Jan 2020 20:40:19 +0000
Message-ID: <f7937e2a4a754b0e8ce3242e7b164b23@aplex01.dom1.jhuapl.edu>
References: <DB7PR07MB4572AF8FE67BBF4EDBB65B16950F0@DB7PR07MB4572.eurprd07.prod.outlook.com>
In-Reply-To: <DB7PR07MB4572AF8FE67BBF4EDBB65B16950F0@DB7PR07MB4572.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: multipart/alternative; boundary="_000_f7937e2a4a754b0e8ce3242e7b164b23aplex01dom1jhuapledu_"
MIME-Version: 1.0
X-OrganizationHeadersPreserved: aplex05.dom1.jhuapl.edu
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-01-23_12:, , signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/le0n9Nd65CDX7NuDFdmrFJKNJfY>
Subject: Re: [dtn] Regarding BPv7 Obsoleting BPv6
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." <dtn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtn>, <mailto:dtn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dtn/>
List-Post: <mailto:dtn@ietf.org>
List-Help: <mailto:dtn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtn>, <mailto:dtn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jan 2020 20:40:24 -0000

That’s fine for BPSec.

-Ed


Sent with BlackBerry Work
(www.blackberry.com)


From: Magnus Westerlund <magnus.westerlund=40ericsson.com@dmarc.ietf.org<mailto:magnus.westerlund=40ericsson.com@dmarc.ietf.org>>
Date: Thursday, Jan 23, 2020, 12:51 PM
To: dtn@ietf.org <dtn@ietf.org<mailto:dtn@ietf.org>>
Subject: [EXT] [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.

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