[dtn] Benjamin Kaduk's No Objection on charter-ietf-dtn-01-02: (with COMMENT)

Benjamin Kaduk via Datatracker <noreply@ietf.org> Thu, 02 December 2021 05:26 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: dtn@ietf.org
Delivered-To: dtn@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 292833A0A46; Wed, 1 Dec 2021 21:26:42 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: dtn-chairs@ietf.org, dtn@ietf.org, Fred.L.Templin@boeing.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.40.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <163842280128.17651.14580462213654503237@ietfa.amsl.com>
Date: Wed, 01 Dec 2021 21:26:42 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/oAlQNQ66Ras9bC3iQUYbmaONRKY>
Subject: [dtn] Benjamin Kaduk's No Objection on charter-ietf-dtn-01-02: (with COMMENT)
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.29
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, 02 Dec 2021 05:26:42 -0000

Benjamin Kaduk has entered the following ballot position for
charter-ietf-dtn-01-02: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-dtn/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

    This architecture will define a standard model
    for the forwarding process of a Bundle Process Agent, providing an
    informational reference point for further specifications.

There seems to be some mismatch between "standard model" and
"informational reference point".  If it's not intended to be in a
standards-track document, perhaps "reference model" would avoid the
difficulty?

  * The definition of architecture and protocols in the areas of Operations,
  Administration and Management (OAM), and Key Management

(nit) I think "an architecture" is needed here.

    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.

Can we say anything about what factors will go into these considerations
(other than, presumably, WG interest)?  Will the reponsible AD need to
be involved in the decision to undertake such work?