Re: [dtn] WG Review: Delay/Disruption Tolerant Networking (dtn)

Benjamin Kaduk <kaduk@mit.edu> Sun, 21 November 2021 00:16 UTC

Return-Path: <kaduk@mit.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 D818B3A078F; Sat, 20 Nov 2021 16:16:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Level:
X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 qmdUOXF9sy0Q; Sat, 20 Nov 2021 16:16:42 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 F35E53A07DD; Sat, 20 Nov 2021 16:16:41 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 1AL0GUTY031141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 20 Nov 2021 19:16:36 -0500
Date: Sat, 20 Nov 2021 16:16:30 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Lloyd W <lloyd.wood=40yahoo.co.uk@dmarc.ietf.org>
Cc: iesg@ietf.org, dtn@ietf.org
Message-ID: <20211121001630.GV93060@kduck.mit.edu>
References: <163664610187.13531.11845651862423028042@ietfa.amsl.com> <479BE447-59FD-4B3F-BE60-3769518CDB37@yahoo.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <479BE447-59FD-4B3F-BE60-3769518CDB37@yahoo.co.uk>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/9dnKdlDxwB_9kK1ZApns58LBSQ0>
Subject: Re: [dtn] WG Review: Delay/Disruption Tolerant Networking (dtn)
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: Sun, 21 Nov 2021 00:16:47 -0000

Hi Lloyd,

Did you have other potential solutions in mind that you are claiming the WG
should be considering?  Or is this just a general concern that the charter
is too focused on a specific (candidate) solution?
Right now the only thing I can really take away from your comment is that you
don't like it -- I don't have any sense for potential changes that you
think would be improvements (and, more importantly, why you think they
would be improvements), and as such, it's really hard to act on your
comment.

Thanks,

Ben

On Fri, Nov 12, 2021 at 01:35:55PM +1100, Lloyd W wrote:
> The focus on the Bundle Protocol as the only solution for the future of Delay-Tolerant Networking continues imo to be detrimental to advancing Delay-Tolerant Networking as a whole.
> 
> Still, it can be argued that that ship sailed over two decades ago.
> 
> Lloyd Wood
> lloyd.wood@yahoo.co.uk
> 
> rather like IPv6 being the only solution for the future of IP networking. Ship has sailed. 
> 
> > On 12 Nov 2021, at 02:55, The IESG <iesg-secretary@ietf.org> wrote:
> > 
> > The Delay/Disruption Tolerant Networking (dtn) WG in the Transport Area of
> > the IETF is undergoing rechartering. The IESG has not made any determination
> > yet. The following draft charter was submitted, and is provided for
> > informational purposes only. Please send your comments to the IESG mailing
> > list (iesg@ietf.org) by 2021-11-21
> > 
> > Delay/Disruption Tolerant Networking (dtn)
> > -----------------------------------------------------------------------
> > Current status: Active WG
> > 
> > Chairs:
> >  Edward Birrane <edward.birrane@jhuapl.edu>
> >  Rick Taylor <rick@tropicalstormsoftware.com>
> > 
> > Secretaries:
> >  Adam Wiethuechter <adam.wiethuechter@axenterprize.com>
> > 
> > Assigned Area Director:
> >  Zaheduzzaman Sarker <Zaheduzzaman.Sarker@ericsson.com>
> > 
> > Transport Area Directors:
> >  Martin Duke <martin.h.duke@gmail.com>
> >  Zaheduzzaman Sarker <Zaheduzzaman.Sarker@ericsson.com>
> > 
> > Mailing list:
> >  Address: dtn@ietf.org
> >  To subscribe: https://www.ietf.org/mailman/listinfo/dtn
> >  Archive: https://mailarchive.ietf.org/arch/browse/dtn/
> > 
> > Group page: https://datatracker.ietf.org/group/dtn/
> > 
> > Charter: https://datatracker.ietf.org/doc/charter-ietf-dtn/
> > 
> > The Delay/Disruption Tolerant Networking (DTN) Working Group specifies
> > mechanisms for data communications in the presence of long delays and/or
> > intermittent connectivity.  The Working Group has published the Bundle
> > Protocol v7 (BPv7), corresponding Bundle Protocol Security protocol (BPSec)
> > and an interoperable Security Context, and the TCP Convergence Layer
> > specifications as standards track RFCs. Multiple independent implementations
> > exist for these technologies in both space and terrestrial environments, and
> > the technology is now used in production by government and commercial
> > organizations world-wide.
> > 
> > This Working Group now focuses on the further work relevant to the area of
> > Delay/Disruption Tolerant Networking, dividing work items into 3
> > broad categories:
> > 
> > * An architecture for Naming, Addressing and Forwarding
> > 
> >    The Bundle Protocol v7 defines an encoding of Names for use in DTN, but
> >    the detailed semantics have not been specified.  The Working Group will
> >    define a common architecture for the delay/disruption tolerant assignment
> >    of names, and the late-binding of such names during bundle forwarding to
> >    end-points within a DTN.  This architecture will define a standard model
> >    for the forwarding process of a Bundle Process Agent, providing an
> >    informational reference point for further specifications.
> > 
> >    The Working Group charter intentionally excludes topics related to Routing
> >    in DTNs. This does not preclude discussion of the subject, in coordination
> >    with the Routing Area, but no Working Group documents will be adopted
> >    under this charter.
> > 
> > * The definition of architecture and protocols in the areas of Operations,
> > Administration and Management (OAM), and Key Management
> > 
> >    Current DTN deployments rely on the use of pre-placed keys and
> >    configuration or bespoke tooling, and there is a growing demand for
> >    standards to improve the automation and reliability of DTN management.
> >    Existing IETF protocols for OAM and Key Management generally rely on a
> >    bi-directional end-to-end path between devices, and in Delay/Disruption
> >    Tolerant Networks (DTNs) such paths rarely exist.  To enable OAM and Key
> >    Management in such cases, there may be a need to standardize an
> >    architecture supporting alternative methods and their supporting protocols
> >    and data models.  The Working Group will liaise with relevant experts in
> >    the OPS Area to discover if there are existing standards that meet, or may
> >    be extended to meet, the DTN use-cases before standardizing new protocols.
> >    There is also believed to be cross-over between the use-cases for OAM and
> >    Key Management in DTNs and the use-cases in Mobile Ad-hoc Networks
> >    (MANETs); to this end the Working Group will coordinate with the MANET
> >    Working Group to explore potential synergies and avoid duplication of
> >    effort.
> > 
> > * Extensions to and best practices for existing protocols
> > 
> >    Extensions to the Bundle Protocol to enable reliability signalling,
> >    tunnelling and Quality of Service indication are needed for the
> >    operational deployment of Delay/Disruption Tolerant Networks, and these
> >    capabilities will be standardized by the Working Group.
> > 
> >    Additional extensions to the Bundle Protocol, additional Security Context
> >    definitions for BPSec, and new Convergence Layer adaptors will be
> >    considered on a case-by-case basis by the working group.
> > 
> >    The Working Group will also document best practices learned from existing
> >    deployment.
> > 
> > The Working Group will coordinate with other IETF Working Groups, especially
> > in the Security, Routing, Operation and Management Areas, to ensure the
> > quality of peer review, the avoidance of duplication of effort, and alignment
> > with specifications produced in other Working Groups.
> > 
> > =============================================
> > Proposed milestones:
> > 
> > * Naming and Addressing Architecture document
> > * Neighbor/Peer Discovery protocol specification
> > 
> > * Delay-Tolerant Management Architecture and Protocols
> > * Key Management protocol specification
> > 
> > * Bundle progress signalling extension to Bundle Protocol specification
> > * Bundle-in-Bundle Encapsulation extension to Bundle Protocol specification
> > * Quality of Service/Flow indication extension to Bundle Protocol
> > specification
> > 
> > Milestones:
> > 
> > TBD
> > 
> > _______________________________________________
> > dtn mailing list
> > dtn@ietf.org
> > https://www.ietf.org/mailman/listinfo/dtn
>