Re: [dtn] BPbis consensus status

"R. Atkinson" <rja.lists@gmail.com> Thu, 24 September 2020 17:40 UTC

Return-Path: <rja.lists@gmail.com>
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 4767E3A1178 for <dtn@ietfa.amsl.com>; Thu, 24 Sep 2020 10:40:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.098
X-Spam-Level:
X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 tJqtQaXa0RS8 for <dtn@ietfa.amsl.com>; Thu, 24 Sep 2020 10:40:42 -0700 (PDT)
Received: from mail-qv1-xf42.google.com (mail-qv1-xf42.google.com [IPv6:2607:f8b0:4864:20::f42]) (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 5B1C63A11B5 for <dtn@ietf.org>; Thu, 24 Sep 2020 10:40:40 -0700 (PDT)
Received: by mail-qv1-xf42.google.com with SMTP id db4so2340335qvb.4 for <dtn@ietf.org>; Thu, 24 Sep 2020 10:40:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sqsJSp9J/KLPlcKVYfnHZL2BibAZiNjkxteTYtNxZS8=; b=Udrkckx+aRNcBjhXGwHo7nPicDBAh3YAcd/4MbJjZbmdhh3BsbnO9sJ9zXxPpo0Lv0 9BGOypleZUjRPU+mKFSNIo1kqxme2tNe7IRyqX+7ZDm0iLf5T+PLUVgJL62Qsee8JPr4 x8jPE3wLbj7qdBFaxa+MGCVEf741Xth1RHEM+gwOggYrMSnih+CpMMN/lnBpQP9xiBrs FNbzHgCEuQS6q0OCO9wPeiOokd6j7SlCcpM2nPDIQzsiht8TuV+yyet+x44QSGP0c0ZW YZMMvQO3fvLwdNJVHVqzRBSdRShyBKf44i/Szq1mdp9VKWpYKf83advKOH6dMa4NqkAA 5gpA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sqsJSp9J/KLPlcKVYfnHZL2BibAZiNjkxteTYtNxZS8=; b=oFfZxBx7c5bD8Tp92Oj/ivfdePemlvO2c+8VFdim4LtVe/RwZVTollszeknVO25HKw K238Tlz4g1jdBiV6gAktB9DFmD20NnTz3x2Tf0dC2JYNDlqoXI/nGY6Szts7avHISDFk y4YKtDc6Z9rvW9pHuEHoBr957UemYzNWQYvmFBlVh13VxuVQatUGM+Hj7r7ExUH8krlD awYV+7DAwk6VGwUHnjRd//TqtWiJwIEOkUh6YcC6US8yN6OShfIVZPVZrV5N7Dq8Ns/N us18lGFZ6bigR6RC87+vCV8J7QEj8Qja4EsgmgQRzeFO6IkS40cp8T1fY2pmygzt17JP U4fg==
X-Gm-Message-State: AOAM530yEqbq6aXybuxUNA2oULe9RfT6IYA/9GEuZM8cUyUkEU3TqeNU 194/8TS6BBaTuE6REYHmj2A=
X-Google-Smtp-Source: ABdhPJwwF3floALLpDyzMIqPX/cemCE20+q/jtjIbgLHwIPiLqAy1THoaFWuKtD9UapEsFjLA0qDAA==
X-Received: by 2002:a0c:abc5:: with SMTP id k5mr353417qvb.40.1600969239321; Thu, 24 Sep 2020 10:40:39 -0700 (PDT)
Received: from [10.30.20.19] (pool-141-156-180-77.washdc.fios.verizon.net. [141.156.180.77]) by smtp.gmail.com with ESMTPSA id 145sm104158qkf.18.2020.09.24.10.40.38 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 Sep 2020 10:40:38 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\))
From: "R. Atkinson" <rja.lists@gmail.com>
In-Reply-To: <905D4F6F-F19A-4154-BF62-EEEBB1109745@yahoo.co.uk>
Date: Thu, 24 Sep 2020 13:40:37 -0400
Cc: DTN WG <dtn@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <D47F16CA-F2E4-4221-8EAC-025808ECC7D5@gmail.com>
References: <34a7886b09d946faa816acbd26700d65@jpl.nasa.gov> <905D4F6F-F19A-4154-BF62-EEEBB1109745@yahoo.co.uk>
To: Lloyd W <lloyd.wood=40yahoo.co.uk@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3445.104.15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/rDTQszCnrTKSlk43AMcozOZiHcQ>
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: Thu, 24 Sep 2020 17:40:44 -0000

Lloyd,

If this is a question about quoted item #1 in Scott’s note below, then I can clarify that my original intended meaning for “verify” would be "cryptographically verify”.

Probably some slight editing (e.g., insert the word “cryptographically” in the right place) to the earlier proposed text would be desirable to make that meaning more clear.

I don’t know what others in the WG think about that (slight) change to the earlier proposed text.

Yours,

Ran

> On Sep 24, 2020, at 05:19, Lloyd W <lloyd.wood=40yahoo.co.uk@dmarc.ietf.org> wrote:
> 
> hi Scott,
> 
> what do you mean by "verify" here?
> 
> A bundle can contain a checksum (section 4.1) and that checksum SHOULD/MUST (imo) be checked before a bundle is forwarded further, to prevent transmitting corruption that would e.g. misdirect a bundle.
> 
> Is that "verification"? That affects the interpretation of your statement of Ran's 1f.
> 
> Lloyd Wood
> lloyd.wood@yahoo.co.uk
> 
> Your quality source for focused bundle checksum concerns for over a decade.
> 
>> On 17 Sep 2020, at 05:43, Burleigh, Scott C (US 312B) <scott.c.burleigh=40jpl.nasa.gov@dmarc.ietf.org> 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.
>>   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 mailing list
> dtn@ietf.org
> https://www.ietf.org/mailman/listinfo/dtn