[Anima] Robert Wilton's No Objection on draft-ietf-anima-autonomic-control-plane-28: (with COMMENT)

Robert Wilton via Datatracker <noreply@ietf.org> Mon, 10 August 2020 18:24 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: anima@ietf.org
Delivered-To: anima@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 660283A09B8; Mon, 10 Aug 2020 11:24:45 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Robert Wilton via Datatracker <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-anima-autonomic-control-plane@ietf.org, anima-chairs@ietf.org, anima@ietf.org, Sheng Jiang <jiangsheng@huawei.com>, jiangsheng@huawei.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.13.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Robert Wilton <rwilton@cisco.com>
Message-ID: <159708388539.28258.3242297268864037873@ietfa.amsl.com>
Date: Mon, 10 Aug 2020 11:24:45 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/5yzXXtR2Nzg1vrzHPGNdee1ZJVM>
Subject: [Anima] Robert Wilton's No Objection on draft-ietf-anima-autonomic-control-plane-28: (with COMMENT)
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Aug 2020 18:24:46 -0000

Robert Wilton has entered the following ballot position for
draft-ietf-anima-autonomic-control-plane-28: 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.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:



I appreciate that this document has already gone through quite a lot of
reviews.  Just a few minor nits (for the version of the doc that was originally
on the telechat before IETF 108):

    6.1.  ACP Domain, Certificate and Network

       This document uses the term ACP in many places where the Autonomic
       Networking reference documents [RFC7575] and
       [I-D.ietf-anima-reference-model] use the word autonomic.  This is
       done because those reference documents consider (only) fully
       autonomic networks and nodes, but support of ACP does not require
       support for other components of autonomic networks except for relying
       on GRASP and providing security and transport for GRASP.  Therefore
       the word autonomic might be misleading to operators interested in
       only the ACP.

Should this paragraph be somewhere earlier in the document?

    6.1.2.  ACP Certificate AcpNodeName

    The acp-node-name is not
    intended for end user consumption, and there is no protection against
    someone not owning a domain name to simpy choose it.

The latter part of this sentence doesn't seem to scan particularly well.  RFC8221 (IPsec/ESP)

    AH MUST NOT be used (because it does not provide confidentiality).

Do you need AH in the terminology or define what it means?

    6.7.4.  ACP via DTLS

       We define the use of ACP via DTLS in the assumption that it is likely
       the first transport encryption supported in some classes of
       constrained devices because DTLS is already used in those devices but
       IPsec is not, and code-space may be limited.

DTLS in the assumption => DTLS, on the assumption
This paragraph could possibly do with a little more wordsmithing.

    6.10.1.  Fundamental Concepts of Autonomic Addressing

For a PE device or NID, how does it know which interfaces to run ACP over?

       o  OAM protocols do not require IPv4: The ACP may carry OAM
          protocols.  All relevant protocols (SNMP, TFTP, SSH, SCP, Radius,
          Diameter, ...) are available in IPv6.  See also [RFC8368] for how
          ACP could be made to interoperate with IPv4 only OAM.

Should this include a YANG management protocol like NETCONF?
Radius => RADIUS (in a few places)  Unknown Destinations

       As this requirement raises additional Data-Plane, it does not apply
       to nodes where the administrative parameter to become root
       (Section can always only be 0b001, e.g.: the node does not
       support explicit configuration to be root, or to be ACP registrar or
       to have ACP-connect functionality.

The first sentence doesn't quite scan.

retrieved bei neighboring nodes =>  retrieved by neighboring nodes
"serialNumber" contains usually => "serialNumber" usually contains
remotely sent IPv6 link-local => remotely send IPv6 link-local