<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="info" consensus="true" docName="draft-ietf-anima-asa-guidelines-7" indexInclude="true" ipr="trust200902" number="9222" prepTime="2022-03-31T14:56:01" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-anima-asa-guidelines-7" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9222" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="ASA Guidelines">Guidelines for Autonomic Service Agents</title>
    <seriesInfo name="RFC" value="9222" stream="IETF"/>
    <author fullname="Brian Carpenter" initials="B." surname="Carpenter">
      <organization abbrev="Univ. of Auckland" showOnFrontPage="true"/>
      <address>
        <postal>
          <street>School of Computer Science</street>
          <street>University of Auckland</street>
          <street>PB 92019</street>
          <city>Auckland</city>
          <region/>
          <code>1142</code>
          <country>NZ</country>
        </postal>
        <email>brian.e.carpenter@gmail.com</email>
      </address>
    </author>
    <author fullname="Laurent Ciavaglia" initials="L." surname="Ciavaglia">
      <organization showOnFrontPage="true">Rakuten Mobile</organization>
      <address>
        <postal>
          <street/>
          <code/>
          <city>Paris</city>
          <region/>
          <country>FR</country>
        </postal>
        <email>laurent.ciavaglia@rakuten.com</email>
      </address>
    </author>
    <author fullname="Sheng Jiang" initials="S." surname="Jiang">
      <organization showOnFrontPage="true">Huawei Technologies Co., Ltd</organization>
      <address>
        <postal>
          <street>Q14 Huawei Campus</street>
          <street>156 Beiqing Road</street>
          <street>Hai-Dian District</street>
          <city>Beijing</city>
          <code>100095</code>
          <country>CN</country>
        </postal>
        <email>jiangsheng@huawei.com</email>
      </address>
    </author>
    <author fullname="Pierre Peloso" initials="P." surname="Peloso">
      <organization showOnFrontPage="true">Nokia</organization>
      <address>
        <postal>
          <street>Villarceaux</street>
          <code>91460</code>
          <city>Nozay</city>
          <region/>
          <country>FR</country>
        </postal>
        <email>pierre.peloso@nokia.com</email>
      </address>
    </author>
    <date month="03" year="2022"/>
    <keyword>GRASP</keyword>
    <keyword>autonomous</keyword>
    <keyword>autonomic function</keyword>
    <keyword>self-management</keyword>
    <keyword>autonomic networking</keyword>
    <keyword>autonomous operation</keyword>
    <keyword>self-management</keyword>
    <keyword>infrastructure</keyword>
    <keyword>intent</keyword>
    <keyword>autonomic control plane</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">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 an
      autonomic networking ecosystem.
      </t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for informational purposes.  
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by the
            Internet Engineering Steering Group (IESG).  Not all documents
            approved by the IESG are candidates for any level of Internet
            Standard; see Section 2 of RFC 7841. 
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9222" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2022 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-logical-structure-of-an-aut">Logical Structure of an Autonomic Service Agent</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-interaction-with-the-autono">Interaction with the Autonomic Networking Infrastructure</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-interaction-with-the-securi">Interaction with the Security Mechanisms</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-interaction-with-the-autonom">Interaction with the Autonomic Control Plane</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.3">
                <t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-interaction-with-grasp-and-">Interaction with GRASP and its API</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.4">
                <t indent="0" pn="section-toc.1-1.4.2.4.1"><xref derivedContent="4.4" format="counter" sectionFormat="of" target="section-4.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-interaction-with-policy-mec">Interaction with Policy Mechanisms</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-interaction-with-non-autono">Interaction with Non-autonomic Components and Systems</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-design-of-grasp-objectives">Design of GRASP Objectives</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-life-cycle">Life Cycle</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-installation-phase">Installation Phase</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2.1.2">
                  <li pn="section-toc.1-1.7.2.1.2.1">
                    <t indent="0" pn="section-toc.1-1.7.2.1.2.1.1"><xref derivedContent="7.1.1" format="counter" sectionFormat="of" target="section-7.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-installation-phase-inputs-a">Installation Phase Inputs and Outputs</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.7.2.2">
                <t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-instantiation-phase">Instantiation Phase</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2.2.2">
                  <li pn="section-toc.1-1.7.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.7.2.2.2.1.1"><xref derivedContent="7.2.1" format="counter" sectionFormat="of" target="section-7.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-operators-goal">Operator's Goal</xref></t>
                  </li>
                  <li pn="section-toc.1-1.7.2.2.2.2">
                    <t indent="0" pn="section-toc.1-1.7.2.2.2.2.1"><xref derivedContent="7.2.2" format="counter" sectionFormat="of" target="section-7.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-instantiation-phase-inputs-">Instantiation Phase Inputs and Outputs</xref></t>
                  </li>
                  <li pn="section-toc.1-1.7.2.2.2.3">
                    <t indent="0" pn="section-toc.1-1.7.2.2.2.3.1"><xref derivedContent="7.2.3" format="counter" sectionFormat="of" target="section-7.2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-instantiation-phase-require">Instantiation Phase Requirements</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.7.2.3">
                <t indent="0" pn="section-toc.1-1.7.2.3.1"><xref derivedContent="7.3" format="counter" sectionFormat="of" target="section-7.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-operation-phase">Operation Phase</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.4">
                <t indent="0" pn="section-toc.1-1.7.2.4.1"><xref derivedContent="7.4" format="counter" sectionFormat="of" target="section-7.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-removal-phase">Removal Phase</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-coordination-and-data-model">Coordination and Data Models</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.8.2">
              <li pn="section-toc.1-1.8.2.1">
                <t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent="8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-coordination-between-autono">Coordination between Autonomic Functions</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.2">
                <t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent="8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-coordination-with-tradition">Coordination with Traditional Management Functions</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.3">
                <t indent="0" pn="section-toc.1-1.8.2.3.1"><xref derivedContent="8.3" format="counter" sectionFormat="of" target="section-8.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-data-models">Data Models</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-robustness">Robustness</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="11" format="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="12" format="counter" sectionFormat="of" target="section-12"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.12.2">
              <li pn="section-toc.1-1.12.2.1">
                <t indent="0" pn="section-toc.1-1.12.2.1.1"><xref derivedContent="12.1" format="counter" sectionFormat="of" target="section-12.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.12.2.2">
                <t indent="0" pn="section-toc.1-1.12.2.2.1"><xref derivedContent="12.2" format="counter" sectionFormat="of" target="section-12.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.13">
            <t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="Appendix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-example-logic-flows">Example Logic Flows</xref></t>
          </li>
          <li pn="section-toc.1-1.14">
            <t indent="0" pn="section-toc.1-1.14.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.15">
            <t indent="0" pn="section-toc.1-1.15.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="intro" numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">
      This document proposes guidelines for the design of Autonomic Service Agents
     (ASAs) in the context of an Autonomic Network (AN) based on the Autonomic Network
     Infrastructure (ANI) outlined in the autonomic networking reference model <xref target="RFC8993" format="default" sectionFormat="of" derivedContent="RFC8993"/>.
     This infrastructure makes use of
     the Autonomic Control Plane (ACP) <xref target="RFC8994" format="default" sectionFormat="of" derivedContent="RFC8994"/> and
     the GeneRic Autonomic Signaling Protocol (GRASP) <xref target="RFC8990" format="default" sectionFormat="of" derivedContent="RFC8990"/>.
     A general introduction to this environment may be found at <xref target="IPJ" format="default" sectionFormat="of" derivedContent="IPJ"/>,
     which also includes explanatory diagrams,
     and a summary of terminology is in <xref target="terminology" format="default" sectionFormat="of" derivedContent="Section 2"/>.</t>
      <t indent="0" pn="section-1-2">
     This document is a contribution to the description of an autonomic
     networking ecosystem, recognizing that a deployable autonomic network
     needs more than just ACP and GRASP implementations.  Such an autonomic
     network must achieve management tasks that a Network Operations Center
     (NOC) cannot readily achieve manually, such as continuous resource
     optimization or automated fault detection and repair. These tasks, and
     other management automation goals, are described at length in <xref target="RFC7575" format="default" sectionFormat="of" derivedContent="RFC7575"/>. The net result should be significant operational
     improvement.  To achieve this, the autonomic networking ecosystem must
     include at least a library of ASAs and corresponding GRASP technical
     objective definitions. A GRASP objective <xref target="RFC8990" format="default" sectionFormat="of" derivedContent="RFC8990"/> is a
     data structure whose main contents are a name and a value. The value
     consists of a single configurable parameter or a set of parameters of
     some kind.</t>
      <t indent="0" pn="section-1-3">There must also be tools to deploy and oversee ASAs, and integration with
     existing operational mechanisms <xref target="RFC8368" format="default" sectionFormat="of" derivedContent="RFC8368"/>. However, this document focuses
     on the design of ASAs, with some reference to implementation and operational aspects.
      </t>
      <t indent="0" pn="section-1-4">There is considerable literature about autonomic agents with a variety of
    proposals about how they should be characterized. Some examples are 
    <xref target="DEMOLA06" format="default" sectionFormat="of" derivedContent="DEMOLA06"/>,
    <xref target="HUEBSCHER08" format="default" sectionFormat="of" derivedContent="HUEBSCHER08"/>,    
    <xref target="MOVAHEDI12" format="default" sectionFormat="of" derivedContent="MOVAHEDI12"/>, and
    <xref target="GANA13" format="default" sectionFormat="of" derivedContent="GANA13"/>. However, for the present document,
    the basic definitions and goals for autonomic networking given in <xref target="RFC7575" format="default" sectionFormat="of" derivedContent="RFC7575"/>
    apply. According to RFC 7575, an Autonomic Service Agent is
    "An agent implemented
    on an autonomic node that implements an autonomic function, either in part
    (in the case of a distributed function) or whole."</t>
      <t indent="0" pn="section-1-5">ASAs must be distinguished from other forms of software
      components. They are components of network or service management; they
      do not in themselves provide services to end users. They do, however,
      provide management services to network operators and administrators.
      For example, the services envisaged for network function virtualization
      (NFV) <xref target="NFV" format="default" sectionFormat="of" derivedContent="NFV"/> or for service function chaining (SFC) <xref target="RFC7665" format="default" sectionFormat="of" derivedContent="RFC7665"/> might be managed by an ASA rather than by traditional
      configuration tools.</t>
      <t indent="0" pn="section-1-6">Another example is that an existing script running within a router to
    locally monitor or configure functions or services could be upgraded to an
    ASA that could communicate with peer scripts on neighboring or remote
    routers.  A high-level API will allow such upgraded scripts to take full
    advantage of the secure ACP and the discovery, negotiation, and
    synchronization features of GRASP. Familiar tasks such as configuring an
    Interior Gateway Protocol (IGP) on neighboring routers or even exchanging
    IGP security keys could be performed securely in this way. This document
    mainly addresses issues affecting quite complex ASAs, but initially, the
    most useful ASAs may in fact be rather simple evolutions of existing
    scripts.</t>
      <t indent="0" pn="section-1-7">The reference model <xref target="RFC8993" format="default" sectionFormat="of" derivedContent="RFC8993"/> for autonomic networks
      explains further the functionality of ASAs by adding the following:</t>
      <blockquote pn="section-1-8">
      [An ASA is] a process that makes use of the features provided by the
      ANI to achieve its own goals, usually including interaction with other
      ASAs via GRASP <xref target="RFC8990" format="default" sectionFormat="of" derivedContent="RFC8990"/> or otherwise.  Of
      course, it also interacts with the specific targets of its function,
      using any suitable mechanism.  Unless its function is very simple, the
      ASA will need to handle overlapping asynchronous operations.  It may
      therefore be a quite complex piece of software in its own right, forming
      part of the application layer above the ANI.
</blockquote>
      <t indent="0" pn="section-1-9">As mentioned, there will certainly be simple ASAs that manage a
      single objective in a straightforward way and do not need asynchronous
      operations.  In nodes where computing power and memory space are limited,
      ASAs should run at a much lower frequency than the primary workload, so
      CPU load should not be a big issue, but memory footprint in a
      constrained node is certainly a concern. ASAs installed in constrained
      devices will have limited functionality.  In such cases, many aspects of
      the current document do not apply. However, in the general case, an ASA
      may be a relatively complex software component that will in many cases
      control and monitor simpler entities in the same or remote host(s). For
      example, a device controller that manages tens or hundreds of simple
      devices might contain a single ASA. </t>
      <t indent="0" pn="section-1-10">The remainder of this document offers guidance on the design of complex ASAs.
      Some of the material may be familiar to those experienced in distributed
      fault-tolerant and real-time control systems. Robustness and security
      are of particular importance in autonomic networks and are discussed
      in Sections <xref target="robust" format="counter" sectionFormat="of" derivedContent="9"/> and <xref target="security" format="counter" sectionFormat="of" derivedContent="10"/>.</t>
    </section>
    <section anchor="terminology" numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-terminology">Terminology</name>
      <t indent="0" pn="section-2-1">This section summarizes various acronyms and terminology used in the
      document. Where no other reference is given, please consult <xref target="RFC8993" format="default" sectionFormat="of" derivedContent="RFC8993"/> or <xref target="RFC7575" format="default" sectionFormat="of" derivedContent="RFC7575"/>.</t>
      <dl indent="3" newline="false" spacing="normal" pn="section-2-2">
        <dt pn="section-2-2.1">Autonomic:
        </dt>
        <dd pn="section-2-2.2">self-managing (self-configuring, self-protecting, self- healing,
	self-optimizing), but allowing high-level guidance by a central entity
	such as a NOC
	</dd>
        <dt pn="section-2-2.3">Autonomic Function:
        </dt>
        <dd pn="section-2-2.4">a function that adapts on its own to a changing environment
	</dd>
        <dt pn="section-2-2.5">Autonomic Node: 
        </dt>
        <dd pn="section-2-2.6">a node that employs autonomic functions
	</dd>
        <dt pn="section-2-2.7">ACP:
        </dt>
        <dd pn="section-2-2.8">Autonomic Control Plane <xref target="RFC8994" format="default" sectionFormat="of" derivedContent="RFC8994"/>
        </dd>
        <dt pn="section-2-2.9">AN:
        </dt>
        <dd pn="section-2-2.10">Autonomic Network; a network of autonomic nodes, which interact directly with each other
	</dd>
        <dt pn="section-2-2.11">ANI:
        </dt>
        <dd pn="section-2-2.12">Autonomic Network Infrastructure
	</dd>
        <dt pn="section-2-2.13">ASA:
        </dt>
        <dd pn="section-2-2.14">Autonomic Service Agent;  an agent installed on an autonomic node
	that implements an autonomic function, either partially (in the case
	of a distributed function) or completely
	</dd>
        <dt pn="section-2-2.15">BRSKI:
        </dt>
        <dd pn="section-2-2.16">Bootstrapping Remote Secure Key Infrastructure <xref target="RFC8995" format="default" sectionFormat="of" derivedContent="RFC8995"/>
        </dd>
        <dt pn="section-2-2.17">CBOR: 
        </dt>
        <dd pn="section-2-2.18">Concise Binary Object Representation<xref target="RFC8949" format="default" sectionFormat="of" derivedContent="RFC8949"/>
        </dd>
        <dt pn="section-2-2.19">GRASP:
        </dt>
        <dd pn="section-2-2.20">GeneRric Autonomic Signaling Protocol <xref target="RFC8990" format="default" sectionFormat="of" derivedContent="RFC8990"/>
        </dd>
        <dt pn="section-2-2.21">GRASP API:
        </dt>
        <dd pn="section-2-2.22">GRASP Application Programming Interface <xref target="RFC8991" format="default" sectionFormat="of" derivedContent="RFC8991"/>
        </dd>
        <dt pn="section-2-2.23">NOC:
        </dt>
        <dd pn="section-2-2.24">Network Operations Center <xref target="RFC8368" format="default" sectionFormat="of" derivedContent="RFC8368"/>
        </dd>
        <dt pn="section-2-2.25">Objective:
        </dt>
        <dd pn="section-2-2.26">A GRASP technical objective is a data structure whose main
	contents are a name and a value.  The value consists of a single
	configurable parameter or a set of parameters of some kind <xref target="RFC8990" format="default" sectionFormat="of" derivedContent="RFC8990"/>.
	</dd>
      </dl>
    </section>
    <section anchor="structure" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-logical-structure-of-an-aut">Logical Structure of an Autonomic Service Agent</name>
      <t indent="0" pn="section-3-1">As mentioned above, all but the simplest ASAs will need to support
      asynchronous operations.  Different programming environments support
      asynchronicity in different ways. In this document, we use an explicit
      multi-threading model to describe operations. This is illustrative, and
      alternatives to multi-threading are discussed in detail in connection
      with the GRASP API (see <xref target="api" format="default" sectionFormat="of" derivedContent="Section 4.3"/>).
      </t>
      <t indent="0" pn="section-3-2">A typical ASA will have a main thread that performs various initial
      housekeeping actions such as:
      </t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3-3">
        <li pn="section-3-3.1">obtain authorization credentials, if needed</li>
        <li pn="section-3-3.2">register the ASA with GRASP</li>
        <li pn="section-3-3.3">acquire relevant policy parameters</li>
        <li pn="section-3-3.4">declare data structures for relevant GRASP objectives</li>
        <li pn="section-3-3.5">register with GRASP those objectives that it will actively manage</li>
        <li pn="section-3-3.6">launch a self-monitoring thread</li>
        <li pn="section-3-3.7">enter its main loop</li>
      </ul>
      <t indent="0" pn="section-3-4">The logic of the main loop will depend on the details of the autonomic function concerned.
       Whenever asynchronous operations are required, extra threads may be launched. 
       Examples of such threads include:
      </t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3-5">
        <li pn="section-3-5.1">repeatedly flood an objective to the AN so that any ASA can
        receive the objective's latest value</li>
        <li pn="section-3-5.2">accept incoming synchronization requests for an objective managed by this ASA</li>
        <li pn="section-3-5.3">accept incoming negotiation requests for an objective managed by this ASA,
    and then conduct the resulting negotiation with the counterpart ASA</li>
        <li pn="section-3-5.4">manage subsidiary non-autonomic devices directly</li>
      </ul>
      <t indent="0" pn="section-3-6">These threads should all either exit after their job is done or
      enter a wait state for new work to avoid wasting system resources.</t>
      <t indent="0" pn="section-3-7">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 synchronization primitives to maintain consistency.</t>
      <t indent="0" pn="section-3-8">The main loop itself could act as the initiator of synchronization
      requests or negotiation requests when the ASA needs data or resources
      from other ASAs. In particular, the main loop should watch for changes
      in policy parameters that affect its operation and, if appropriate,
      occasionally refresh authorization credentials. It should also do
      whatever is required to avoid unnecessary resource consumption, for
      example, by limiting its frequency of execution.</t>
      <t indent="0" pn="section-3-9">The self-monitoring thread is of considerable importance. Failure of
      autonomic service agents is highly undesirable.  To a large extent, this
      depends on careful coding and testing, with no unhandled error returns
      or exceptions, but if there is nevertheless some sort of failure, the
      self-monitoring thread should detect it, fix it if possible, and, in the
      worst case, restart the entire ASA.</t>
      <t indent="0" pn="section-3-10"><xref target="eg" format="default" sectionFormat="of" derivedContent="Appendix A"/> presents some example logic flows in informal pseudocode.</t>
    </section>
    <section anchor="interact" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-interaction-with-the-autono">Interaction with the Autonomic Networking Infrastructure</name>
      <section anchor="interacts" numbered="true" toc="include" removeInRFC="false" pn="section-4.1">
        <name slugifiedName="name-interaction-with-the-securi">Interaction with the Security Mechanisms</name>
        <t indent="0" pn="section-4.1-1">An ASA by definition runs in an autonomic node. Before any normal
        ASAs are started, such nodes must be bootstrapped into the autonomic
        network's secure key infrastructure, typically in accordance with
        <xref target="RFC8995" format="default" sectionFormat="of" derivedContent="RFC8995"/>. This key infrastructure will be used to
        secure the ACP (next section) and may be used by ASAs to set up
        additional secure interactions with their peers, if needed.</t>
        <t indent="0" pn="section-4.1-2">Note that the secure bootstrap process itself incorporates simple
        special-purpose ASAs that use a restricted mode of GRASP (<xref target="RFC8995" section="4" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8995#section-4" derivedContent="RFC8995"/>).</t>
      </section>
      <section anchor="interacta" numbered="true" toc="include" removeInRFC="false" pn="section-4.2">
        <name slugifiedName="name-interaction-with-the-autonom">Interaction with the Autonomic Control Plane</name>
        <t indent="0" pn="section-4.2-1">In a normal autonomic network, ASAs will run as clients of the ACP,
        which will provide a fully secured network environment for all
        communication with other ASAs, in most cases mediated by GRASP (next
        section).</t>
        <t indent="0" pn="section-4.2-2">Note that the ACP formation process itself incorporates simple
        special-purpose ASAs that use a restricted mode of GRASP (<xref target="RFC8994" sectionFormat="of" section="6.4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8994#section-6.4" derivedContent="RFC8994"/>).</t>
      </section>
      <section anchor="api" numbered="true" toc="include" removeInRFC="false" pn="section-4.3">
        <name slugifiedName="name-interaction-with-grasp-and-">Interaction with GRASP and its API</name>
        <t indent="0" pn="section-4.3-1">In a node where a significant number of ASAs are installed, GRASP
        <xref target="RFC8990" format="default" sectionFormat="of" derivedContent="RFC8990"/> is likely to run as a separate process with
        its API <xref target="RFC8991" format="default" sectionFormat="of" derivedContent="RFC8991"/> available in user space. Thus, ASAs
        may operate without special privilege, unless they need it for other
        reasons. The ASA's view of GRASP is built around GRASP objectives
        (<xref target="objdes" format="default" sectionFormat="of" derivedContent="Section 6"/>), defined as data structures containing
        administrative information such as the objective's unique name, and
        its current value. The format and size of the value is not restricted
        by the protocol, except that it must be possible to serialize it for
        transmission in Concise Binary Object Representation (CBOR) <xref target="RFC8949" format="default" sectionFormat="of" derivedContent="RFC8949"/>, subject only to GRASP's maximum message size as
        discussed in <xref target="objdes" format="default" sectionFormat="of" derivedContent="Section 6"/>.</t>
        <t indent="0" pn="section-4.3-2">As discussed in <xref target="structure" format="default" sectionFormat="of" derivedContent="Section 3"/>, GRASP is an asynchronous
     protocol, and this document uses a multi-threading model to describe
     operations. In many programming environments, an "event loop" model is
     used instead, in which case each thread would be implemented as an event
     handler called in turn by the main loop. For this case, the GRASP API
     must provide non-blocking calls and possibly support callbacks. This
     topic is discussed in more detail in <xref target="RFC8991" format="default" sectionFormat="of" derivedContent="RFC8991"/>, and other
     asynchronicity models are also possible.  Whenever necessary, the GRASP
     session identifier will be used to distinguish simultaneous
     operations.</t>
        <t indent="0" pn="section-4.3-3">The GRASP API should offer the following features:
        </t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.3-4">
          <li pn="section-4.3-4.1">Registration functions, so that an ASA can register itself and
          the objectives that it manages.</li>
          <li pn="section-4.3-4.2">A discovery function, by which an ASA can discover other ASAs
          supporting a given objective.</li>
          <li pn="section-4.3-4.3">A negotiation request function, by which an ASA can start
          negotiation of an objective with a counterpart ASA.  With this,
          there is a corresponding listening function for an ASA that wishes
          to respond to negotiation requests and a set of functions to
          support negotiating steps. Once a negotiation starts, it is a
          symmetric process with both sides sending successive objective
          values to each other until agreement is reached (or the negotiation
          fails).</li>
          <li pn="section-4.3-4.4">A synchronization function, by which an ASA can request the
          current value of an objective from a counterpart ASA.  With this,
          there is a corresponding listening function for an ASA that wishes
          to respond to synchronization requests.  Unlike negotiation,
          synchronization is an asymmetric process in which the listener sends
          a single objective value to the requester.</li>
          <li pn="section-4.3-4.5">A flood function, by which an ASA can cause the current value of
          an objective to be flooded throughout the AN so that any ASA can
          receive it.</li>
        </ul>
        <t indent="0" pn="section-4.3-5">For further details and some additional housekeeping functions, see <xref target="RFC8991" format="default" sectionFormat="of" derivedContent="RFC8991"/>.
        </t>
        <t indent="0" pn="section-4.3-6">The GRASP API is intended to support the various interactions
        expected between most ASAs, such as the interactions outlined in <xref target="structure" format="default" sectionFormat="of" derivedContent="Section 3"/>. However, if ASAs require additional
        communication between themselves, they can do so directly over the ACP
        to benefit from its security. One option is to use GRASP discovery and
        synchronization as a rendezvous mechanism between two ASAs, passing
        communication parameters such as a TCP port number via GRASP. The use
        of TLS over the ACP for such communications is advisable, as described
        in <xref target="RFC8994" sectionFormat="of" section="6.9.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8994#section-6.9.2" derivedContent="RFC8994"/>.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-4.4">
        <name slugifiedName="name-interaction-with-policy-mec">Interaction with Policy Mechanisms</name>
        <t indent="0" pn="section-4.4-1"> At the time of writing, the policy mechanisms for the ANI are
        undefined. In particular, the use of declarative policies (aka
        Intents) for the definition and management of an ASA's behaviors remains
        a research topic <xref target="I-D.irtf-nmrg-ibn-concepts-definitions" format="default" sectionFormat="of" derivedContent="IBN-CONCEPTS"/>.</t>
        <t indent="0" pn="section-4.4-2"> In the cases where ASAs are defined as closed control
		loops, the specifications defined in <xref target="ZSM009-1" format="default" sectionFormat="of" derivedContent="ZSM009-1"/>
		regarding imperative and declarative goal statements may be
		applicable.</t>
        <t indent="0" pn="section-4.4-3">In the ANI, policy dissemination is expected to operate by
		an information distribution mechanism (e.g., via GRASP <xref target="RFC8990" format="default" sectionFormat="of" derivedContent="RFC8990"/>) that can reach all autonomic nodes and
		therefore every ASA. However, each ASA must be capable of
		operating "out of the box" in the absence of locally defined
		policy, so every ASA implementation must include carefully
		chosen default values and settings for all policy
		parameters.</t>
      </section>
    </section>
    <section anchor="nonauto" numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-interaction-with-non-autono">Interaction with Non-autonomic Components and Systems</name>
      <t indent="0" pn="section-5-1">To have any external effects, an ASA must also interact with non-autonomic
    components of the node where it is installed. For example, an ASA whose purpose
    is to manage a resource must interact with that resource. An ASA managing
    an entity that is also managed by local software must interact
    with that software. For example, if such management is performed by NETCONF
    <xref target="RFC6241" format="default" sectionFormat="of" derivedContent="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.</t>
      <t indent="0" pn="section-5-2">In an environment where systems are virtualized and specialized using
    techniques such as network function virtualization or network slicing,
    there will be a design choice whether ASAs are deployed once per physical node
    or once per virtual context. A related issue is whether the ANI as a whole
    is deployed once on a physical network or whether several virtual ANIs
    are deployed. This aspect needs to be considered by the ASA designer.</t>
    </section>
    <section anchor="objdes" numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-design-of-grasp-objectives">Design of GRASP Objectives</name>
      <t indent="0" pn="section-6-1">The design of an ASA will often require the design of a new GRASP
      objective.  The general rules for the format of GRASP objectives, their
      names, and IANA registration are given in <xref target="RFC8990" format="default" sectionFormat="of" derivedContent="RFC8990"/>. Additionally, that document discusses various
      general considerations for the design of objectives, which are not
      repeated here. However, note that GRASP, like HTTP, does
      not provide transactional integrity. In particular, steps in a GRASP
      negotiation are not idempotent. The design of a GRASP objective and the
      logic flow of the ASA should take this into account. One approach, which
      should be used when possible, is to design objectives with idempotent
      semantics. If this is not possible, typically if an ASA is allocating
      part of a shared resource to other ASAs, it needs to ensure that the
      same part of the resource is not allocated twice. The easiest way is to
      run only one negotiation at a time. If an ASA is capable of overlapping
      several negotiations, it must avoid interference between these
      negotiations.
      </t>
      <t indent="0" pn="section-6-2">Negotiations will always end, normally because one end or the other
    declares success or failure.  If this does not happen, either a timeout or
    exhaustion of the loop count will occur. The definition of a GRASP
    objective should describe a specific negotiation policy if it is not self-evident.</t>
      <t indent="0" pn="section-6-3">GRASP allows a "dry run" mode of negotiation, where a negotiation
      session follows its normal course but is not committed at either end
      until a subsequent live negotiation session.  If dry run mode is
      defined for the objective, its specification, and every implementation,
      must consider what state needs to be saved following a dry run
      negotiation, such that a subsequent live negotiation can be expected to
      succeed. It must be clear how long this state is kept and what happens
      if the live negotiation occurs after this state is deleted. An ASA that
      requests a dry run negotiation must take account of the possibility that
      a successful dry run is followed by a failed live negotiation. Because
      of these complexities, the dry run mechanism should only be supported by
      objectives and ASAs where there is a significant benefit from it.</t>
      <t indent="0" pn="section-6-4">The actual value field of an objective is limited by the GRASP
      protocol definition to any data structure that can be expressed in
      Concise Binary Object Representation (CBOR) <xref target="RFC8949" format="default" sectionFormat="of" derivedContent="RFC8949"/>. For some objectives, a single data item will
      suffice, for example, an integer, a floating point
      number, a UTF-8 string, or an arbitrary byte string.  For more complex
      cases, a simple tuple structure such as [item1, item2, item3] could be
      used.  Since CBOR is closely linked to JSON, it is also rather easy to
      define an objective whose value is a JSON structure. The formats
      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 (<xref target="RFC8991" sectionFormat="of" section="2.3.2.4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8991#section-2.3.2.4" derivedContent="RFC8991"/>).</t>
      <t indent="0" pn="section-6-5">The maximum size of the value field of an objective is limited by the
    GRASP maximum message size. If the default maximum size specified as
    GRASP_DEF_MAX_SIZE by <xref target="RFC8990" format="default" sectionFormat="of" derivedContent="RFC8990"/> is not enough, the
    specification of the objective must indicate the required maximum message
    size for both unicast and multicast messages.</t>
      <t indent="0" pn="section-6-6">A mapping from YANG to CBOR is defined by <xref target="I-D.ietf-core-yang-cbor" format="default" sectionFormat="of" derivedContent="CBOR-YANG"/>. Subject to
    the size limit defined for GRASP messages, nothing prevents objectives transporting YANG in this way.</t>
      <t indent="0" pn="section-6-7">The flexibility of CBOR implies that the value field of many objectives can be extended in service,
    to add additional information or alternative content, especially if JSON-like structures are
    used. This has consequences for the robustness of ASAs, as discussed in <xref target="robust" format="default" sectionFormat="of" derivedContent="Section 9"/>.</t>
    </section>
    <section anchor="life" numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-life-cycle">Life Cycle</name>
      <t indent="0" pn="section-7-1">The ASA life cycle is discussed in <xref target="I-D.peloso-anima-autonomic-function" format="default" sectionFormat="of" derivedContent="AUTONOMIC-FUNCTION"/>,
      from which the following text was derived. It does not cover all details, and some
      of the terms used would require precise definitions in a given implementation.</t>
      <t indent="0" pn="section-7-2">In simple cases, autonomic functions could be permanent, in the sense
      that ASAs are shipped as part of a product and persist throughout the
      product's life. However, in complex cases, a more likely situation is
      that ASAs need to be installed or updated dynamically because of new
      requirements or bugs. This section describes one approach to the
      resulting life cycle of individual ASAs. It does not consider wider
      issues such as updates of shared libraries.</t>
      <t indent="0" pn="section-7-3">Because continuity of service is fundamental to autonomic networking,
    the process of seamlessly replacing a running instance of an ASA with a
    new version needs to be part of the ASA's design. The implication of
    service continuity on the design of ASAs can be illustrated along the
    three main phases of the ASA life cycle, namely installation,
    instantiation, and operation.</t>
      <figure anchor="Fig_LC" align="left" suppress-title="false" pn="figure-1">
        <name slugifiedName="name-life-cycle-of-an-autonomic-">Life Cycle of an Autonomic Service Agent</name>
        <artwork name="" type="" align="left" alt="" pn="section-7-4.1">
                  +--------------+
Undeployed ------&gt;|              |------&gt; Undeployed
                  |  Installed   | 
              +--&gt;|              |---+
     Mandate  |   +--------------+   | Receives a
   is revoked |   +--------------+   |  Mandate               			  
              +---|              |&lt;--+
                  | Instantiated | 
              +--&gt;|              |---+
          set |   +--------------+   | set
         down |   +--------------+   | up             			  
              +---|              |&lt;--+
                  |  Operational | 
                  |              |
                  +--------------+
		</artwork>
      </figure>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-7.1">
        <name slugifiedName="name-installation-phase">Installation Phase</name>
        <t indent="0" pn="section-7.1-1">We define "installation" to mean that a piece of software is loaded into
        a device, along with any necessary libraries, but is not yet activated.</t>
        <t indent="0" pn="section-7.1-2">Before being able to instantiate and run ASAs, the operator will first provision the
	infrastructure with the sets of ASA software corresponding to its needs and objectives.
	Such software must be checked for integrity and authenticity before installation.
	The provisioning of the infrastructure is realized in the installation phase and consists of 
	installing (or checking the availability of) the pieces of software of the different ASAs 
	in a set of Installation Hosts within the autonomic network.</t>
        <t indent="0" pn="section-7.1-3">There are three properties applicable to the installation of ASAs:
        </t>
        <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-7.1-4">
          <li pn="section-7.1-4.1">The dynamic installation property
          allows installing an ASA on demand, on any hosts compatible with the ASA.</li>
          <li pn="section-7.1-4.2">The decoupling property
          allows an ASA on one machine to control resources in another machine
          (known as "decoupled mode").</li>
          <li pn="section-7.1-4.3">The multiplicity property
          allows controlling multiple sets of resources from a single ASA.</li>
        </ul>
        <t indent="0" pn="section-7.1-5">These three properties are very important in the context of the installation
        phase as their variations condition how the ASA could be installed on the infrastructure. </t>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-7.1.1">
          <name slugifiedName="name-installation-phase-inputs-a">Installation Phase Inputs and Outputs</name>
          <t indent="0" pn="section-7.1.1-1">Inputs are:
          </t>
          <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-7.1.1-2">
            <li pn="section-7.1.1-2.1">[ASA_type]: specifies which ASA to install.
	    </li>
            <li pn="section-7.1.1-2.2">[Installation_target_infrastructure]: specifies the candidate installation Hosts.
	    </li>
            <li pn="section-7.1.1-2.3">[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 hosts on which the ASAs are to be
	    installed, or it could consist of operator-defined criteria and
	    constraints.
	    </li>
          </ul>
          <t indent="0" pn="section-7.1.1-3">The main output of the installation phase is a [List_of_ASAs] installed on
[List_of_hosts]. This output is also useful for the coordination function
where it acts as a static interaction map (see <xref target="coordi" format="default" sectionFormat="of" derivedContent="Section 8.1"/>).</t>
          <t indent="0" pn="section-7.1.1-4">The condition to validate in order to pass to next phase is to
          ensure that [List_of_ASAs] are correctly installed on
          [List_of_hosts].  A minimum set of primitives to support the
          installation of ASAs could be the following: install (List_of_ASAs,
          Installation_target_infrastructure, ASA_placement_function) and
          uninstall (List_of_ASAs).</t>
        </section>
      </section>
      <section anchor="Sec_Inst" numbered="true" toc="include" removeInRFC="false" pn="section-7.2">
        <name slugifiedName="name-instantiation-phase">Instantiation Phase</name>
        <t indent="0" pn="section-7.2-1">We define "instantiation" as the operation of creating a single ASA instance
        from the corresponding piece of installed software.</t>
        <t indent="0" pn="section-7.2-2">Once the ASAs are installed on the appropriate hosts in the
        network, these ASAs may start to operate.  From the operator
        viewpoint, an operating ASA means the ASA manages the network
        resources as per the objectives given.  At the ASA local level,
        operating means executing their control loop algorithm.</t>
        <t indent="0" pn="section-7.2-3">There are two aspects to take into consideration.  First, having a
        piece of code installed and available to run on a host is not the same
        as having an agent based on this piece of code running inside the
        host.  Second, in a coupled case, determining which resources are
        controlled by an ASA is straightforward (the ASA runs on the same
        autonomic node as the resources it is controlling). In a decoupled
        mode, determining this is a bit more complex: a starting agent will
        have to either discover the set of resources it ought to control, or
        such information has to be communicated to the ASA.</t>
        <t indent="0" pn="section-7.2-4">The instantiation phase of an ASA covers both these aspects:
        starting the agent code (when this does not start automatically) and
        determining which resources have to be controlled (when this is not
        straightforward).</t>
        <section anchor="Sec_Inst_Goal" numbered="true" toc="include" removeInRFC="false" pn="section-7.2.1">
          <name slugifiedName="name-operators-goal">Operator's Goal</name>
          <t indent="0" pn="section-7.2.1-1">Through this phase, the operator wants to control its autonomic
          network regarding at least two aspects:
          </t>
          <ol spacing="normal" indent="adaptive" start="1" type="1" pn="section-7.2.1-2">
            <li pn="section-7.2.1-2.1" derivedCounter="1.">determine the scope of autonomic functions by instructing which network
            resources have to be managed by which autonomic function (and more precisely
            by which release of the ASA software code, e.g., version number or provider).</li>
            <li pn="section-7.2.1-2.2" derivedCounter="2.">determine how the autonomic functions are organized by instantiating a set
            of ASAs across one or more autonomic nodes and instructing them
            accordingly about the other ASAs in the set as necessary.</li>
          </ol>
          <t indent="0" pn="section-7.2.1-3">
				In this phase, the operator may also want to
				set goals for autonomic functions, e.g., by
				configuring GRASP objectives.
          </t>
          <t indent="0" pn="section-7.2.1-4">The operator's goal can be summarized in an instruction to the autonomic ecosystem matching the following format,
          explained in detail in the next sub-section:
          </t>
          <t indent="3" pn="section-7.2.1-5">[Instances_of_ASA_type] ready to control [Instantiation_target_infrastructure] with [Instantiation_target_parameters]</t>
        </section>
        <section anchor="Sec_Inst_InOut" numbered="true" toc="include" removeInRFC="false" pn="section-7.2.2">
          <name slugifiedName="name-instantiation-phase-inputs-">Instantiation Phase Inputs and Outputs</name>
          <t indent="0" pn="section-7.2.2-1">Inputs are:
          </t>
          <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-7.2.2-2">
            <li pn="section-7.2.2-2.1">[Instances_of_ASA_type]: specifies which ASAs to instantiate
	    </li>
            <li pn="section-7.2.2-2.2">[Instantiation_target_infrastructure]: specifies which
	    resources are to be managed by the autonomic function; this can be
	    the whole network or a subset of it like a domain, a physical
	    segment, or even a specific list of resources.
	    </li>
            <li pn="section-7.2.2-2.3">[Instantiation_target_parameters]: specifies which GRASP
    	    objectives are to be sent to ASAs (e.g., an optimization target)
	    </li>
          </ul>
          <t indent="0" pn="section-7.2.2-3">Outputs are:
          </t>
          <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-7.2.2-4">
            <li pn="section-7.2.2-4.1">[Set_of_ASA_resources_relations]: describes which resources are managed by which ASA instances; this is
  not a formal message but a resulting configuration log for a set of ASAs.
  </li>
          </ul>
        </section>
        <section anchor="Sec_Inst_Reqs" numbered="true" toc="include" removeInRFC="false" pn="section-7.2.3">
          <name slugifiedName="name-instantiation-phase-require">Instantiation Phase Requirements</name>
          <t indent="0" pn="section-7.2.3-1">The instructions described in <xref target="Sec_Inst" format="default" sectionFormat="of" derivedContent="Section 7.2"/> could be
          either of the following:
          </t>
          <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-7.2.3-2">
            <li pn="section-7.2.3-2.1">Sent to a targeted ASA. In this case, the receiving Agent will have to manage the
	    specified list of [Instantiation_target_infrastructure], with the
	    [Instantiation_target_parameters].
	    </li>
            <li pn="section-7.2.3-2.2">Broadcast to all ASAs. In this case, the ASAs would determine from the list which
	    ASAs would handle which [Instantiation_target_infrastructure],
	    with the [Instantiation_target_parameters].
	    </li>
          </ul>
          <t indent="0" pn="section-7.2.3-3">These instructions may be grouped as a specific data structure referred to
as an ASA Instance Mandate. The specification of such an ASA Instance Mandate
is beyond the scope of this document.</t>
          <t indent="0" pn="section-7.2.3-4">The conclusion of this instantiation phase is a set of ASA
          instances ready to operate.  These ASA instances are characterized
          by the resources they manage, the metrics being monitored, and the
          actions that can be executed (like modifying certain parameter
          values).  The description of the ASA instance may be defined in an
          ASA Instance Manifest data structure.  The specification of such an
          ASA Instance Manifest is beyond the scope of this document.</t>
          <t indent="0" pn="section-7.2.3-5">The ASA Instance Manifest does not only serve informational
          purposes such as acknowledgement of successful instantiation to the
          operator but is also necessary for further autonomic operations with:
          </t>
          <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-7.2.3-6">
            <li pn="section-7.2.3-6.1">coordinated entities (see <xref target="coordi" format="default" sectionFormat="of" derivedContent="Section 8.1"/>)</li>
            <li pn="section-7.2.3-6.2">collaborative entities with purposes such as to establish knowledge exchange
            (some ASAs may produce knowledge or monitor metrics that would be useful for other ASAs)</li>
          </ul>
        </section>
      </section>
      <section anchor="Sec_Operation" numbered="true" toc="include" removeInRFC="false" pn="section-7.3">
        <name slugifiedName="name-operation-phase">Operation Phase</name>
        <t indent="0" pn="section-7.3-1">During the operation phase, the operator can:
        </t>
        <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-7.3-2">
          <li pn="section-7.3-2.1">activate/deactivate ASAs: enable/disable their autonomic loops
  </li>
          <li pn="section-7.3-2.2">modify ASA targets: set different technical objectives
  </li>
          <li pn="section-7.3-2.3">modify ASAs managed resources: update the Instance Mandate to specify a different set of resources to
  manage (only applicable to decoupled ASAs)
  </li>
        </ul>
        <t indent="0" pn="section-7.3-3">During the operation phase, running ASAs can interact with other ASAs:
        </t>
        <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-7.3-4">
          <li pn="section-7.3-4.1">in order to exchange knowledge (e.g., an ASA providing traffic
          predictions to a load balancing ASA)</li>
          <li pn="section-7.3-4.2">in order to collaboratively reach an objective (e.g., ASAs
          pertaining to the same autonomic function will collaborate, e.g., in
          the case of a load balancing function, by modifying link metrics
          according to neighboring resource loads)</li>
        </ul>
        <t indent="0" pn="section-7.3-5">During the operation phase, running ASAs are expected to apply
        coordination schemes as per <xref target="coordi" format="default" sectionFormat="of" derivedContent="Section 8.1"/>.
        </t>
      </section>
      <section anchor="Sec_Removal" numbered="true" toc="include" removeInRFC="false" pn="section-7.4">
        <name slugifiedName="name-removal-phase">Removal Phase</name>
        <t indent="0" pn="section-7.4-1">When an ASA is removed from service and uninstalled, the above steps
        are reversed. It is important
        that its data, especially any security key material, is purged.</t>
      </section>
    </section>
    <section anchor="coordm" numbered="true" toc="include" removeInRFC="false" pn="section-8">
      <name slugifiedName="name-coordination-and-data-model">Coordination and Data Models</name>
      <section anchor="coordi" numbered="true" toc="include" removeInRFC="false" pn="section-8.1">
        <name slugifiedName="name-coordination-between-autono">Coordination between Autonomic Functions</name>
        <t indent="0" pn="section-8.1-1">Some autonomic functions will be completely independent of each
      other. However, others are at risk of interfering with each other; for
      example, two different optimization functions might both attempt to
      modify the same underlying parameter in different ways. In a complete
      system, a method is needed for identifying ASAs that might
      interfere with each other and coordinating their actions when
      necessary.</t>
      </section>
      <section anchor="coordt" numbered="true" toc="include" removeInRFC="false" pn="section-8.2">
        <name slugifiedName="name-coordination-with-tradition">Coordination with Traditional Management Functions</name>
        <t indent="0" pn="section-8.2-1">Some ASAs will have functions that overlap with existing
      configuration tools and network management mechanisms such as
      command-line interfaces, DHCP, DHCPv6, SNMP, NETCONF, and RESTCONF.
      This is, of course, an existing problem whenever multiple configuration
      tools are in use by the NOC. Each ASA designer will need to consider
      this issue and how to avoid clashes and inconsistencies in various
      deployment scenarios. Some specific considerations for interaction with
      OAM tools are given in <xref target="RFC8368" format="default" sectionFormat="of" derivedContent="RFC8368"/>.  As another example,
      <xref target="RFC8992" format="default" sectionFormat="of" derivedContent="RFC8992"/> describes how autonomic management of IPv6
      prefixes can interact with prefix delegation via DHCPv6. The description
      of a GRASP objective and of an ASA using it should include a discussion
      of any such interactions.</t>
      </section>
      <section anchor="datam" numbered="true" toc="include" removeInRFC="false" pn="section-8.3">
        <name slugifiedName="name-data-models">Data Models</name>
        <t indent="0" pn="section-8.3-1">Management functions often include a shared data model, quite likely
      to be expressed in a formal notation such as YANG. This aspect should
      not be an afterthought in the design of an ASA. To the contrary, the
      design of the ASA and of its GRASP objectives should match the data
      model; as noted in <xref target="objdes" format="default" sectionFormat="of" derivedContent="Section 6"/>, YANG serialized as CBOR may
      be used directly as the value of a GRASP objective.</t>
      </section>
    </section>
    <section anchor="robust" numbered="true" toc="include" removeInRFC="false" pn="section-9">
      <name slugifiedName="name-robustness">Robustness</name>
      <t indent="0" pn="section-9-1">It is of great importance that all components of an autonomic system
      are highly robust.  Although ASA designers should aim for their
      component to never fail, it is more important to design the ASA to
      assume that failures will happen and to gracefully recover from those
      failures when they occur. Hence, this section lists various aspects of
      robustness that ASA designers should consider:
      </t>
      <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-9-2">
        <li pn="section-9-2.1" derivedCounter="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 loop in case of persistent failure, a suitable pause should
        be inserted before such a restart. The length of the pause depends on
        the use case; randomization and exponential backoff should be
        considered.</li>
        <li pn="section-9-2.2" derivedCounter="2.">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 value known to be safe in all configurations.</li>
        <li pn="section-9-2.3" derivedCounter="3.">If a GRASP synchronization or negotiation session fails for any
        reason, it may be repeated after a suitable pause. The length of the
        pause depends on the use case; randomization and exponential backoff
        should be considered.</li>
        <li pn="section-9-2.4" derivedCounter="4.">If a session fails repeatedly, the ASA should consider that its
        peer has failed, and it should cause GRASP to flush its discovery cache and
        repeat peer discovery. </li>
        <li pn="section-9-2.5" derivedCounter="5.">In any case, it may be prudent to repeat discovery periodically,
        depending on the use case.</li>
        <li pn="section-9-2.6" derivedCounter="6.">Any received GRASP message should be checked. If it is wrongly
        formatted, it should be ignored. Within a unicast session, an Invalid
        message (M_INVALID) may be sent. This function may be provided by the
        GRASP implementation itself.</li>
        <li pn="section-9-2.7" derivedCounter="7.">Any received GRASP objective should be checked. Basic formatting
        errors like invalid CBOR will likely be detected by GRASP itself, but
        the ASA is responsible for checking the precise syntax and semantics
        of a received objective. If it is wrongly formatted, it should be
        ignored. Within a negotiation session, a Negotiation End message
        (M_END) with a Decline option (O_DECLINE) should be sent. An ASA may
        log such events for diagnostic purposes.</li>
        <li pn="section-9-2.8" derivedCounter="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).
        </li>
        <li pn="section-9-2.9" derivedCounter="9.">If an ASA receives either an Invalid message (M_INVALID) or a Negotiation End
    message (M_END) with a Decline option (O_DECLINE), one possible reason is that
    the peer ASA does not support a new feature of either GRASP or the objective
    in question. In such a case, the ASA may choose to repeat the operation concerned
    without using that new feature.
    </li>
        <li pn="section-9-2.10" derivedCounter="10.">All other possible exceptions should be handled in an orderly
        way. There should be no such thing as an unhandled exception (but see
        point 1 above).</li>
      </ol>
      <t indent="0" pn="section-9-3">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/resources it controls, it typically aims to
    improve this state to a better state, say (2).  Ideally, the ASA is built
    so that it can ensure that any error encountered can still lead to
    returning to (1) instead of a state (3), which is worse than (1). One
    example instance of this principle is "make-before-break" used in
    reconfiguration of routing protocols in manual operations. This principle
    of operations can accordingly be coded into the operation of an ASA.  The
    GRASP dry run option mentioned in <xref target="objdes" format="default" sectionFormat="of" derivedContent="Section 6"/> is another tool
    helpful for this ASA design goal of "test-before-make".
      </t>
    </section>
    <section anchor="security" numbered="true" toc="include" removeInRFC="false" pn="section-10">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-10-1">ASAs are intended to run in an environment that is protected by the
      Autonomic Control Plane <xref target="RFC8994" format="default" sectionFormat="of" derivedContent="RFC8994"/>, admission to which
      depends on an initial secure bootstrap process such as BRSKI <xref target="RFC8995" format="default" sectionFormat="of" derivedContent="RFC8995"/>.  Those documents describe security considerations
      relating to the use of and properties provided by the ACP and BRSKI,
      respectively.  Such an ACP can provide keying material for mutual
      authentication between ASAs as well as confidential communication
      channels for messages between ASAs.  In some deployments, a secure
      partition of the link layer might be used instead. GRASP itself has
      significant security considerations <xref target="RFC8990" format="default" sectionFormat="of" derivedContent="RFC8990"/>.  However,
      this does not relieve ASAs of responsibility for security.  When ASAs
      configure or manage network elements outside the ACP, potentially in a
      different physical node, they must interact with other non-autonomic
      software components to perform their management functions. The details
      are specific to each case, but this has an important security
      implication. An ASA might act as a loophole by which the managed entity
      could penetrate the security boundary of the ANI. Thus, ASAs must be
      designed to avoid loopholes such as passing on executable code or
      proxying unverified commands and should, if possible, operate in an
      unprivileged mode.  In particular, they must use secure coding
      practices, e.g., carefully validate all incoming information and avoid
      unnecessary elevation of privilege.  This will apply in particular when
      an ASA interacts with a management component such as a NETCONF
      server.</t>
      <t indent="0" pn="section-10-2">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.</t>
      <t indent="0" pn="section-10-3">As a reminder, GRASP does not intrinsically provide transactional
      integrity (<xref target="objdes" format="default" sectionFormat="of" derivedContent="Section 6"/>).</t>
      <t indent="0" pn="section-10-4">As appropriate to their specific functions, ASAs should take account
      of relevant privacy considerations <xref target="RFC6973" format="default" sectionFormat="of" derivedContent="RFC6973"/>.
      </t>
      <t indent="0" pn="section-10-5">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. In the general case, a node may have multiple roles, and a role may
      use multiple ASAs, each using multiple GRASP objectives. Additional
      mechanisms for the fine-grained authorization of nodes and ASAs to
      manipulate specific GRASP objectives could be designed.  Meanwhile, we
      repeat that ASAs should run without special privilege if possible.
      Independently of this, interfaces between ASAs and the router
      configuration and monitoring services of the node can be subject to
      authentication that provides more fine-grained authorization for
      specific services. These additional authentication parameters could be
      passed to an ASA during its instantiation phase.</t>
    </section>
    <section anchor="iana" numbered="true" toc="include" removeInRFC="false" pn="section-11">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-11-1">This document has no IANA actions.</t>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.ietf-core-yang-cbor" to="CBOR-YANG"/>
    <displayreference target="I-D.irtf-nmrg-ibn-concepts-definitions" to="IBN-CONCEPTS"/>
    <displayreference target="I-D.peloso-anima-autonomic-function" to="AUTONOMIC-FUNCTION"/>
    <references pn="section-12">
      <name slugifiedName="name-references">References</name>
      <references pn="section-12.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC8949" target="https://www.rfc-editor.org/info/rfc8949" quoteTitle="true" derivedAnchor="RFC8949">
          <front>
            <title>Concise Binary Object Representation (CBOR)</title>
            <author initials="C." surname="Bormann" fullname="C. Bormann">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="P." surname="Hoffman" fullname="P. Hoffman">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2020" month="December"/>
            <abstract>
              <t indent="0">The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.</t>
              <t indent="0">This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049.  It does not create a new version of the format.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="94"/>
          <seriesInfo name="RFC" value="8949"/>
          <seriesInfo name="DOI" value="10.17487/RFC8949"/>
        </reference>
        <reference anchor="RFC8990" target="https://www.rfc-editor.org/info/rfc8990" quoteTitle="true" derivedAnchor="RFC8990">
          <front>
            <title>GeneRic Autonomic Signaling Protocol (GRASP)</title>
            <author initials="C." surname="Bormann" fullname="C. Bormann">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B." surname="Carpenter" fullname="B. Carpenter" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B." surname="Liu" fullname="B. Liu" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2021" month="May"/>
            <abstract>
              <t indent="0">This document specifies the GeneRic Autonomic Signaling Protocol (GRASP), which enables autonomic nodes and Autonomic Service Agents to dynamically discover peers, to synchronize state with each other, and to negotiate parameter settings with each other. GRASP depends on an external security environment that is described elsewhere. The technical objectives and parameters for specific application scenarios are to be described in separate documents. Appendices briefly discuss requirements for the protocol and existing protocols with comparable features.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8990"/>
          <seriesInfo name="DOI" value="10.17487/RFC8990"/>
        </reference>
        <reference anchor="RFC8994" target="https://www.rfc-editor.org/info/rfc8994" quoteTitle="true" derivedAnchor="RFC8994">
          <front>
            <title>An Autonomic Control Plane (ACP)</title>
            <author initials="T." surname="Eckert" fullname="T. Eckert" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Behringer" fullname="M. Behringer" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Bjarnason" fullname="S. Bjarnason">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2021" month="May"/>
            <abstract>
              <t indent="0">Autonomic functions need a control plane to communicate, which depends on some addressing and routing.  This Autonomic Control Plane should ideally be self-managing and be as independent as possible of configuration.  This document defines such a plane and calls it the "Autonomic Control Plane", with the primary use as a control plane for autonomic functions.  It also serves as a "virtual out-of-band channel" for Operations, Administration, and Management (OAM) communications over a network that provides automatically configured, hop-by-hop authenticated and encrypted communications via automatically configured IPv6 even when the network is not configured or is misconfigured.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8994"/>
          <seriesInfo name="DOI" value="10.17487/RFC8994"/>
        </reference>
        <reference anchor="RFC8995" target="https://www.rfc-editor.org/info/rfc8995" quoteTitle="true" derivedAnchor="RFC8995">
          <front>
            <title>Bootstrapping Remote Secure Key Infrastructure (BRSKI)</title>
            <author initials="M." surname="Pritikin" fullname="M. Pritikin">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Richardson" fullname="M. Richardson">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Eckert" fullname="T. Eckert">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Behringer" fullname="M. Behringer">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="K." surname="Watsen" fullname="K. Watsen">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2021" month="May"/>
            <abstract>
              <t indent="0">This document specifies automated bootstrapping of an Autonomic Control Plane.  To do this, a Secure Key Infrastructure is bootstrapped.  This is done using manufacturer-installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline.  We call this process the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. Bootstrapping a new device can occur when using a routable address and a cloud service, only link-local connectivity, or limited/disconnected networks. Support for deployment models with less stringent security requirements is included. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device.  The established secure connection can be used to deploy a locally issued certificate to the device as well.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8995"/>
          <seriesInfo name="DOI" value="10.17487/RFC8995"/>
        </reference>
      </references>
      <references pn="section-12.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="I-D.peloso-anima-autonomic-function" quoteTitle="true" target="https://datatracker.ietf.org/doc/html/draft-peloso-anima-autonomic-function-01" derivedAnchor="AUTONOMIC-FUNCTION">
          <front>
            <title>A Day in the Life of an Autonomic Function</title>
            <author fullname="Peloso Pierre">
	 </author>
            <author fullname="Laurent Ciavaglia">
	 </author>
            <date month="March" day="21" year="2016"/>
            <abstract>
              <t indent="0">   While autonomic functions are often pre-installed and integrated with
   the network elements they manage, this is not a mandatory condition.
   Allowing autonomic functions to be dynamically installed and to
   control resources remotely enables more versatile deployment
   approaches and enlarges the application scope to virtually any legacy
   equipment.  The analysis of autonomic functions deployment schemes
   through the installation, instantiation and operation phases allows
   constructing a unified life-cycle and identifying new required
   functionality.  Thus, the introduction of autonomic technologies will
   be facilitated, the adoption much more rapid and broad.  Operators
   will benefit from multi-vendor, inter-operable autonomic functions
   with homogeneous operations and superior quality, and will have more
   freedom in their deployment scenarios.


              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-peloso-anima-autonomic-function-01"/>
          <format type="TXT" target="https://www.ietf.org/archive/id/draft-peloso-anima-autonomic-function-01.txt"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="I-D.ietf-core-yang-cbor" quoteTitle="true" target="https://datatracker.ietf.org/doc/html/draft-ietf-core-yang-cbor-18" derivedAnchor="CBOR-YANG">
          <front>
            <title>CBOR Encoding of Data Modeled with YANG</title>
            <author initials="M" surname="Veillette" fullname="Michel Veillette" role="editor"/>
            <author initials="I" surname="Petrov" fullname="Ivaylo Petrov" role="editor"/>
            <author initials="A" surname="Pelov" fullname="Alexander Pelov"/>
            <author initials="C" surname="Bormann" fullname="Carsten Bormann"/>
            <author initials="M" surname="Richardson" fullname="Michael Richardson"/>
            <date month="December" year="2021"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-core-yang-cbor-18"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="DEMOLA06" quoteTitle="true" derivedAnchor="DEMOLA06">
          <front>
            <title>Towards an Agent Model for Future Autonomic Communications</title>
            <seriesInfo name="Proceedings of the 7th WOA 2006 Workshop From Objects to Agents" value="51-59"/>
            <author initials="F." surname="De Mola" fullname=""/>
            <author initials="R." surname="Quitadamo"/>
            <date month="September" year="2006"/>
          </front>
        </reference>
        <reference anchor="GANA13" target="https://www.etsi.org/deliver/etsi_gs/AFI/001_099/002/01.01.01_60/gs_afi002v010101p.pdf" quoteTitle="true" derivedAnchor="GANA13">
          <front>
            <title>Autonomic network engineering for the self-managing Future Internet (AFI); Generic Autonomic Network Architecture (An Architectural Reference Model for Autonomic Networking, Cognitive Networking and Self-Management)</title>
            <author>
              <organization showOnFrontPage="true">ETSI</organization>
            </author>
            <date month="April" year="2013"/>
          </front>
          <refcontent>GS AFI 002</refcontent>
          <refcontent>V1.1.1</refcontent>
        </reference>
        <reference anchor="HUEBSCHER08" quoteTitle="true" target="https://doi.org/10.1145/1380584.1380585" derivedAnchor="HUEBSCHER08">
          <front>
            <title>A survey of autonomic computing - degrees, models, and applications</title>
            <author initials="M. C." surname="Huebscher"/>
            <author initials="J. A." surname="McCann"/>
            <date month="August" year="2008"/>
          </front>
          <seriesInfo name="DOI" value="10.1145/1380584.1380585"/>
          <refcontent>ACM Computing Surveys (CSUR)</refcontent>
          <refcontent>Volume 40, Issue 3</refcontent>
        </reference>
        <reference anchor="I-D.irtf-nmrg-ibn-concepts-definitions" quoteTitle="true" target="https://datatracker.ietf.org/doc/html/draft-irtf-nmrg-ibn-concepts-definitions-09" derivedAnchor="IBN-CONCEPTS">
          <front>
            <title>Intent-Based Networking - Concepts and Definitions</title>
            <author fullname="Alexander Clemm">
              <organization showOnFrontPage="true">Futurewei</organization>
            </author>
            <author fullname="Laurent Ciavaglia">
              <organization showOnFrontPage="true">Rakuten Mobile</organization>
            </author>
            <author fullname="Lisandro Zambenedetti Granville">
              <organization showOnFrontPage="true">Federal University of Rio Grande do Sul (UFRGS)</organization>
            </author>
            <author fullname="Jeff Tantsura">
              <organization showOnFrontPage="true">Microsoft</organization>
            </author>
            <date month="March" day="24" year="2022"/>
            <abstract>
              <t indent="0">   Intent and Intent-Based Networking (IBN) are taking the industry by
   storm.  At the same time, IBN-related terms are often used loosely
   and inconsistently, in many cases overlapping and confused with other
   concepts such as "Policy."  This document clarifies the concept of
   "Intent" and provides an overview of the functionality that is
   associated with it.  The goal is to contribute towards a common and
   shared understanding of terms, concepts, and functionality that can
   be used as the foundation to guide further definition of associated
   research and engineering problems and their solutions.

   This document is a product of the IRTF Network Management Research
   Group (NMRG).  It reflects the consensus of the research group,
   having received many detailed and positive reviews by RG
   participants.  It is published for informational purposes.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-irtf-nmrg-ibn-concepts-definitions-09"/>
          <format type="TXT" target="https://www.ietf.org/archive/id/draft-irtf-nmrg-ibn-concepts-definitions-09.txt"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="IPJ" target="https://ipj.dreamhosters.com/wp-content/uploads/2021/10/243-ipj.pdf" quoteTitle="true" derivedAnchor="IPJ">
          <front>
            <title>Autonomic Networking Gets Serious</title>
            <author surname="Behringer" initials="M."/>
            <author surname="Bormann" initials="C."/>
            <author surname="Carpenter" initials="B. E."/>
            <author surname="Eckert" initials="T."/>
            <author surname="Campos Nobre" initials="J."/>
            <author surname="Jiang" initials="S."/>
            <author surname="Li" initials="Y."/>
            <author surname="Richardson" initials="M. C."/>
            <date month="October" year="2021"/>
          </front>
          <refcontent>The Internet Protocol Journal</refcontent>
          <refcontent>Volume 24, Issue 3, Page(s) 2 - 18</refcontent>
          <refcontent>ISSN 1944-1134</refcontent>
        </reference>
        <reference anchor="MOVAHEDI12" quoteTitle="true" target="https://doi.org/10.1109/SURV.2011.042711.00078" derivedAnchor="MOVAHEDI12">
          <front>
            <title>A Survey of Autonomic Network Architectures and Evaluation Criteria</title>
            <seriesInfo name="DOI" value="10.1109/SURV.2011.042711.00078"/>
            <author initials="Z." surname="Movahedi"/>
            <author initials="M." surname="Ayari"/>
            <author initials="R." surname="Langar"/>
            <author initials="G." surname="Pujolle"/>
            <date year="2012"/>
          </front>
          <refcontent>IEEE Communications Surveys &amp; Tutorials</refcontent>
          <refcontent>Volume 14, Issue 2, Pages 464 - 490</refcontent>
        </reference>
        <reference anchor="NFV" target="https://portal.etsi.org/NFV/NFV_White_Paper.pdf" quoteTitle="true" derivedAnchor="NFV">
          <front>
            <title>Network Functions Virtualisation</title>
            <author>
              <organization showOnFrontPage="true">ETSI</organization>
            </author>
            <date month="October" year="2012"/>
          </front>
          <refcontent>SDN and OpenFlow World Congress</refcontent>
        </reference>
        <reference anchor="RFC6241" target="https://www.rfc-editor.org/info/rfc6241" quoteTitle="true" derivedAnchor="RFC6241">
          <front>
            <title>Network Configuration Protocol (NETCONF)</title>
            <author initials="R." surname="Enns" fullname="R. Enns" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Bjorklund" fullname="M. Bjorklund" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Schoenwaelder" fullname="J. Schoenwaelder" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Bierman" fullname="A. Bierman" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2011" month="June"/>
            <abstract>
              <t indent="0">The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices.  It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages.  The NETCONF protocol operations are realized as remote procedure calls (RPCs).  This document obsoletes RFC 4741.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6241"/>
          <seriesInfo name="DOI" value="10.17487/RFC6241"/>
        </reference>
        <reference anchor="RFC6973" target="https://www.rfc-editor.org/info/rfc6973" quoteTitle="true" derivedAnchor="RFC6973">
          <front>
            <title>Privacy Considerations for Internet Protocols</title>
            <author initials="A." surname="Cooper" fullname="A. Cooper">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="H." surname="Tschofenig" fullname="H. Tschofenig">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B." surname="Aboba" fullname="B. Aboba">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Peterson" fullname="J. Peterson">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Morris" fullname="J. Morris">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Hansen" fullname="M. Hansen">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Smith" fullname="R. Smith">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2013" month="July"/>
            <abstract>
              <t indent="0">This document offers guidance for developing privacy considerations for inclusion in protocol specifications.  It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices.  It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6973"/>
          <seriesInfo name="DOI" value="10.17487/RFC6973"/>
        </reference>
        <reference anchor="RFC7575" target="https://www.rfc-editor.org/info/rfc7575" quoteTitle="true" derivedAnchor="RFC7575">
          <front>
            <title>Autonomic Networking: Definitions and Design Goals</title>
            <author initials="M." surname="Behringer" fullname="M. Behringer">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Pritikin" fullname="M. Pritikin">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Bjarnason" fullname="S. Bjarnason">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Clemm" fullname="A. Clemm">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B." surname="Carpenter" fullname="B. Carpenter">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Jiang" fullname="S. Jiang">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="L." surname="Ciavaglia" fullname="L. Ciavaglia">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2015" month="June"/>
            <abstract>
              <t indent="0">Autonomic systems were first described in 2001.  The fundamental goal is self-management, including self-configuration, self-optimization, self-healing, and self-protection.  This is achieved by an autonomic function having minimal dependencies on human administrators or centralized management systems.  It usually implies distribution across network elements.</t>
              <t indent="0">This document defines common language and outlines design goals (and what are not design goals) for autonomic functions.  A high-level reference model illustrates how functional elements in an Autonomic Network interact.  This document is a product of the IRTF's Network Management Research Group.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7575"/>
          <seriesInfo name="DOI" value="10.17487/RFC7575"/>
        </reference>
        <reference anchor="RFC7665" target="https://www.rfc-editor.org/info/rfc7665" quoteTitle="true" derivedAnchor="RFC7665">
          <front>
            <title>Service Function Chaining (SFC) Architecture</title>
            <author initials="J." surname="Halpern" fullname="J. Halpern" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Pignataro" fullname="C. Pignataro" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2015" month="October"/>
            <abstract>
              <t indent="0">This document describes an architecture for the specification, creation, and ongoing maintenance of Service Function Chains (SFCs) in a network.  It includes architectural concepts, principles, and components used in the construction of composite services through deployment of SFCs, with a focus on those to be standardized in the IETF.  This document does not propose solutions, protocols, or extensions to existing protocols.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7665"/>
          <seriesInfo name="DOI" value="10.17487/RFC7665"/>
        </reference>
        <reference anchor="RFC8368" target="https://www.rfc-editor.org/info/rfc8368" quoteTitle="true" derivedAnchor="RFC8368">
          <front>
            <title>Using an Autonomic Control Plane for Stable Connectivity of Network Operations, Administration, and Maintenance (OAM)</title>
            <author initials="T." surname="Eckert" fullname="T. Eckert" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Behringer" fullname="M. Behringer">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2018" month="May"/>
            <abstract>
              <t indent="0">Operations, Administration, and Maintenance (OAM), as per BCP 161, for data networks is often subject to the problem of circular dependencies when relying on connectivity provided by the network to be managed for the OAM purposes.</t>
              <t indent="0">Provisioning while bringing up devices and networks tends to be more difficult to automate than service provisioning later on.  Changes in core network functions impacting reachability cannot be automated because of ongoing connectivity requirements for the OAM equipment itself, and widely used OAM protocols are not secure enough to be carried across the network without security concerns.</t>
              <t indent="0">This document describes how to integrate OAM processes with an autonomic control plane in order to provide stable and secure connectivity for those OAM processes.  This connectivity is not subject to the aforementioned circular dependencies.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8368"/>
          <seriesInfo name="DOI" value="10.17487/RFC8368"/>
        </reference>
        <reference anchor="RFC8991" target="https://www.rfc-editor.org/info/rfc8991" quoteTitle="true" derivedAnchor="RFC8991">
          <front>
            <title>GeneRic Autonomic Signaling Protocol Application Program Interface (GRASP API)</title>
            <author initials="B." surname="Carpenter" fullname="B. Carpenter">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B." surname="Liu" fullname="B. Liu" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="W." surname="Wang" fullname="W. Wang">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="X." surname="Gong" fullname="X. Gong">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2021" month="May"/>
            <abstract>
              <t indent="0">This document is a conceptual outline of an Application Programming Interface (API) for the GeneRic Autonomic Signaling Protocol (GRASP). Such an API is needed for Autonomic Service Agents (ASAs) calling the GRASP protocol module to exchange Autonomic Network messages with other ASAs. Since GRASP is designed to support asynchronous operations, the API will need to be adapted according to the support for asynchronicity in various programming languages and operating systems.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8991"/>
          <seriesInfo name="DOI" value="10.17487/RFC8991"/>
        </reference>
        <reference anchor="RFC8992" target="https://www.rfc-editor.org/info/rfc8992" quoteTitle="true" derivedAnchor="RFC8992">
          <front>
            <title>Autonomic IPv6 Edge Prefix Management in Large-Scale Networks</title>
            <author initials="S." surname="Jiang" fullname="S. Jiang" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="Z." surname="Du" fullname="Z. Du">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B." surname="Carpenter" fullname="B. Carpenter">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="Q." surname="Sun" fullname="Q. Sun">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2021" month="May"/>
            <abstract>
              <t indent="0">This document defines two autonomic technical objectives for IPv6 prefix management at the edge of large-scale ISP networks, with an extension to support IPv4 prefixes. An important purpose of this document is to use it for validation of the design of various components of the Autonomic Networking Infrastructure.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8992"/>
          <seriesInfo name="DOI" value="10.17487/RFC8992"/>
        </reference>
        <reference anchor="RFC8993" target="https://www.rfc-editor.org/info/rfc8993" quoteTitle="true" derivedAnchor="RFC8993">
          <front>
            <title>A Reference Model for Autonomic Networking</title>
            <author initials="M." surname="Behringer" fullname="M. Behringer" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B." surname="Carpenter" fullname="B. Carpenter">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Eckert" fullname="T. Eckert">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="L." surname="Ciavaglia" fullname="L. Ciavaglia">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Nobre" fullname="J. Nobre">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2021" month="May"/>
            <abstract>
              <t indent="0">This document describes a reference model for Autonomic Networking for managed networks. It defines the behavior of an autonomic node, how the various elements in an autonomic context work together, and how autonomic services can use the infrastructure.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8993"/>
          <seriesInfo name="DOI" value="10.17487/RFC8993"/>
        </reference>
        <reference anchor="ZSM009-1" target="https://www.etsi.org/deliver/etsi_gs/ZSM/001_099/00901/01.01.01_60/gs_ZSM00901v010101p.pdf" quoteTitle="true" derivedAnchor="ZSM009-1">
          <front>
            <title>Zero-touch network and Service Management (ZSM); Closed-Loop Automation; Part 1: Enablers</title>
            <author>
              <organization showOnFrontPage="true">ETSI</organization>
            </author>
            <date month="June" year="2021"/>
          </front>
          <refcontent>GS ZSM 009-1</refcontent>
          <refcontent>Version 1.1.1</refcontent>
        </reference>
      </references>
    </references>
    <section anchor="eg" numbered="true" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-example-logic-flows">Example Logic Flows</name>
      <t indent="0" pn="section-appendix.a-1">This appendix describes generic logic flows that combine to act as an
      Autonomic Service Agent (ASA) for resource management. Note that these
      are illustrative examples and are in no sense requirements. As long as
      the rules of GRASP are followed, a real implementation could be
      different. The reader is assumed to be familiar with GRASP <xref target="RFC8990" format="default" sectionFormat="of" derivedContent="RFC8990"/> and its conceptual API <xref target="RFC8991" format="default" sectionFormat="of" derivedContent="RFC8991"/>.
</t>
      <t indent="0" pn="section-appendix.a-2">A complete autonomic function for a distributed resource will consist
      of a number of instances of the ASA placed at relevant points in a
      network. Specific details will, of course, depend on the resource
      concerned. One example is IP address prefix management, as specified in
      <xref target="RFC8992" format="default" sectionFormat="of" derivedContent="RFC8992"/>. In this case, an instance of the ASA will
      exist in each delegating router.
</t>
      <t indent="0" pn="section-appendix.a-3">
An underlying assumption is that there is an initial source of the resource in
question, referred to here as an origin ASA. The other ASAs, known as
delegators, obtain supplies of the resource from the origin, delegate
quantities of the resource to consumers that request it, and recover it when
no longer needed.
</t>
      <t indent="0" pn="section-appendix.a-4">
Another assumption is there is a set of network-wide policy parameters, which
the origin will provide to the delegators. These parameters will control how
the delegators decide how much resource to provide to consumers.  Thus, the
ASA logic has two operating modes: origin and delegator. When running as an
origin, it starts by obtaining a quantity of the resource from the NOC, and it
acts as a source of policy parameters, via both GRASP flooding and GRASP
synchronization. (In some scenarios, flooding or synchronization alone might
be sufficient, but this example includes both.)
</t>
      <t indent="0" pn="section-appendix.a-5">
When running as a delegator, it starts with an empty resource pool,
acquires the policy parameters by GRASP synchronization, and delegates
quantities of the resource to consumers that request it. Both as an origin and as a delegator, when its pool is low,
it seeks quantities of the resource by
requesting GRASP negotiation with peer ASAs. When its pool is sufficient, it
hands out resource to peer ASAs in response to negotiation requests. Thus,
over time, the initial resource pool held by the origin will be shared among
all the delegators according to demand.
</t>
      <t indent="0" pn="section-appendix.a-6">
In theory, a network could include any number of origins and any number of
delegators, with the only condition being that each origin's initial resource
pool is unique. A realistic scenario is to have exactly one origin and as many
delegators as you like. A scenario with no origin is useless.
</t>
      <t indent="0" pn="section-appendix.a-7">
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, which focuses on communication between ASAs. Since GRASP operations are not intrinsically idempotent, data integrity during failure scenarios is the responsibility of the ASA designer. This is a complex topic in its own right that is not discussed in the present document.
</t>
      <t indent="0" pn="section-appendix.a-8">
The description below does not implement GRASP's dry run function. That would require temporarily marking any resource handed out in a dry run negotiation as reserved, until either the peer obtains it in a live run, or a suitable timeout occurs.
</t>
      <t indent="0" pn="section-appendix.a-9">
The main data structures used in each instance of the ASA are:
</t>
      <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-appendix.a-10">
        <li pn="section-appendix.a-10.1">resource_pool: an ordered list of available resources, for example. Depending on the
  nature of the resource, units of resource are split when appropriate, and a
  background garbage collector recombines split resources if they are returned
  to the pool.
  </li>
        <li pn="section-appendix.a-10.2">delegated_list: where a delegator stores the resources it has given to subsidiary devices.    
  </li>
      </ul>
      <t indent="0" pn="section-appendix.a-11">
Possible main logic flows are below, using a threaded implementation model. As noted above, alternative approaches to asynchronous operations are possible. The transformation to an event loop model should be apparent; each thread would correspond to one event in the event loop.
</t>
      <t indent="0" pn="section-appendix.a-12">
The GRASP objectives are as follows:
</t>
      <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-appendix.a-13">
        <li pn="section-appendix.a-13.1">["EX1.Resource", flags, loop_count, value], where the value depends on the resource concerned but will typically include its size and          
identification. 
</li>
        <li pn="section-appendix.a-13.2">["EX1.Params", flags, loop_count, value], where the value will be, for example, a JSON object defining the applicable parameters.  
</li>
      </ul>
      <t indent="0" pn="section-appendix.a-14">
In the outline logic flows below, these objectives are represented simply by their names.
      </t>
      <sourcecode type="pseudocode" markers="false" pn="section-appendix.a-15">
MAIN PROGRAM:

Create empty resource_pool (and an associated lock)
Create empty delegated_list
Determine whether to act as origin
if origin:
    Obtain initial resource_pool contents from NOC
    Obtain value of EX1.Params from NOC
Register ASA with GRASP
Register GRASP objectives EX1.Resource and EX1.Params
if origin:
    Start FLOODER thread to flood EX1.Params
    Start SYNCHRONIZER listener for EX1.Params
Start MAIN_NEGOTIATOR thread for EX1.Resource
if not origin:
    Obtain value of EX1.Params from GRASP flood or synchronization
    Start DELEGATOR thread
Start GARBAGE_COLLECTOR thread
good_peer = none
do forever:
    if resource_pool is low:
        Calculate amount A of resource needed
        Discover peers using GRASP M_DISCOVER / M_RESPONSE
        if good_peer in peers:
            peer = good_peer
        else:
            peer =  #any choice among peers
        grasp.request_negotiate("EX1.Resource", peer)
        #i.e., send negotiation request
        Wait for response (M_NEGOTIATE, M_END or M_WAIT)
        if OK:
            if offered amount of resource sufficient:
                Send M_END + O_ACCEPT #negotiation succeeded
                Add resource to pool
                good_peer = peer      #remember this choice
            else:
                Send M_END + O_DECLINE #negotiation failed
                good_peer = none       #forget this choice
    sleep() #periodic timer suitable for application scenario
</sourcecode>
      <sourcecode type="pseudocode" markers="false" pn="section-appendix.a-16">
MAIN_NEGOTIATOR thread:

do forever:
    grasp.listen_negotiate("EX1.Resource")
    #i.e., wait for negotiation request
    Start a separate new NEGOTIATOR thread for requested amount A
</sourcecode>
      <sourcecode type="pseudocode" markers="false" pn="section-appendix.a-17">
NEGOTIATOR thread:

Request resource amount A from resource_pool
if not OK:
    while not OK and A &gt; Amin:
        A = A-1
        Request resource amount A from resource_pool
if OK:
    Offer resource amount A to peer by GRASP M_NEGOTIATE
    if received M_END + O_ACCEPT:
        #negotiation succeeded
    elif received M_END + O_DECLINE or other error:
        #negotiation failed
        Return resource to resource_pool
else:
    Send M_END + O_DECLINE #negotiation failed
#thread exits
</sourcecode>
      <sourcecode type="pseudocode" markers="false" pn="section-appendix.a-18">
DELEGATOR thread:

do forever:
    Wait for request or release for resource amount A
    if request:
        Get resource amount A from resource_pool
        if OK:
            Delegate resource to consumer #atomic
            Record in delegated_list      #operation
        else:
            Signal failure to consumer
            Signal main thread that resource_pool is low
    else:
        Delete resource from delegated_list
        Return resource amount A to resource_pool
</sourcecode>
      <sourcecode type="pseudocode" markers="false" pn="section-appendix.a-19">
SYNCHRONIZER thread:

do forever:
    Wait for  M_REQ_SYN message for EX1.Params
    Reply with M_SYNCH message for EX1.Params
</sourcecode>
      <sourcecode type="pseudocode" markers="false" pn="section-appendix.a-20">
FLOODER thread:

do forever:
    Send M_FLOOD message for EX1.Params
    sleep() #periodic timer suitable for application scenario

</sourcecode>
      <sourcecode type="pseudocode" markers="false" pn="section-appendix.a-21">
GARBAGE_COLLECTOR thread:

do forever:
    Search resource_pool for adjacent resources
    Merge adjacent resources
    sleep() #periodic timer suitable for application scenario
</sourcecode>
    </section>
    <section anchor="ack" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.b">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.b-1">Valuable comments were received from <contact fullname="Michael       Behringer"/>, <contact fullname="Menachem Dodge"/>, <contact fullname="Martin Dürst"/>, <contact fullname="Toerless Eckert"/>,
      <contact fullname="Thomas Fossati"/>, <contact fullname="Alex Galis"/>,
      <contact fullname="Bing Liu"/>, <contact fullname="Benno Overeinder"/>,
      <contact fullname="Michael Richardson"/>, <contact fullname="Rob       Wilton"/>, and other IESG members.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.c">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Brian Carpenter" initials="B." surname="Carpenter">
        <organization abbrev="Univ. of Auckland" showOnFrontPage="true"/>
        <address>
          <postal>
            <street>School of Computer Science</street>
            <street>University of Auckland</street>
            <street>PB 92019</street>
            <city>Auckland</city>
            <region/>
            <code>1142</code>
            <country>NZ</country>
          </postal>
          <email>brian.e.carpenter@gmail.com</email>
        </address>
      </author>
      <author fullname="Laurent Ciavaglia" initials="L." surname="Ciavaglia">
        <organization showOnFrontPage="true">Rakuten Mobile</organization>
        <address>
          <postal>
            <street/>
            <code/>
            <city>Paris</city>
            <region/>
            <country>FR</country>
          </postal>
          <email>laurent.ciavaglia@rakuten.com</email>
        </address>
      </author>
      <author fullname="Sheng Jiang" initials="S." surname="Jiang">
        <organization showOnFrontPage="true">Huawei Technologies Co., Ltd</organization>
        <address>
          <postal>
            <street>Q14 Huawei Campus</street>
            <street>156 Beiqing Road</street>
            <street>Hai-Dian District</street>
            <city>Beijing</city>
            <code>100095</code>
            <country>CN</country>
          </postal>
          <email>jiangsheng@huawei.com</email>
        </address>
      </author>
      <author fullname="Pierre Peloso" initials="P." surname="Peloso">
        <organization showOnFrontPage="true">Nokia</organization>
        <address>
          <postal>
            <street>Villarceaux</street>
            <code>91460</code>
            <city>Nozay</city>
            <region/>
            <country>FR</country>
          </postal>
          <email>pierre.peloso@nokia.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
