Re: [dtn] BPbis consensus status

Lloyd W <lloyd.wood@yahoo.co.uk> Thu, 24 September 2020 09:19 UTC

Return-Path: <eclipticplane2002@yahoo.co.uk>
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 29F613A0522 for <dtn@ietfa.amsl.com>; Thu, 24 Sep 2020 02:19:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.849
X-Spam-Level:
X-Spam-Status: No, score=-1.849 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, 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=yahoo.co.uk
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 cLA6B4FxNL6D for <dtn@ietfa.amsl.com>; Thu, 24 Sep 2020 02:19:46 -0700 (PDT)
Received: from sonic314-21.consmr.mail.ir2.yahoo.com (sonic314-21.consmr.mail.ir2.yahoo.com [77.238.177.147]) (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 1ED0E3A0489 for <dtn@ietf.org>; Thu, 24 Sep 2020 02:19:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s2048; t=1600939184; bh=hWln0yuXhHe9M6lSZY8zsx90MtpMopoOzIPCXRXExNE=; h=From:Subject:Date:References:Cc:In-Reply-To:To:From:Subject; b=DX0BCkd+x9mJkqxNRmDXidq3l9PwWxl15hfSAfuyfm313Ivtd6zpTQ5kvUBRC7bGCUqFZXZbJCDfC4mfO0KGj0ylm6ef5FeO1G/wb6PtrimHPBPw9u5bd/F0U7GD3EmNUXaO7aB5OHLGrFENjPUIGApuIgA+SlPPgv1XNZOsE4sT5g0IbsdjoOd8QY/FeXUu6vdqgU4kgIS2xHtkVKrRrorgFtLOZ/4/qM0JTzw1025l6DR/Olj4vjyt0V7O4uDmBaK41ZXuGcdtDQNVi08xBPGqtQqd/YZjSip+vHw43S0Z3XNfFMN6m+5qF0ht06YmJpZdjWqoHJJNHH8aWSqisQ==
X-YMail-OSG: Cvex8EEVM1kB9aizl9ARbBVbDDiRXnFskYclADuEn8XRaM3Wc6I2rht7DTOYAiB b7D_R1cwdwgKFpa381AQ5wgEfUxDjoxyonnSq8BKrfjhkKpKsZe31h0Cvhbo1gbq7IKOEfw.DUkY EDdRAYuo2C1j7GEmcvKzI4EwRAgscXxrcMS67klfne2Zj06z_LokcE3mwzM0i9kG8p3FeSdYWs4B OytJUGvsDU6gIo8FfzD97e4xC8VfA9NtulGkpo6JLvwjruinwCTxzXYUxlmjMfO_vdrJh0GnZRNy HZAlfNJGd3GACBEEI4p3f8hWu1xA9lKrDJOmteRRm6YAhfZM3t_w8_xOoOWSsRxKVRHpAhCUBmMC Y6B9bD9ZxNtVPwmMQ.VSzakacaGDHQUk1xUs3P3a3df1ENf9l6fsoFFUHBgsX6jUG62_8WnTUHof UezTmW0YeJvCF7XSHbvQAVwu9vI9D7K.Jr8prg0p5HNBUcyTUy9O1dnDK3MVyCH9fHQT9BcULRXH hBygdNNZd8muVBTF1yxVLL76bZOdXyXc3iwjTRsRW2i3o4mOF5HJO96vgmLCRSrUK7hGpIet00xj CnpFdFg_i3ohe6jPyj83D1jU05cr5rsIpkqH6Prra75kgldbZ6KrCyJrTmaOicNpuAT08IkQkroF 4FFug80dEocX8TZ5NO8K2VP8zz7xpu5NKfeKCS4C6xRu7Z4eu7XkMqFZRBltXgN19q.ONvSs1OTh TidbrlBYjl4ytAcplDLIsVFQ5GmC3hT41sSPzXDXdPtLVuiY.8YGl6DFFNQMyhiSZv7a9AOJ7UWh 2qfPpD47XvuVpzLyiqdU6FxMYLT8BcY3YvPUMczw5mtMyfjudzGgRjcRHoQGQPjTnIhkp1z9C3pc a0AcWLdczi1R99smQV0PmREZ5w.0SNQ0.jsW5f.B2M9.CgYagx6Sz0J.kT7dCHbGRofo3GwK749g fTYrnC6I5v74A77Xot_YsaRVHq4ZmyZIVqm1xN141uiOj3HKbaTIl9w7kuTkN.Ku_9hBUPBJLp5H _EjyGdtaOLQE3htORRiZ.Nkwg_Ym7XroBxOmNWuwX1z9X9hSgxK1vFwWctVv4DBK5neXFldY35mQ lBSmWpVQI06JWHshfXQzDcIVIHFq5gxOosPZc3aIu0etcKBjX5bTcita2mGjnaUk.mpWE9tbcWwZ KC07MfacqZ5eq12U_clNKEv0FmGLThsgDOgUbctIOZDNoHZekvU6vtMmrDLfTkQJheDH9EGyoUf5 k5DSJL0DfIEcctN_MzTQJVwiiVcJOhNFeIjcwzyzGm7XNxp53V36ufZ3FWQAY2bvKKoz9k7db2yS AKSJbZOzzDiudgL.sIz2hYJpOvd_BvisDDE9iv2nujMIpH9zOw287hmfnjxbfdaRkx51ByC_C.ub yeCvL89ZSLZrUxfw_XH8kOXb4JCaZRotBHlUc9lnhIpp8UPm1mAUXiUrN2GZWzEKqwdfuNNQMauS NvGTw0EaTUrwbEXieD3pCFp9Kwpgf7S0nfhN.nC0vI59HMfG.Tu3ya1MnfTbarC77ccM2by6BvB2 ZAHVLhVjEtAaIP9nmD8Vk
Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.ir2.yahoo.com with HTTP; Thu, 24 Sep 2020 09:19:44 +0000
Received: by smtp410.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID cbc29754adee0d58d0f0e5bc2cf23b64; Thu, 24 Sep 2020 09:19:42 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Lloyd W <lloyd.wood@yahoo.co.uk>
Mime-Version: 1.0 (1.0)
Date: Thu, 24 Sep 2020 19:19:39 +1000
Message-Id: <905D4F6F-F19A-4154-BF62-EEEBB1109745@yahoo.co.uk>
References: <34a7886b09d946faa816acbd26700d65@jpl.nasa.gov>
Cc: dtn@ietf.org
In-Reply-To: <34a7886b09d946faa816acbd26700d65@jpl.nasa.gov>
To: "Burleigh, Scott C (US 312B)" <scott.c.burleigh=40jpl.nasa.gov@dmarc.ietf.org>
X-Mailer: iPad Mail (18A373)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/W39NBNNCB2koSTQ23Id7bMa2J_k>
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 09:19:49 -0000

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