Re: [dtn] BPbis consensus status
Marc Blanchet <marc.blanchet@viagenie.ca> Wed, 16 September 2020 19:51 UTC
Return-Path: <marc.blanchet@viagenie.ca>
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 0F7193A0BED for <dtn@ietfa.amsl.com>; Wed, 16 Sep 2020 12:51:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=viagenie-ca.20150623.gappssmtp.com
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 XxLmcULTvrKR for <dtn@ietfa.amsl.com>; Wed, 16 Sep 2020 12:50:59 -0700 (PDT)
Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 289B53A0BE2 for <dtn@ietf.org>; Wed, 16 Sep 2020 12:50:58 -0700 (PDT)
Received: by mail-qk1-x72a.google.com with SMTP id q63so9553412qkf.3 for <dtn@ietf.org>; Wed, 16 Sep 2020 12:50:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=viagenie-ca.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=zY4tSzPNArYSds/z8TuLScrIA6Tuminm5y+Kpei3QrY=; b=lM+XUrdnKkNAkJi+1IPy7tr3owo+K4AOmz2h8j6D3rwsruRLl0OdTX/cjheMtWGINT y2DMcQ54KC70CXudUdlPSvGtqeiHn6b/YYhDBrXChfMy2z0WZJKmLzm9b1FlJ0aoFZfF VYtm20yItB0WDfomG5L7R4cdqV0hTCzvRB6OH72f2wdq0KxIeT2HiDyzcQlS65cipWti TlpgNs/cNH7ekhZIp9c76OMKfe7f2FHx73giAjAex0gYZVlWMCnGzdkCXUPDXN7iFLhx dU7nuCt1QG8ljOt7w56dgcKU8WQxahFvblpdBOJV7bnZU2foLsBx37f5GNwNMKI2D0rD GQ1g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=zY4tSzPNArYSds/z8TuLScrIA6Tuminm5y+Kpei3QrY=; b=AgpTJrfpRLgaKnWUjrSZ68G7cLVaLs9IFvFk/3KaGYgLWBKZT2tqdFM9KZZm6bhQYI VDghSI0eXfsQRUzzleYhPrIraBWiCxxYNfHt6JNGnNFLmzEc6dnj9cBVntV0SKVa0RdJ Qwqxl8NOTtTVaIOpiBFrApWF5e6HBS3E5GJrZ+k3gOPoRpZxh2gngKUVBhG9i0bCrcpM BCqyuIbllk6aF/OSOb9LOyiTMtNrExgaz98bFwhST/4/uG8RE0GnBO1CdazDStN70DWq nzNs46cI753MX5s0od6+5lPdRdy1NLbPRK1CDYuPAQCj/XuPo1TdCWeeZWcf7mI7LhoA RCqQ==
X-Gm-Message-State: AOAM532qQ324F1zC/JiXFYabQ2nL0PHEOTD0LPGlOQphY8arZOn8FNN9 VbNLL+vdUVkQr0v8bxjYSgr/AFUnpGHPKg==
X-Google-Smtp-Source: ABdhPJwWEReC3AJzoUJERngPp3GdGcEKbMEVf8M1Yjvznlm4Uz59CWlO5RabU1wi/p83WoKG1eZRfA==
X-Received: by 2002:ae9:f306:: with SMTP id p6mr24316966qkg.104.1600285857819; Wed, 16 Sep 2020 12:50:57 -0700 (PDT)
Received: from [192.168.1.59] (modemcable138.218-70-69.static.videotron.ca. [69.70.218.138]) by smtp.gmail.com with ESMTPSA id m196sm19702094qke.87.2020.09.16.12.50.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Sep 2020 12:50:57 -0700 (PDT)
From: Marc Blanchet <marc.blanchet@viagenie.ca>
To: "Burleigh, Scott C" <scott.c.burleigh=40jpl.nasa.gov@dmarc.ietf.org>
Cc: dtn@ietf.org
Date: Wed, 16 Sep 2020 15:50:56 -0400
X-Mailer: MailMate Trial (1.13.2r5673)
Message-ID: <F2B67324-D3F5-4F28-8CC3-207EB607E6EA@viagenie.ca>
In-Reply-To: <34a7886b09d946faa816acbd26700d65@jpl.nasa.gov>
References: <34a7886b09d946faa816acbd26700d65@jpl.nasa.gov>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/P9haLz3P_qyM7lgs3rWoYKV07wk>
Subject: Re: [dtn] BPbis consensus status
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: Wed, 16 Sep 2020 19:51:01 -0000
On 16 Sep 2020, at 15:43, Burleigh, Scott C (US 312B) wrote: > Hi. As best I can work out from the last eight weeks of emails, here > is the status of the remaining open questions on the BPbis draft. > > 1. Should the BPbis specification mandate implementation of the BPSec > security extensions? > a. On July 27, Marc Blanchet strongly opposes this mandate. I’m still opposed to have BPSEC be mandatory to implement as I think the security services can be done within the payload. IP is currently not secured on the Internet. It is within the IP payload (TLS) that security services are applied. I want a fully conformant BP implementation to ship without BPSec and without any specific use case (e.g. forwarding vs non-forwarding). However, I expect many use cases to require security, but again, in those cases, it can be accomplished within the payload, not at the BP level. Having said that, if I’m the only one in that camp, then I guess I’m loosing… Marc. > b. On July 28, Brian Sipos supports the mandate in a limited way: > when bundle-level security is needed, that security must be provided > by BPSec rather than by some other mechanism. [This language now > appears in section 9 of version 26 of the BPbis Internet Draft.] > c. On July 28, Ronny Bull agrees with Brian. > d. On July 28, Mehmet Adalier agrees with Brian. > e. On July 28, Ed Birrane agrees with Brian. > f. On July 29, Ran Atkinson supports the mandate in a more expansive > way: implementation of BPSec is mandatory for any Bundle Protocol > Agent that sources, verifies, and/or accepts a bundle. A BPA that > only forwards bundles (without verifying them) need not implement > BPSec. > g. On July 29, Rick Taylor agrees with Ran. > h. On July 29, Ed Birrane agrees with Ran. > i. On July 29, Ronny Bull agrees with Ran. > j. On August 3, Adam Wiethuechter agrees with Brian. > k. On September 2, Magnus Westerlund supports the mandate without > limitation. > > 2. Is the registration policy for Bundle and Block Processing Control > flags in sections 10.3 and 10.4 of BPbis version 26 satisfactory? > a. To date, no comments from the Working Group. > > 3. Does the language in section 5.4 Step 2 of BPbis version 26 > satisfactorily address the question of mandating implementation of > TCPCL in the BPbis specification? > a. To date, no comments from the Working Group. > > 4. Does the language in section 4.2.2 and 5.5 of BPbis version 26 > satisfactorily address the question of authorizing Bundle Protocol > Agents to override the bundle lifetimes asserted by BP applications? > a. To date, no comments from the Working Group. > > 5. Does the language in section 4.1.5.1.1 of BPbis version 26 > satisfactorily address the question of discerning whether or not a > given dtn-scheme endpoint ID identifies a singleton endpoint? > a. To date, no comments from the Working Group. > > 6. Does the language in section 10.6 of BPbis version 26 > satisfactorily address the question of limiting the permitted number > of different BP URI scheme type codes? > a. To date, no comments from the Working Group. > > 7. In version 26 of the BPbis specification, all BP time values (e.g., > bundle creation time, lifetime, bundle age) are denominated in > milliseconds rather than in seconds or microseconds. Is this > satisfactory? > a. On July 28, Carsten Bormann notes that the CBOR representation of > time values could utilize tags to reduce transmission bandwidth > consumption. > b. On July 29, Jeremy Mayer endorses Carsten's idea: times may be > denominated in seconds (tag 1) or at other granularity (tag 1001). > c. On July 29, Ed Birrane warns that this concept introduces the > possibility of time values changing in transit, violating the > immutability of primary blocks. > d. On July 29, Rick Taylor, Scott Burleigh, Ed Birrane, and Ran > Atkinson discuss the question of what is really meant by the > immutability of the primary block: semantic immutability or syntactic > immutability? > e. On August 3, Adam Wiethuechter agrees with Ran that both semantic > immutability and syntactic immutability are required. He believes > that denominating all DTN times in milliseconds is a good resolution. > f. On August 4, Lloyd Wood explains immutability. > > 8. Does the language in section 4.3 of BPbis version 26 satisfactorily > address the question of whether implementation of all extension blocks > defined in the BPbis specification is mandatory or conditional? > a. To date, no comments from the Working Group. > > Scott > > _______________________________________________ > dtn mailing list > dtn@ietf.org > https://www.ietf.org/mailman/listinfo/dtn
- [dtn] BPbis consensus status Burleigh, Scott C (US 312B)
- Re: [dtn] BPbis consensus status Marc Blanchet
- Re: [dtn] BPbis consensus status R. Atkinson
- Re: [dtn] BPbis consensus status Marc Blanchet
- Re: [dtn] [EXTERNAL] Re: BPbis consensus status Burleigh, Scott C (US 312B)
- Re: [dtn] [EXT] Re: [EXTERNAL] Re: BPbis consensu… Birrane, Edward J.
- Re: [dtn] [EXTERNAL] BPbis consensus status Marc Blanchet
- Re: [dtn] [EXTERNAL] BPbis consensus status R. Atkinson
- Re: [dtn] [EXTERNAL] BPbis consensus status Magnus Westerlund
- Re: [dtn] [EXTERNAL] BPbis consensus status Marc Blanchet
- Re: [dtn] BPbis consensus status Lloyd W
- Re: [dtn] [EXTERNAL] Re: BPbis consensus status Burleigh, Scott C (US 312B)
- Re: [dtn] BPbis consensus status R. Atkinson