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