Re: [Anima] [Gen-art] Genart last call review of draft-ietf-anima-asa-guidelines-04
Lars Eggert <lars@eggert.org> Thu, 20 January 2022 13:27 UTC
Return-Path: <lars@eggert.org>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 450173A110D; Thu, 20 Jan 2022 05:27:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org
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 g83s5-siL4tJ; Thu, 20 Jan 2022 05:27:01 -0800 (PST)
Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (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 C51A23A110B; Thu, 20 Jan 2022 05:27:00 -0800 (PST)
Received: from smtpclient.apple (unknown [IPv6:2a00:ac00:4000:400:acdb:18e0:9d80:8cc4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 4BD8C1D29C1; Thu, 20 Jan 2022 15:26:50 +0200 (EET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1642685210; bh=kk2417WMUHck1X0vwnM9ZGTT5Zg2IpTVSx1k+FA+63s=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=EZwxU0noqy5fbhkxCpRsiojhFiNJaO157CvF/gaemXCd/xTnWIzS/N9nOhVX1yfU+ ZVhsIB8zLd7D0TN3AUB72uWOoOfOGLNuiN9AtzJQEpi0t7DY4tyi+eFW7HelaRPJh3 RYKdNhf+JvK1JZDzrVOYk7cjK00GFB5jDqtXulEc=
Content-Type: multipart/signed; boundary="Apple-Mail=_70177E3D-D798-4767-874C-44212616D73F"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\))
From: Lars Eggert <lars@eggert.org>
In-Reply-To: <163880271685.2714.12242758600140257355@ietfa.amsl.com>
Date: Thu, 20 Jan 2022 15:26:49 +0200
Cc: gen-art@ietf.org, last-call@ietf.org, draft-ietf-anima-asa-guidelines.all@ietf.org, anima@ietf.org
Message-Id: <AC8DBE1E-AE6F-484F-9F32-1ABC8392EE76@eggert.org>
References: <163880271685.2714.12242758600140257355@ietfa.amsl.com>
To: Thomas Fossati <thomas.fossati@arm.com>
X-MailScanner-ID: 4BD8C1D29C1.A505E
X-MailScanner: Found to be clean
X-MailScanner-From: lars@eggert.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/2cNY3IOQEgTDRK-cMuqVkCJFSC0>
Subject: Re: [Anima] [Gen-art] Genart last call review of draft-ietf-anima-asa-guidelines-04
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Thu, 20 Jan 2022 13:27:06 -0000
Thomas, thank you for your review. I have entered a No Objection ballot for this document. Lars > On 2021-12-6, at 16:58, Thomas Fossati via Datatracker <noreply@ietf.org> wrote: > > Reviewer: Thomas Fossati > Review result: Ready with Issues > > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-anima-asa-guidelines-?? > Reviewer: Thomas Fossati > Review Date: 2021-12-06 > IETF LC End Date: 2021-12-13 > IESG Telechat date: Not scheduled for a telechat > > Summary: > > The document contains guidance for building ASAs. It discusses > different kinds of requirements and their impact on the software > architecture. It looks like an useful doc to have. > > In general, the document reads very well, with the exception of Section > 6 - see "Minor issues" below. > > Major issues: > > Minor issues: > > In Section 6.3, I have followed the reference to > draft-peloso-anima-autonomic-function and I noticed that the content of > Section 6 has been transplanted nearly as-is from there. So, to avoid > redundancy, I wonder whether that content should be given the same > treatment as you do in Section 7 WRT draft-ciavaglia-anima-coordination? > Or maybe you want to re-think the approach and have Section 7 do similar > copy&paste from draft-ciavaglia-anima-coordination? They are both > individual and expired draft after all so it's probably better doing the > latter. > > I also wonder whether it is worth to spell out explicitly the fact that, > given ASAs may need to co-exist with the actual networking application, > they should be build to require minimal memory footprint &, in general, > use system resources with parsimony. A related question is whether ASAs > require dedicated system resources in order to continue operating in a > busy system? > > Nits/editorial comments: > > Section 2. > > * Repeatedly flood an objective to the AN, so that any ASA can > > Expand "AN" on first use. > > These threads should all either exit after their job is done, or > enter a wait state for new work, to avoid blocking others > unnecessarily. > > "blocking others unnecessarily" is not what would typically happen, > maybe "to avoid wasting system resources" ? > > [...] It > should also do whatever is required to avoid unnecessary resource > consumption, such as including an arbitrary wait time in each cycle > of the main loop. > > I am not sure what "arbitrary wait time" refers to? Is it a "sleep(n)" > at the end of each iteration of the main loop? I think it's the > parsimony principle what you want to highlight here, and the first part > of the sentence is sufficient for capturing that without going into > concrete examples. > > Section 3.3 > > This API is intended to support the various interactions expected > between most ASAs, such as the interactions outlined in Section 2. > However, if ASAs require additional communication between themselves, > they can do so using any desired protocol, even just a TLS session if > that meets their needs. One option is to use GRASP discovery and > > What is the meaning of "just" in "just a TLS session"? Also it's not > clear what kind of messages would flow through this additional channel > and if there are any requirements in terms of their security properties. > > [...] As > noted above, the ACP can secure such communications, unless there is > a good reason to do otherwise. > > Maybe s/can/should/ and drop "unless ... otherwise"? > > Section 6.1.1. > > The typography used here to define inputs is a bit odd. And in general > the whole section probably needs some more attention from an editorial > point of view. > > Section 6.2 > > the agent piece of code (when this does not start automatically) and > > Maybe drop "piece of". > > Section 6.2.1 > > The operator's goal can be summarized in an instruction to the ANIMA > ecosystem matching the following format: > > [instances of ASAs of a given type] ready to control > [Instantiation_target_Infrastructure] with > [Instantiation_target_parameters] > > Maybe better to move this at the beginning of Section 6.2.2. > > Section 6.2.3 > > As in Section 6.1.1., the typographic style used here is a bit odd / > unconventional. > > Section 6.3 > > Note: This section is to be further developed in future revisions of > the document, especially the implications on the design of ASAs. > > Is this note still valid? (I hope not :-) ) > > Section 10 > > of robustness that ASA designers should consider > > Maybe stick a colon at the end of the line. > > 1. If despite all precautions, an ASA does encounter a fatal error, > it should in any case restart automatically and try again. To > mitigate a hard loop in case of persistent failure, a suitable > > Terminology: what do you mean by "hard loop"? > > 8. On the other hand, the definitions of GRASP objectives are very > likely to be extended, using the flexibility of CBOR or JSON. > Therefore, ASAs should be able to deal gracefully with unknown > components within the values of objectives. > > Is this in line with Section 6 of draft-iab-protocol-maintenance? > I.e., has GRASP clearly defined extensibility rules, or is this a call > for the ASA implementation to apply the robustness principle? > > At a slightly more general level, ASAs are not services in > themselves, but they automate services. This has a fundamental > impact on how to design robust ASAs. In general, when an ASA > observes a particular state [1] of operations of the services/ > > "[1]" looks like a bib reference, please consider using an alternative > typography, e.g., "(1)", or "A" > > Section 11 > > ASAs are intended to run in an environment that is protected by the > Autonomic Control Plane [RFC8994], admission to which depends on an > initial secure bootstrap process such as [RFC8995]. > > s/such as BRSKI [RFC8995]/ > > In particular, they must use secure techniques and carefully > validate any incoming information. > > "secure techniques" could be unpacked a bit, for example: "secure coding > practices" (e.g., input validation, least privilege, etc.), "secure > configuration practices" (e.g., default deny). > > Appendix C > > An implementation requirement is that resource pools are kept in > stable storage. Otherwise, if a delegator exits for any reason, all > the resources it has obtained or delegated are lost. If an origin > exits, its entire spare pool is lost. The logic for using stable > storage and for crash recovery is not included in the pseudocode > below. > > Is there a further requirement for the storage to be shared across all > ASAs? What I am wondering is whether a shared global map of the current > resource allocations exists to help reconstructing a partitioned > topology (in case one ASA disappears)? Or is the delegated resource > recall, in case the ASA delegator fails, handled by GRASP? > > > > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art
- [Anima] Genart last call review of draft-ietf-ani… Thomas Fossati via Datatracker
- Re: [Anima] Genart last call review of draft-ietf… Brian E Carpenter
- Re: [Anima] [Last-Call] Genart last call review o… Thomas Fossati
- Re: [Anima] [Gen-art] Genart last call review of … Lars Eggert