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

Toerless Eckert <> Fri, 11 September 2020 13:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 244113A0D60; Fri, 11 Sep 2020 06:08:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.616
X-Spam-Status: No, score=0.616 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KGGLXHLauCKe; Fri, 11 Sep 2020 06:08:53 -0700 (PDT)
Received: from ( [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C526A3A0E06; Fri, 11 Sep 2020 06:08:52 -0700 (PDT)
Received: from ( [IPv6:2001:638:a000:4134::ffff:52]) by (Postfix) with ESMTP id D381354862A; Fri, 11 Sep 2020 15:00:36 +0200 (CEST)
Received: by (Postfix, from userid 10463) id D12B4440059; Fri, 11 Sep 2020 15:00:36 +0200 (CEST)
Date: Fri, 11 Sep 2020 15:00:36 +0200
From: Toerless Eckert <>
To: Robert Wilton <>
Cc: The IESG <>,,,, Sheng Jiang <>
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <>
Subject: Re: [Anima] Robert Wilton's No Objection on draft-ietf-anima-autonomic-control-plane-28: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 11 Sep 2020 13:09:07 -0000

Thanks, Robert

Listing all diffs just in case and so i don't have to create separate mail headers ;-)
replies to discuss/comments after diff URLs.


Full diff -28 to current -29 version:

(this includes conversion XMLv2->v3 and addition of contributor section).

Diff for Roman Danyliw discuss/comments reply:

Diff for Ben Kaduk discuss/comments reply:

Diff for Barry Leiba discuss/comments reply:

Diff for Erik Kline discuss/comments reply:

Diff for Robert Wilton comments reply:

On Mon, Aug 10, 2020 at 11:24:45AM -0700, Robert Wilton via Datatracker wrote:
> 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
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Hi,
> 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?

Good question:

The ACP spec serves to answer part of the Autonomic Network architecture
from NMRG and the reference model yet the terminology in this doc is
eliminating "autonomous". This and the following paragraph are create
the linkage between the larger architecture and original reason for the
ACP and the broader applicability of the spec.

yada yada... i feel it is appropriate to be at the top of the normative text
because of this linkage. And broader applicability beyond them.

>     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.

Changed to:

The acp-node-name is not intended for end user consumption. There is no protection against an operator to pick any domain name for an ACP whether or not the operator can claim to own the domain name. Instead, the domain name only serves
>  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?

The folks on made it sound as if AH was Voldemort
 - the less you mention about it, the better. So i just expanded the word inline:

The IP Authentication Header (AH) MUST NOT be used

>     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.

          <t>This document defines the use of ACP via DTLS, on the assumption that it is likely the first transport encryption supported in some classes of constrained devices: DTLS is commonly used in constrained devices when IPsec is not. Code-space on those devices may be also be too limited to support more than the minimum number of required protocols.</t>

>     6.10.1.  Fundamental Concepts of Autonomic Addressing
> For a PE device or NID, how does it know which interfaces to run ACP over?

See discussion in thread.

>        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.

Fixed by reply to another reviewers nit.

> Nits:
> retrieved bei neighboring nodes =>  retrieved by neighboring nodes


> "serialNumber" contains usually => "serialNumber" usually contains


> remotely sent IPv6 link-local => remotely send IPv6 link-local