Skip to main content

Guidelines for Autonomic Service Agents
draft-ietf-anima-asa-guidelines-07

Revision differences

Document history

Date Rev. By Action
2022-03-28
07 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2022-03-22
07 (System) RFC Editor state changed to AUTH48
2022-02-24
07 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2022-02-21
07 Bernie Volz Closed request for Telechat review by INTDIR with state 'Overtaken by Events'
2022-02-17
07 Tero Kivinen Closed request for Last Call review by SECDIR with state 'Overtaken by Events'
2022-02-17
07 Tero Kivinen Assignment of request for Last Call review by SECDIR to Mališa Vučinić was marked no-response
2022-02-07
07 (System) RFC Editor state changed to EDIT
2022-02-07
07 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2022-02-07
07 (System) Announcement was received by RFC Editor
2022-02-07
07 (System) IANA Action state changed to No IANA Actions from In Progress
2022-02-07
07 (System) IANA Action state changed to In Progress
2022-02-07
07 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2022-02-07
07 Amy Vezza IESG has approved the document
2022-02-07
07 Amy Vezza Closed "Approve" ballot
2022-02-07
07 (System) Removed all action holders (IESG state changed)
2022-02-07
07 Robert Wilton IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2022-02-07
07 Robert Wilton Ballot approval text was generated
2022-02-01
07 Brian Carpenter New version available: draft-ietf-anima-asa-guidelines-07.txt
2022-02-01
07 (System) New version accepted (logged-in submitter: Brian Carpenter)
2022-02-01
07 Brian Carpenter Uploaded new revision
2022-01-27
06 Roman Danyliw
[Ballot comment]
Thank you for addressing my DISCUSS and COMMENTs

==[ Remaining comment discussed on list.  Only minimally required primitives will be documented.

** Section …
[Ballot comment]
Thank you for addressing my DISCUSS and COMMENTs

==[ Remaining comment discussed on list.  Only minimally required primitives will be documented.

** Section 6.1.1
  A minimum set of primitives to
  support the installation of ASAs could be: install(list of ASAs,
  Installation_target_Infrastructure, ASA placement function), and
  uninstall (list of ASAs).

Would an explicit primitive for checking if an ASA is already installed be needed – that is, how does one deal with an install() if the ASA is already installed?
2022-01-27
06 Roman Danyliw [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss
2022-01-26
06 Benjamin Kaduk
[Ballot comment]
Thanks for the updates in the -06; by and large they look good
(especially the resolution to my Discuss).

I may still have …
[Ballot comment]
Thanks for the updates in the -06; by and large they look good
(especially the resolution to my Discuss).

I may still have some lingering confusion about Installation Hosts,
though -- in Section 6.1.1 we write:

  *  [ASA_placement_function] specifies how the installation phase will
      meet the operator's needs and objectives for the provision of the
      infrastructure.  This function is only useful in the decoupled
      mode.  It can be as simple as an explicit list of Installation
      Hosts, or it could consist of operator-defined criteria and
      constraints.

But I think, in light of the context in which this appears, it would
make more sense to say "can be as simple as an explicit list of hosts
on which the ASAs are to be installed" (or perhaps a variant that uses
the "[List_of_hosts]" spelling of the following paragraph).
On the other hand, I could just be suffering from having previously confused myself
by reading the -05, and maybe this is actually fine for someone reading
it for the first time.
2022-01-26
06 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss
2022-01-26
06 (System) Changed action holders to Robert Wilton (IESG state changed)
2022-01-26
06 (System) Sub state has been changed to AD Followup from Revised ID Needed
2022-01-26
06 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2022-01-26
06 Brian Carpenter New version available: draft-ietf-anima-asa-guidelines-06.txt
2022-01-26
06 (System) New version accepted (logged-in submitter: Brian Carpenter)
2022-01-26
06 Brian Carpenter Uploaded new revision
2022-01-21
05 Benno Overeinder Request for Telechat review by INTDIR Completed: Ready with Nits. Reviewer: Benno Overeinder. Sent review to list.
2022-01-20
05 (System) Changed action holders to Brian Carpenter, Sheng Jiang, Laurent Ciavaglia, Robert Wilton, Peloso Pierre (IESG state changed)
2022-01-20
05 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2022-01-20
05 Lars Eggert
[Ballot comment]
Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term "traditional"; alternatives might be "classic", "classical", …
[Ballot comment]
Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term "traditional"; alternatives might be "classic", "classical",
  "common", "conventional", "customary", "fixed", "habitual", "historic",
  "long-established", "popular", "prescribed", "regular", "rooted",
  "time-honored", "universal", "widely used", "widespread".

Thanks to Thomas Fossati for their General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/ohsgWQpj39CLR4OuF6XAWQGpGpA).

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 3.4. , paragraph 3, nit:
> iques such as network function virtualization or network slicing, there will
>                                ^^^^^^^^^^^^^^
Do not mix variants of the same word ("virtualization" and "virtualisation")
within a single text.

Section 6.2. , paragraph 2, nit:
>  explained in detail in the next sub-section: [instances of ASAs of a given
>                                  ^^^^^^^^^^^
This word is normally spelled as one.

Section 6.3. , paragraph 5, nit:
> del; as noted in Section 5, YANG serialized as CBOR may be used directly as
>                                  ^^^^^^^^^^
Do not mix variants of the same word ("serialize" and "serialise") within a
single text.

Section 12.2. , paragraph 4, nit:
> nda, P., and P. Lynch, "Network Virtualization Research Challenges", RFC 8568
>                                ^^^^^^^^^^^^^^
Do not mix variants of the same word ("virtualization" and "virtualisation")
within a single text.

Section 12.2. , paragraph 14, nit:
> ix B. Terminology This appendix summarises various acronyms and terminology
>                                ^^^^^^^^^^
Do not mix variants of the same word ("summarise" and "summarize") within a
single text.

Document references draft-ietf-core-yang-cbor-17, but -18 is the latest
available revision.

These URLs in the document can probably be converted to HTTPS:
* http://www.etsi.org/deliver/etsi_gs/AFI/001_099/002/01.01.01_60/gs_afi002v010101p.pdf
2022-01-20
05 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert
2022-01-20
05 Murray Kucherawy
[Ballot comment]
Thank you to Martin Dürst for the ARTART review.

"Autonomic domain" is defined in the Appendix B, but doesn't appear in the document …
[Ballot comment]
Thank you to Martin Dürst for the ARTART review.

"Autonomic domain" is defined in the Appendix B, but doesn't appear in the document body.  Could it be removed?

Apart from that, nothing to add that my colleagues haven't already said.
2022-01-20
05 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2022-01-19
05 Benjamin Kaduk
[Ballot discuss]
It looks like the indentation in the example MAIN PROGRAM in Appendix C
is incorrect, or at least confusing, in the "do forever" …
[Ballot discuss]
It looks like the indentation in the example MAIN PROGRAM in Appendix C
is incorrect, or at least confusing, in the "do forever" loop therein.
Specifically, assuming semantic whitespace as in Python, we never
actually perform grasp negotiation for the "good_peer in peers" case.
Additionally, I think we may have a risk of getting stuck in a loop
making no progress so long as good_peer remains in the set of discovered
peers but does not have enough resources available for our
request/negotiation to succeed.  I think we want to clear out good_peer
if a negotiation fails, to avoid that scenario.
2022-01-19
05 Benjamin Kaduk Ballot discuss text updated for Benjamin Kaduk
2022-01-19
05 Benjamin Kaduk
[Ballot discuss]
It looks like the indentation in the example MAIN PROGRAM in Appendix C
is incorrect, or at least confusing, in the "do forever" …
[Ballot discuss]
It looks like the indentation in the example MAIN PROGRAM in Appendix C
is incorrect, or at least confusing, in the "do forever" loop therein.
Specifically, assuming semantic whitespace as in Python, we never
actually perform grasp negotiation for the "good_peer in peers" case.
Additionally, I think we may have a risk of getting stuck in a loop
making no progress so long as good_peer remains in the set of discovered
peers but does not have enough resources available for our
request/negotiation to succeed.  I think we want to clear out good_peer
if a negotiation fails to avoid that scenario.
2022-01-19
05 Benjamin Kaduk
[Ballot comment]
Section 1

  management services to network operators and administrators.  For
  example, the services envisaged for network function virtualisation
  [RFC8568 …
[Ballot comment]
Section 1

  management services to network operators and administrators.  For
  example, the services envisaged for network function virtualisation
  [RFC8568] or for service function chaining [RFC7665] might be managed
  by an ASA rather than by traditional configuration tools.

RFC 8568 is an IRTF document on "Network Virtualization Research
Challenges"; is that really the best reference for this concept?
I note that RFC 8014 exists (IETF, Informational) on "An Architecture
for Data-Center Network Virtualization over Layer 3 (NVO3)", which
admittedly is not exactly the same thing, but might still be suitable.

Section 2

  A typical ASA will have a main thread that performs various initial
  housekeeping actions such as:
  [...]
  *  Define data structures for relevant GRASP objectives.

I may just be confused, but wouldn't defining a GRASP objective/data
structure mapping be a matter of protocol design, not something that
requires ongoing activity in a housekeeping or startup thread of a
running ASA?  If the intent was just that the values in a predetermined
data structure template should be populated at this step, I would be
much less confused.

  *  Obtain authorization credentials, if needed.

In a non-autonomic context, I would say that getting credentials needs
to be a periodic task, not something done once on startup and retained
indefinitely.  It seems that in the ASA context, the situation may be
difference, since the authorization credentials in question are likely
to be (or be derived from) the device's LDevID, which might reasonbly
have a very long lifetime.  On the other hand, there might also be
scenarios where LDevID lifetime is short-lived and certificate renewal
occurs often, so that the ASA would benefit from having credential
management be a periodic task.  Do you think it's better to list this
item in the initial housekeeping or in the main loop tasks?

Section 3.3

  Section 2.  However, if ASAs require additional communication between
  themselves, they can do so using any desired protocol, such as a TLS
  session over the ACP if that meets their needs.  One option is to use
  GRASP discovery and synchronization as a rendez-vous mechanism
  between two ASAs, passing communication parameters such as a TCP port
  number via GRASP.  As noted above, the ACP should be used to secure
  such communications.

I agree that there is earlier text suggesting that the ACP should be
used for normal inter-ASA communications.  I'm commenting here
specifically on the phrase "used to secure such communications".  If the
ACP is providing secure communications, then why would there be a need
to use an additional TLS session on top of it (which is specifically
called out as an option in the quoted text)?  It seems that there is
some additional subtlety here, in that the ACP provides some baseline
security property of "the communications peer belongs to the ACP" but
that in some cases there is a need for additional protection such that
the data being exchanged is visible only to the two communicating
endpoints in the ACP and not to any intermediate ACP nodes that it
traverses.
That's a long bit of discussion to just suggest s/used to secure/used
for/, but I think it's important to treat use of the word "secure"
carefully, as it can be interpreted in many different ways by different
readers when used without further qualification.

Section 4

  For example, if such management is performed by NETCONF [RFC6241],
  the ASA must interact with the NETCONF server as an independent
  NETCONF client in the same node to avoid any inconsistency between
  configuration changes delivered via NETCONF and configuration changes
  made by the ASA.

I will, of course, defer to my ops&mgmt colleagues on this, but my
understanding was that the NMDA allowed for changes made "out of band"
from the normal management protocol and that NETCONF clients were
expected to be able to cope with that.  If my understanding is correct,
that would suggest a slight rephrasing to something like "would
typically interact", rather than "must interact".

Section 3.1, 3.2

  Note that the [...] process itself may include special-
  purpose ASAs that run in a constrained insecure mode.

In light of the other discussion on this phrase, I submit "run in a
restricted mode in an insecure network setting" for consideration as a
possible alternative.

Section 5

  A mapping from YANG to CBOR is defined by [I-D.ietf-core-yang-cbor].
  Subject to the size limit defined for GRASP messages, nothing
  prevents objectives using YANG in this way.

I would suggest mentioning the YANG data structure extension of RFC 8791
in this context of using YANG to define data structures that are
divorced frrom configuration or operational state.

Section 6.1

                                              The provisioning of the
  infrastructure is realized in the installation phase and consists in
  installing (or checking the availability of) the pieces of software
  of the different ASAs in a set of Installation Hosts.  Installation
  Hosts may be nodes of an autonomic network, or servers dedicated to
  storing the software images of the different ASAs.

I'm a bit confused about whether the Installation Host is the target of
the installation operation (i.e., the software is installed on this host
and will/might eventually run there) or functions more as a software
repository, from which the software will be fetched prior to running on
some other node.  The phrases "servers dedicated to storing the software
images" and "checking the availability of" suggest the latter, but down
in §6.1.1 we tak of a list of ASAs installed on "[list of Installation
Hosts]" and even here we talk of "installing ... software ... in a set
of Installation Hosts".  It would be good to clarify which of these
roles are intended (or that both distinct roles are covered).

Section 7.1

  necessary.  This issue is considered in detail in
  [I-D.ciavaglia-anima-coordination].

The referenced draft expired in 2016 and contains a disclaimer that [the
latest version] "has been issued to reactivate the document in order to
allow discussion within the ANIMA WG about the coordination of autonomic
functions", which does not exactly send a strong signal that that
document is a definitive source of information on this topic.

Section 7.2

                          Each ASA designer will need to consider this
  issue and how to avoid clashes and inconsistencies.  [...]

Is an ASA designer even expected to be in a position to know what other
configuration/management tools/mechanisms the ASA might be competing
with?

Section 8

  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.  The specification
        of an objective should describe how unknown components are to be
        handled (ignored, logged and ignored, or rejected as an error).

Do we want to encourage specifications of objectives to also describe
ways in which extension are envisioned (which should not necessarily be
taken as excluding other potential extension points)?

Section 9

Do we want to mention again the lack of transactional integrity in GRASP
(mentioned previously in §5)?

  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 BRSKI [RFC8995].  [...]

Perhaps banal, but I'd suggest including some explicit statement of
"those documents describe security considerations relating to the use of
and properties provided by the ACP and BRSKI, respectively" as a trigger
to actually read them, vs just noting their existence.

It may also be prudent to reference the GRASP security considerations.

                                  Thus, ASAs must be designed to avoid
  loopholes such as passing on executable code, and should if possible
  operate in an unprivileged mode.  [...]

I would add "or proxying unverified commands" to "such as passing on
executable code", since that seems more likely to me than literally
sending around executable binaries and running them".

  A similar situation will arise if an ASA acts as a gateway between
  two separate autonomic networks, i.e. it has access to two separate
  ACPs.  Such an ASA must also be designed to avoid loopholes and to
  validate incoming information from both sides.

This makes me think of the phrasing "the ASA must act as a trust
boundary between the distinct ACPs", a phrasing which might also be put
to use in the previous discussion of loophole avoidance as well.

  The initial version of the autonomic infrastructure assumes that all
  autonomic nodes are trusted by virtue of their admission to the ACP.
  ASAs are therefore trusted to manipulate any GRASP objective, simply
  because they are installed on a node that has successfully joined the
  ACP.  [...]

Thanks for stating this clearly; I think it's valuable to reiterate it
in this context.  Would this be an appropriate place to discuss how this
"trusted by virtue of ACP membership" relates (or doesn't relate) to the
notion of "unprivileged mode" or "without special privilege" that's
mentioned in a couple places earlier in the document?

Section 12.2

Google appeared to find me http://ceur-ws.org/Vol-204/P07.pdf when I
started searching from what's listed for [DeMola06].

Appendix C

In the NEGOTIATOR thread, do we need to return A to the resource_pool if
the negotiation failed?

NITS

Abstract

We definitely want to keep the "so-called" in "so-called autonomic
networking"?  It looks really odd to me, but I have no horse in this
race.

Section 1

  this way.  This document mainly addresses issues affecting quite
  complex ASAs, but the most useful ones may in fact be rather simple
  developments from existing scripts.

I think the intent here is that the most useful ASAs might just be simple
evolutions/conversions of existing scripts into simple ASAs, but the
current text doesn't convey that sense very well.  "the most useful
ones" might formally bind more tightly to 'issues' than 'ASAs', and I
think a different word than "developments" would be better.

Section 2

  According to the degree of parallelism needed by the application,
  some of these threads might be launched in multiple instances.  In
  particular, if negotiation sessions with other ASAs are expected to
  be long or to involve wait states, the ASA designer might allow for
  multiple simultaneous negotiating threads, with appropriate use of
  queues and locks to maintain consistency.

I think there are synchronization primitives usable in this scenario
that don't technically involve locks, so s/locks/synchronization
primitives/ might be more pedantically correct.  I am not taking the
stance that pedantic correctness should trump readability, though.

Section 5

  acceptable by the GRASP API will limit the options in practice.  A
  generic solution is for the API to accept and deliver the value field
  in raw CBOR, with the ASA itself encoding and decoding it via a CBOR
  library.

I would suggest "in encoded binary form", to avoid an implication that
the API is going to check that there is a valid CBOR structure being
provided.

  GRASP maximum message size.  If the default maximum size specified by
  [RFC8990] is not enough, the specification of the objective must

It might help the reader if we write out GRASP_DEF_MAX_SIZE (assuming
that is actually the intended limit).

Section 6.1

  *  The decoupling property allows controlling resources of an
      autonomic node from a remote ASA, i.e. an ASA installed on a host
      machine different from the autonomic node resources.

There seems to be a missing possessive or word order issue here; maybe
"different from the autonomic node whose resources are being
controlled"?

Section 6.1.1

  *  [ASA placement function] specifies how the installation phase will
      meet the operator's needs and objectives for the provision of the
      infrastructure.  This function is only required in the decoupled
      mode.  [...]

I wonder if it's more clear to say that this function "is the identity
function" or "just returns the list of candidate Installation Hosts"
when decoupled mode is not in use.

  The condition to validate in order to pass to next phase is to ensure
  that [list of ASAs] are well installed on [list of Installation

I think there was an exchange with a previous reviewer that proposed
just removing "well" here; I would counter with a proposal to use
"properly", "completely", or "successfully" instead -- the previous
paragraph already determined that the ASAs in question are "installed
on" the list of installation hosts.

Section 6.2.2

  *  [Set of ASAs - Resources relations] describing which resources are
      managed by which ASA instances, this is not a formal message, but
      a resulting configuration of a set of ASAs.

Comma splice (first comma).
2022-01-19
05 Benjamin Kaduk [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk
2022-01-19
05 Francesca Palombini
[Ballot comment]
Thank you for the work on this document.

Many thanks to Martin Dürst for the ART ART review: https://mailarchive.ietf.org/arch/msg/anima/Qs2CgHSHTiKQwsqob4K_qP3ENw8/, and thank you …
[Ballot comment]
Thank you for the work on this document.

Many thanks to Martin Dürst for the ART ART review: https://mailarchive.ietf.org/arch/msg/anima/Qs2CgHSHTiKQwsqob4K_qP3ENw8/, and thank you to the authors for addressing Martin's comments.

Francesca
2022-01-19
05 Francesca Palombini [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini
2022-01-18
05 Roman Danyliw
[Ballot discuss]
** Section 3.1 and 3.2.

(a) (Section 3.1) “… the secure bootstrap process itself may include special-purpose ASAs that run in a constrained …
[Ballot discuss]
** Section 3.1 and 3.2.

(a) (Section 3.1) “… the secure bootstrap process itself may include special-purpose ASAs that run in a constrained insecure mode.”,

(b) (Section 3.2) “ … the ACP formation process itself may include special-purpose ASAs that run in a constrained insecure mode.”

What is meant by “special-purpose” (i.e., how is that different than an ASA that isn’t special purpose) and what are the security properties of a “constrained insecure mode”?  Is this text saying that the secure bootstrapping and ACP formation might not always be done securely?

(b) reads like it could be DULL-GRAP (Section 2.5.2 of draft-ietf-anima-grasp) but it isn’t clear.
2022-01-18
05 Roman Danyliw
[Ballot comment]
** Section 6.  Would the ASA lifecycle presented here need to consider resale, transfer or decommissioning of equipment on which the ASA runs?  …
[Ballot comment]
** Section 6.  Would the ASA lifecycle presented here need to consider resale, transfer or decommissioning of equipment on which the ASA runs?  I’m specifically thinking of the broader considerations discussed in BRSKI.  For example, should there be primitives to purge the ASA configuration, key materials, or logs?

** Section 6.1.  Is there any integrity and authenticity checking before the ASA software is installed?

** Section 6.1.1.
The condition to validate in order to pass to next phase is to ensure
  that [list of ASAs] are well installed on [list of Installation
  Hosts].

What does it mean to be “well installed”?

** Section 6.1.1
  A minimum set of primitives to
  support the installation of ASAs could be: install(list of ASAs,
  Installation_target_Infrastructure, ASA placement function), and
  uninstall (list of ASAs).

Would an explicit primitive for checking if an ASA is already installed be needed – that is, how does one deal with an install() if the ASA is already installed?

** Section 6.2.
  First, there is a difference between (1) having a
  piece of code available to run on a host and (2) having an agent
  based on this piece of code running inside the host. 

I don’t follow the text for (1).  (1) seems to be roughly the definition of the previously described installation phase (Section 6.1).  What is the difference being suggested for this phase?

** -- Section 6.2.3.
The specification of such an
  ASA Instance Mandate is beyond the scope of this document.

It caught my attention that the specification of “ASA Instance Mandate” was explicitly called out as being out of scope for this document.  No issue with that.  However, so many of the other terms are also out of scope.  For example, “Set of ASAs – Resources relations” and “Instantiation_target_parameters”

** Section 8. 
  If a newly received or calculated value for a parameter falls
  out of bounds, the corresponding parameter should be either left
  unchanged or restored to a safe value.

Is that safe value likely to be contextual to the environment in which the ASA is deployed?

** Editorial

-- Section 6.1.1.  Editorial.  Why does “[Installation_target_Infrastructure] have both hyphens and capitalizes “Infrastructure” while “[ASA of a give type” and [ASA placement function] doesn’t have hyphens and only capitalized the first word?

-- Section 6.1.1.  Editorial. A forward reference or earlier definition of “decoupled mode” would have been helpful.  It is defined in Section 6.2.
2022-01-18
05 Roman Danyliw [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw
2022-01-18
05 Martin Duke
[Ballot comment]
No need to respond to this, whether or not you like the suggestion:

In Sec. 2, the statement "Autonomic service agents must never …
[Ballot comment]
No need to respond to this, whether or not you like the suggestion:

In Sec. 2, the statement "Autonomic service agents must never fail" is jarring, and comes across as wishful thinking. The rest of the document, especially Sec. 8  explains things well. However, changing this to something like "Failure of a service agent would likely have severe consequences" might be more descriptive.
2022-01-18
05 Martin Duke [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke
2022-01-18
05 Éric Vyncke
[Ballot comment]

Thank you for the work put into this document. I find it quite exhaustive and well explained.

Please find below some non-blocking COMMENT …
[Ballot comment]

Thank you for the work put into this document. I find it quite exhaustive and well explained.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education -- and after writing them, I spotted that some of them are overlapping with Warren Kumari's ballot), and some nits.

Special thanks to Toerless Eckert for the shepherd's write-up including the section about the WG consensus.

I hope that this helps to improve the document,

Regards,

-éric

-- Section 1 --
Should "ANIMA" be expanded at first use ? Or should it be replaced by "ANIMA WG" ?

In "The net result should be significant improvement of operational metrics" is the concept of "operational metrics" well understood by the readers ? Why not simply "operational cost" ?

-- Section 3.1 and 3.2 --
Their last paragraphs would benefit if there were some explanations about their assertions.

-- Section 3.3 --
There are some repetitions around the data structures used by ASA but this is OK.

I am more concerned by the implicit model used by the document with kernel/user space as well as the multi-threaded loop. While I understand that this is of course quite common for generic computers (and possibly high end devices), what about constrained devices ? I must admit that I am venturing outside of my comfort zone here...

-- Section 4 --
In "whether ASAs are deployed once per physical node or once per virtual context", isn't this part more generic ? I.e., should it be stated outside of section 4 ?

-- Section 5 --
Interesting and useful section but I wonder whether it fits a document about ASA.

-- Section 6 --
The way I am reading the section is that the life cycle only considers a monolithic piece of software. Should there be a mention about partial (e.g., just a library) update ?

Should there be any linkage with SUIT WG ?

-- Section 8 --
Should the periodic retry include a random portion ?

== NITS ==

-- Section 4 --
I found that 2 consecutive sentences starting with "An ASA whose purpose is to manage" are weird.
2022-01-18
05 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2022-01-18
05 Zaheduzzaman Sarker [Ballot comment]
I didn't find any transport related issues in this specification, Thanks for the well written document.It was easy to follow with those appendixes.
2022-01-18
05 Zaheduzzaman Sarker [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker
2022-01-17
05 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2022-01-17
05 John Scudder
[Ballot comment]
Thanks for this document, which was overall informative and easy to read. I do have a couple small comments.

1. While most terminology …
[Ballot comment]
Thanks for this document, which was overall informative and easy to read. I do have a couple small comments.

1. While most terminology is clearly defined, I didn’t find any definition of “the decoupled mode” first referred to in §6.1.1. It’s possible to infer what’s meant from context, after reading a bit more, but this was a speed bump in an otherwise smooth ride. “Decoupled” and “coupled” occur several places thereafter. I did go and check the normative references, and AFAICT none of them define the term either.

2. Also in §6.1.1, you mention ensuring that ASAs are “well installed”. This suggests to the reader that ASAs might also be “poorly installed” and that the installation phase might somehow return that status as well, which seems dubious. My guess is that “well” could simply be dropped?
2022-01-17
05 John Scudder [Ballot Position Update] New position, No Objection, has been recorded for John Scudder
2022-01-17
05 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2022-01-17
05 Warren Kumari
[Ballot comment]
Firstly, thanks to Menachem Dodge for the OpsDir review: https://datatracker.ietf.org/doc/review-ietf-anima-asa-guidelines-04-opsdir-lc-dodge-2021-12-13/ - they are always helpful.

Also, thanks to the authors and WG for …
[Ballot comment]
Firstly, thanks to Menachem Dodge for the OpsDir review: https://datatracker.ietf.org/doc/review-ietf-anima-asa-guidelines-04-opsdir-lc-dodge-2021-12-13/ - they are always helpful.

Also, thanks to the authors and WG for such a clear and readable document.

I do have a few (non-blocking) comments:
Introduction:
O: "The net result should be significant improvement of operational metrics."
P: "The net result should be significant improvement *in* operational metrics."
C: I suspect that my proposed change doesn't actually fix my concern :-) To me, the original wording makes it sound like the result is an improvement in the metrics *themselves*, not what the metrics are reporting / representing. Perhaps something like "The net result should be significant improvement in operational performance" would be better? It's also entirely possible that it was just that it's just me, so...


O: "In this document, we use an explicit multi-threading model to describe operations."
C: I think that adding something along the lines of "This is done to illustrate the concepts; implementations are free to use whatever features and methods achieve the results" or similar. Perhaps something like this could actually be added to the previous sentence ("Different programming environments support asynchronicity in different ways.")? I've often seen implementers look at the pseudo-code / requirements, and then just start coding from that, without stopping to consider if their tooling provides features / paradigms that do accomplish the same thing, but better (e.g complex even driven systems when goroutines / channels would be more idiomatic).

O: "5.  Design of GRASP Objectives"
C: This is sort of a meta comment (/potentially a larger topic) -- the title of the document is: "Guidelines for Autonomic Service Agents", and the abstract says "This document proposes guidelines for the design of Autonomic Service Agents for autonomic networks." But, much of the content (including this section) feels like it isn't *really* about the design of the ASA, but more of general guidelines for AN / GRAPS / etc.
I fully agree that it is useful content, but perhaps the title of the document should be changed, or the non-ASA guidelines bits could all just be put in a new document?). Note that, as with all of my comments, this is just a comment / thought / suggestion (I won't be sad / offended if you disagree / reject it)

Thanks again,
W
2022-01-17
05 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2022-01-17
05 David Lamparter Assignment of request for Telechat review by INTDIR to David Lamparter was rejected
2022-01-11
05 Bernie Volz Request for Telechat review by INTDIR is assigned to Benno Overeinder
2022-01-11
05 Bernie Volz Request for Telechat review by INTDIR is assigned to Benno Overeinder
2022-01-11
05 Bernie Volz Request for Telechat review by INTDIR is assigned to David Lamparter
2022-01-11
05 Bernie Volz Request for Telechat review by INTDIR is assigned to David Lamparter
2022-01-10
05 Éric Vyncke Requested Telechat review by INTDIR
2022-01-10
05 Amanda Baber IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2022-01-10
05 Éric Vyncke Requested Telechat review by INTDIR
2022-01-07
05 Amy Vezza Placed on agenda for telechat - 2022-01-20
2022-01-07
05 Robert Wilton Ballot has been issued
2022-01-07
05 Robert Wilton [Ballot Position Update] New position, Yes, has been recorded for Robert Wilton
2022-01-07
05 Robert Wilton Created "Approve" ballot
2022-01-07
05 Robert Wilton IESG state changed to IESG Evaluation from Waiting for Writeup
2022-01-07
05 Robert Wilton Ballot writeup was changed
2021-12-19
05 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2021-12-19
05 Brian Carpenter New version available: draft-ietf-anima-asa-guidelines-05.txt
2021-12-19
05 (System) New version accepted (logged-in submitter: Brian Carpenter)
2021-12-19
05 Brian Carpenter Uploaded new revision
2021-12-13
04 Martin Dürst Request for Last Call review by ARTART Completed: Ready with Issues. Reviewer: Martin Dürst. Sent review to list.
2021-12-13
04 (System) IESG state changed to Waiting for Writeup from In Last Call
2021-12-13
04 Menachem Dodge Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Menachem Dodge. Sent review to list.
2021-12-06
04 Thomas Fossati Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Thomas Fossati. Sent review to list.
2021-12-06
04 Magnus Westerlund Closed request for Last Call review by TSVART with state 'Team Will not Review Document'
2021-12-06
04 Tommy Pauly Assignment of request for Last Call review by TSVART to Tommy Pauly was rejected
2021-12-06
04 Magnus Westerlund Request for Last Call review by TSVART is assigned to Tommy Pauly
2021-12-06
04 Magnus Westerlund Request for Last Call review by TSVART is assigned to Tommy Pauly
2021-12-03
04 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2021-12-03
04 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-anima-asa-guidelines-04, which is currently in Last Call, and has the following comments:

We …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-anima-asa-guidelines-04, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist
2021-12-02
04 Tero Kivinen Request for Last Call review by SECDIR is assigned to Mališa Vučinić
2021-12-02
04 Tero Kivinen Request for Last Call review by SECDIR is assigned to Mališa Vučinić
2021-12-02
04 Jean Mahoney Request for Last Call review by GENART is assigned to Thomas Fossati
2021-12-02
04 Jean Mahoney Request for Last Call review by GENART is assigned to Thomas Fossati
2021-12-01
04 Barry Leiba Request for Last Call review by ARTART is assigned to Martin Dürst
2021-12-01
04 Barry Leiba Request for Last Call review by ARTART is assigned to Martin Dürst
2021-12-01
04 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Menachem Dodge
2021-12-01
04 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Menachem Dodge
2021-11-29
04 Julian Reschke Assignment of request for Last Call review by ARTART to Julian Reschke was rejected
2021-11-29
04 Barry Leiba Request for Last Call review by ARTART is assigned to Julian Reschke
2021-11-29
04 Barry Leiba Request for Last Call review by ARTART is assigned to Julian Reschke
2021-11-29
04 Cindy Morgan IANA Review state changed to IANA - Review Needed
2021-11-29
04 Cindy Morgan
The following Last Call announcement was sent out (ends 2021-12-13):

From: The IESG
To: IETF-Announce
CC: anima-chairs@ietf.org, anima@ietf.org, draft-ietf-anima-asa-guidelines@ietf.org, rwilton@cisco.com, tte@cs.fau.de …
The following Last Call announcement was sent out (ends 2021-12-13):

From: The IESG
To: IETF-Announce
CC: anima-chairs@ietf.org, anima@ietf.org, draft-ietf-anima-asa-guidelines@ietf.org, rwilton@cisco.com, tte@cs.fau.de
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Guidelines for Autonomic Service Agents) to Informational RFC


The IESG has received a request from the Autonomic Networking Integrated
Model and Approach WG (anima) to consider the following document: -
'Guidelines for Autonomic Service Agents'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-12-13. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document proposes guidelines for the design of Autonomic Service
  Agents for autonomic networks.  Autonomic Service Agents, together
  with the Autonomic Network Infrastructure, the Autonomic Control
  Plane and the Generic Autonomic Signaling Protocol constitute base
  elements of a so-called autonomic networking ecosystem.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-anima-asa-guidelines/



No IPR declarations have been submitted directly on this I-D.




2021-11-29
04 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2021-11-29
04 Robert Wilton Last call was requested
2021-11-29
04 Robert Wilton Ballot approval text was generated
2021-11-29
04 Robert Wilton Ballot writeup was generated
2021-11-29
04 Robert Wilton IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2021-11-29
04 Robert Wilton Changed consensus to Yes from Unknown
2021-11-29
04 Robert Wilton Last call announcement was generated
2021-11-23
04 (System) Changed action holders to Robert Wilton (IESG state changed)
2021-11-23
04 (System) Sub state has been changed to AD Followup from Revised ID Needed
2021-11-23
04 Brian Carpenter New version available: draft-ietf-anima-asa-guidelines-04.txt
2021-11-23
04 (System) New version accepted (logged-in submitter: Brian Carpenter)
2021-11-23
04 Brian Carpenter Uploaded new revision
2021-11-18
03 Toerless Eckert
Shepherd writeup for draft-ietf-anima-asa-guidelines
Version: 2
Date:    11/10/2021
Author:  Toerless Eckert, tte@cs.fau.de

Status:
Document did pass WGLC earlier this week.

> As required by …
Shepherd writeup for draft-ietf-anima-asa-guidelines
Version: 2
Date:    11/10/2021
Author:  Toerless Eckert, tte@cs.fau.de

Status:
Document did pass WGLC earlier this week.

> As required by RFC 4858, this is the current template for the Document
> Shepherd Write-Up. Changes are expected over time.
>
> This version is dated 1 November 2019.

> (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

This draft requests to be an informational WG RFC.
This status is correctly indicated in the page header.

> (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

The ANIMA WG has defined a set of mechanisms through its RFCs most of whom where
released earlier in 2021.

One key benefit of these mechanisms is to make it easier to develop and deploy
network automation software agents on network devices. These agents are called
"Autonomic Service Agents" (ASA).

This simplification is achieved through the autonomic services offered by ANIMAs
"Autonomic Networking Infrastructure" and its services provided to those ASA.

This document gives an overview of the structure of ASA and guidance for its
interaction mechanisms with those services. These functions are primarily
service (objective) interactions with other ASA via the ANI GRASP protocol,
use of the ANI's ACP for any other secure communication between ASA and ASA
Lifecycles.

> Working Group Summary:

This document was worked on and improved by several members of the WG for
a long time (Since Sep 2016) without being adopted because work on ASA and
potocols/mechanisms for them was out of charter for a long time. Most issues
where resolved during this time, which is why the document only needed to
receive few revisions after being adopted by the WG when the charter allowed
for it.

> Document Quality:

This document is of an architectural/design nature. It predates significant
implementation experience. It does not discuss any protocols but primarily
use of abstract service interfaces within a network device.

A simple proof of concept of some of the aspects described in this document
was done by Brian Carpenter (co-author) and is discussed here:

https://mailarchive.ietf.org/arch/msg/anima/u1TCJQ0PpOJSVs9bdqr5akwA25w/                                   
There are no formal languages used.

Thorough reviews where done by multiple reviewers listed in the acknowledgement
section including the Shepherd (for the penultimate version of the document).

> Who is the Document Shepherd? Who is the Responsible Area Director?

Document Shepherd: Toerless Eckert

Responsible AD: Rob Wilton (OPS).

Note that initially, ANIMA was completely managed by an INT AD
(Terry Manderson) because there was a lot of larger system component
interaction issues to be resolved, which was probably felt to better
fit INT than OPS. This document, while only being informational,
is primarily talking about integration aspects of components, where
an INT AD might also be an option (Shepherd has no strong opinion either way).

> (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

See above. Thorough review by Shepherd.
The Shepherd thinks that this document is ready for publication.

> (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

> (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

> (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

The document shepherd is fine with the document.
There are no issues. The need of the document is
the desire to provide some initial guidance for
software developers intending to start building ASA
and ANI software components. Given how this first round
of guidance for a completely new (ANIMA) architecture
is intended to predate such developments, there are
a lot of unknowns, and this is fine.

> (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

Brian Carpenter:  Mail as of Oct 16th
Sheng Jiang:      Mail as of Oct 18th
Pierre Peloso:    Mail as of Nov  5th
Laurent Civiaglia: Mail as of Nov 10th
>
> (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No: Authors are not aware of any IPR that has not been reported to IETF.

> (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There is strong consensus in the WG (after going through the revisions to
improve the document quality).

> (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

> (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

https://www6.ietf.org/tools/idnits was run in verbose mode against
the document and found no issues other than its usual self-issues
(not document issues).

> (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

NA: No formal languages are used, no registries referenced or created.

> (13) Have all references within this document been identified as either normative or informative?

Yes.

> (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

All normative references have been published as RFC.

> (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No downware references.

> (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No changes to existing RFCs.

> (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

This document makes no requests to IANA.

> (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

NA.

> (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

NA.

> (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

NA.

2021-11-18
03 (System) Changed action holders to Brian Carpenter, Sheng Jiang, Laurent Ciavaglia, Robert Wilton, Peloso Pierre (IESG state changed)
2021-11-18
03 Robert Wilton IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2021-11-10
03 (System) Changed action holders to Robert Wilton (IESG state changed)
2021-11-10
03 Robert Wilton IESG state changed to AD Evaluation from Publication Requested
2021-11-10
03 Toerless Eckert
Shepherd writeup for draft-ietf-anima-asa-guidelines
Version: 2
Date:    11/10/2021
Author:  Toerless Eckert, tte@cs.fau.de

Status:
Document did pass WGLC earlier this week.

> As required by …
Shepherd writeup for draft-ietf-anima-asa-guidelines
Version: 2
Date:    11/10/2021
Author:  Toerless Eckert, tte@cs.fau.de

Status:
Document did pass WGLC earlier this week.

> As required by RFC 4858, this is the current template for the Document
> Shepherd Write-Up. Changes are expected over time.
>
> This version is dated 1 November 2019.

> (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

This draft requests to be an informational WG RFC.
This status is correctly indicated in the page header.

> (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

The ANIMA WG has defined a set of mechanisms through its RFCs most of whom where
released earlier in 2021.

One key benefit of these mechanisms is to make it easier to develop and deploy
network automation software agents on network devices. These agents are called
"Autonomic Service Agents" (ASA).

This simplification is achieved through the autonomic services offered by ANIMAs
"Autonomic Networking Infrastructure" and its services provided to those ASA.

This document gives an overview of the structure of ASA and guidance for its
interaction mechanisms with those services. These functions are primarily
service (objective) interactions with other ASA via the ANI GRASP protocol,
use of the ANI's ACP for any other secure communication between ASA and ASA
Lifecycles.

> Working Group Summary:

This document was worked on and improved by several members of the WG for
a long time (Since Sep 2016) without being adopted because work on ASA and
potocols/mechanisms for them was out of charter for a long time. Most issues
where resolved during this time, which is why the document only needed to
receive few revisions after being adopted by the WG when the charter allowed
for it.

> Document Quality:

This document is of an architectural/design nature. It predates significant
implementation experience. It does not discuss any protocols but primarily
use of abstract service interfaces within a network device.

A simple proof of concept of some of the aspects described in this document
was done by Brian Carpenter (co-author) and is discussed here:

https://mailarchive.ietf.org/arch/msg/anima/u1TCJQ0PpOJSVs9bdqr5akwA25w/                                   
There are no formal languages used.

Thorough reviews where done by multiple reviewers listed in the acknowledgement
section including the Shepherd (for the penultimate version of the document).

> Who is the Document Shepherd? Who is the Responsible Area Director?

Document Shepherd: Toerless Eckert

Responsible AD: The AD responsible for ANIMA is Rob Wilton (OPS).
Currently, there is no AD assigned to this document.

Note that initially, ANIMA was completely managed by an INT AD
(Terry Manderson) because there was a lot of larger system component
interaction issues to be resolved, which was probably felt to better
fit INT than OPS. This document, while only being informational,
is primarily talking about integration aspects of components, where
an INT AD might also be an option (Shepherd has no strong opinion either way).

> (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

See above. Thorough review by Shepherd.
The Shepherd thinks that this document is ready for publication.

> (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

> (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

> (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

The document shepherd is fine with the document.
There are no issues. The need of the document is
the desire to provide some initial guidance for
software developers intending to start building ASA
and ANI software components. Given how this first round
of guidance for a completely new (ANIMA) architecture
is intended to predate such developments, there are
a lot of unknowns, and this is fine.

> (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

Brian Carpenter:  Mail as of Oct 16th
Sheng Jiang:      Mail as of Oct 18th
Pierre Peloso:    Mail as of Nov  5th
Laurent Civiaglia: Mail as of Nov 10th
>
> (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No: Authors are not aware of any IPR that has not been reported to IETF.

> (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There is strong consensus in the WG (after going through the revisions to
improve the document quality).

> (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

> (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

https://www6.ietf.org/tools/idnits was run in verbose mode against
the document and found no issues other than its usual self-issues
(not document issues).

> (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

NA: No formal languages are used, no registries referenced or created.

> (13) Have all references within this document been identified as either normative or informative?

Yes.

> (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

All normative references have been published as RFC.

> (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No downware references.

> (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No changes to existing RFCs.

> (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

This document makes no requests to IANA.

> (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

NA.

> (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

NA.

> (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

NA.

2021-11-10
03 Toerless Eckert Responsible AD changed to Robert Wilton
2021-11-10
03 Toerless Eckert IETF WG state changed to Submitted to IESG for Publication from WG Document
2021-11-10
03 Toerless Eckert IESG state changed to Publication Requested from I-D Exists
2021-11-10
03 Toerless Eckert IESG process started in state Publication Requested
2021-11-10
03 Toerless Eckert
Shepherd writeup for draft-ietf-anima-asa-guidelines
Version: 2
Date:    11/10/2021
Author:  Toerless Eckert, tte@cs.fau.de

Status:
Document did pass WGLC earlier this week.

> As required by …
Shepherd writeup for draft-ietf-anima-asa-guidelines
Version: 2
Date:    11/10/2021
Author:  Toerless Eckert, tte@cs.fau.de

Status:
Document did pass WGLC earlier this week.

> As required by RFC 4858, this is the current template for the Document
> Shepherd Write-Up. Changes are expected over time.
>
> This version is dated 1 November 2019.

> (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

This draft requests to be an informational WG RFC.
This status is correctly indicated in the page header.

> (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

The ANIMA WG has defined a set of mechanisms through its RFCs most of whom where
released earlier in 2021.

One key benefit of these mechanisms is to make it easier to develop and deploy
network automation software agents on network devices. These agents are called
"Autonomic Service Agents" (ASA).

This simplification is achieved through the autonomic services offered by ANIMAs
"Autonomic Networking Infrastructure" and its services provided to those ASA.

This document gives an overview of the structure of ASA and guidance for its
interaction mechanisms with those services. These functions are primarily
service (objective) interactions with other ASA via the ANI GRASP protocol,
use of the ANI's ACP for any other secure communication between ASA and ASA
Lifecycles.

> Working Group Summary:

This document was worked on and improved by several members of the WG for
a long time (Since Sep 2016) without being adopted because work on ASA and
potocols/mechanisms for them was out of charter for a long time. Most issues
where resolved during this time, which is why the document only needed to
receive few revisions after being adopted by the WG when the charter allowed
for it.

> Document Quality:

This document is of an architectural/design nature. It predates significant
implementation experience. It does not discuss any protocols but primarily
use of abstract service interfaces within a network device.

A simple proof of concept of some of the aspects described in this document
was done by Brian Carpenter (co-author) and is discussed here:

https://mailarchive.ietf.org/arch/msg/anima/u1TCJQ0PpOJSVs9bdqr5akwA25w/                                   
There are no formal languages used.

Thorough reviews where done by multiple reviewers listed in the acknowledgement
section including the Shepherd (for the penultimate version of the document).

> Who is the Document Shepherd? Who is the Responsible Area Director?

Document Shepherd: Toerless Eckert

Responsible AD: The AD responsible for ANIMA is Rob Wilton (OPS).
Currently, there is no AD assigned to this document.

Note that initially, ANIMA was completely managed by an INT AD
(Terry Manderson) because there was a lot of larger system component
interaction issues to be resolved, which was probably felt to better
fit INT than OPS. This document, while only being informational,
is primarily talking about integration aspects of components, where
an INT AD might also be an option (Shepherd has no strong opinion either way).

> (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

See above. Thorough review by Shepherd.
The Shepherd thinks that this document is ready for publication.

> (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

> (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

> (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

The document shepherd is fine with the document.
There are no issues. The need of the document is
the desire to provide some initial guidance for
software developers intending to start building ASA
and ANI software components. Given how this first round
of guidance for a completely new (ANIMA) architecture
is intended to predate such developments, there are
a lot of unknowns, and this is fine.

> (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

Brian Carpenter:  Mail as of Oct 16th
Sheng Jiang:      Mail as of Oct 18th
Pierre Peloso:    Mail as of Nov  5th
Laurent Civiaglia: Mail as of Nov 10th
>
> (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No: Authors are not aware of any IPR that has not been reported to IETF.

> (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There is strong consensus in the WG (after going through the revisions to
improve the document quality).

> (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

> (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

https://www6.ietf.org/tools/idnits was run in verbose mode against
the document and found no issues other than its usual self-issues
(not document issues).

> (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

NA: No formal languages are used, no registries referenced or created.

> (13) Have all references within this document been identified as either normative or informative?

Yes.

> (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

All normative references have been published as RFC.

> (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No downware references.

> (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No changes to existing RFCs.

> (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

This document makes no requests to IANA.

> (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

NA.

> (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

NA.

> (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

NA.

2021-11-06
03 Brian Carpenter New version available: draft-ietf-anima-asa-guidelines-03.txt
2021-11-06
03 (System) New version accepted (logged-in submitter: Brian Carpenter)
2021-11-06
03 Brian Carpenter Uploaded new revision
2021-11-04
02 Toerless Eckert
Shepherd writeup for draft-ietf-anima-asa-guidelines
Date:  11/04/2021
Author: Toerless Eckert, tte@cs.fau.de

Status:
Document did pass WGLC earlier this week.

Open issues:

1.  We are missing IPR …
Shepherd writeup for draft-ietf-anima-asa-guidelines
Date:  11/04/2021
Author: Toerless Eckert, tte@cs.fau.de

Status:
Document did pass WGLC earlier this week.

Open issues:

1.  We are missing IPR disclosure replies from Laurent Ciavaglia and Peloso Pierre.

2.  The shepherd would like to see another rev of the document before passing
    the document on to AD/IETF/IESG review:

  a) https://mailarchive.ietf.org/arch/msg/anima/8TLhWV0NcSOQhKihe-tc5Co1_6g/
      (That was a marker from Brian Carpenter)

  b) adding a reference to the IP journal article and finding a good place
      where to reference it in the document .

      i would suggest a sentence stating that that document gives a good
      overview to ASA software developers how ANI works, and gives examples
      of ASA and some of their relevant details defined in this document.

> As required by RFC 4858, this is the current template for the Document
> Shepherd Write-Up. Changes are expected over time.
>
> This version is dated 1 November 2019.

> (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

This draft requests to be an informational WG RFC.
This status is correctly indicated in the page header.

> (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

The ANIMA WG has defined a set of mechanisms through its RFCs most of whom where
released earlier in 2021.

One key benefit of these mechanisms is to make it easier to develop and deploy
network automation software agents on network devices. These agents are called
"Autonomic Service Agents" (ASA).

This simplification is achieved through the autonomic services offered by ANIMAs
"Autonomic Networking Infrastructure" and its services provided to those ASA.

This document gives an overview of the structure of ASA and guidance for its
interaction mechanisms with those services. These functions are primarily
service (objective) interactions with other ASA via the ANI GRASP protocol,
use of the ANI's ACP for any other secure communication between ASA and ASA
Lifecycles.

> Working Group Summary:

This document was worked on and improved by several members of the WG for
a long time (Since Sep 2016) without being adopted because work on ASA and
potocols/mechanisms for them was out of charter for a long time. Most issues
where resolved during this time, which is why the document only needed to
receive few revisions after being adopted by the WG when the charter allowed
for it.

> Document Quality:

This document is of an architectural/design nature. It predates significant
implementation experience. It does not discuss any protocols but primarily
use of abstract service interfaces within a network device.

A simple proof of concept of some of the aspects described in this document
was done by Brian Carpenter (co-author) and is discussed here:

https://mailarchive.ietf.org/arch/msg/anima/u1TCJQ0PpOJSVs9bdqr5akwA25w/                                   
There are no formal languages used.

Thorough reviews where done by multiple reviewers listed in the acknowledgement
section including the Shepherd (for the penultimate version of the document).

> Who is the Document Shepherd? Who is the Responsible Area Director?

Document Shepherd: Toerless Eckert

Responsible AD: The AD responsible for ANIMA is Rob Wilton (OPS).
Currently, there is no AD assigned to this document.

Note that initially, ANIMA was completely managed by an INT AD
(Terry Manderson) because there was a lot of larger system component
interaction issues to be resolved, which was probably felt to better
fit INT than OPS. This document, while only being informational,
is primarily talking about integration aspects of components, where
an INT AD might also be an option (Shepherd has no strong opinion either way).

> (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

See above. Thorough review by Shepherd.
The Shepherd thinks that this document is ready for publication.

> (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

> (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

> (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

The document shepherd is fine with the document.
There are no issues. The need of the document is
the desire to provide some initial guidance for
software developers intending to start building ASA
and ANI software components. Given how this first round
of guidance for a completely new (ANIMA) architecture
is intended to predate such developments, there are
a lot of unknowns, and this is fine.

> (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

TBD.

The following authors have provided the necessary confirmation:
Brian Carpenter:  Mail as of Oct 16th
Sheng Jiang:      Mail as of Oct 18th
>
> (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosure was filed.

> (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There is strong consensus in the WG (after going through the revisions to
improve the document quality).

> (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

> (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

https://www6.ietf.org/tools/idnits was run in verbose mode against
the document and found no issues other than its usual self-issues
(not document issues).

> (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

NA: No formal languages are used, no registries referenced or created.

> (13) Have all references within this document been identified as either normative or informative?

Yes.

> (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

All normative references have been published as RFC.

> (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No downware references.

> (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No changes to existing RFCs.

> (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

This document makes no requests to IANA.

> (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

NA.

> (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

NA.

> (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

NA.

2021-09-12
02 Brian Carpenter New version available: draft-ietf-anima-asa-guidelines-02.txt
2021-09-12
02 (System) New version accepted (logged-in submitter: Brian Carpenter)
2021-09-12
02 Brian Carpenter Uploaded new revision
2021-06-26
01 Brian Carpenter New version available: draft-ietf-anima-asa-guidelines-01.txt
2021-06-26
01 (System) New version accepted (logged-in submitter: Brian Carpenter)
2021-06-26
01 Brian Carpenter Uploaded new revision
2021-05-18
00 (System) Document has expired
2021-05-17
00 Sheng Jiang Intended Status changed to Informational from None
2021-03-05
00 Toerless Eckert Notification list changed to tte@cs.fau.de from ttef@cs.fau.de, tte@cs.fau.de
2020-11-15
00 Toerless Eckert Notification list changed to ttef@cs.fau.de, tte@cs.fau.de from ttef@cs.fau.de because the document shepherd was set
2020-11-15
00 Toerless Eckert Document shepherd changed to Toerless Eckert
2020-11-15
00 Toerless Eckert Notification list changed to ttef@cs.fau.de because the document shepherd was set
2020-11-15
00 Toerless Eckert Document shepherd changed to Toerless Eckert
2020-11-14
00 Brian Carpenter This document now replaces draft-carpenter-anima-asa-guidelines instead of None
2020-11-14
00 Brian Carpenter New version available: draft-ietf-anima-asa-guidelines-00.txt
2020-11-14
00 (System) New version accepted (logged-in submitter: Brian Carpenter)
2020-11-14
00 Brian Carpenter Uploaded new revision