Skip to main content

A Reference Model for Autonomic Networking
RFC 8993

Revision differences

Document history

Date Rev. By Action
2021-05-21
10 (System)
Received changes through RFC Editor sync (created alias RFC 8993, changed abstract to 'This document describes a reference model for Autonomic Networking for managed …
Received changes through RFC Editor sync (created alias RFC 8993, changed abstract to '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.', changed pages to 26, changed standardization level to Informational, changed state to RFC, added RFC published event at 2021-05-21, changed IESG state to RFC Published)
2021-05-21
10 (System) RFC published
2021-05-06
10 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2021-04-10
10 (System) RFC Editor state changed to AUTH48
2021-02-22
10 (System) RFC Editor state changed to RFC-EDITOR from REF
2021-02-01
10 (System) RFC Editor state changed to REF from EDIT
2020-11-02
10 (System) RFC Editor state changed to EDIT from MISSREF
2018-11-26
10 (System) IANA Action state changed to No IANA Actions from In Progress
2018-11-26
10 (System) RFC Editor state changed to MISSREF
2018-11-26
10 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2018-11-26
10 (System) Announcement was received by RFC Editor
2018-11-26
10 (System) IANA Action state changed to In Progress
2018-11-24
10 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2018-11-24
10 Cindy Morgan IESG has approved the document
2018-11-24
10 Cindy Morgan Closed "Approve" ballot
2018-11-24
10 Cindy Morgan Ballot approval text was generated
2018-11-23
10 Ignas Bagdonas IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2018-11-22
10 Michael Behringer New version available: draft-ietf-anima-reference-model-10.txt
2018-11-22
10 (System) New version approved
2018-11-22
10 (System) Request for posting confirmation emailed to previous authors: anima-chairs@ietf.org, Laurent Ciavaglia , Michael Behringer , Toerless Eckert , Brian Carpenter , Jeferson Nobre
2018-11-22
10 Michael Behringer Uploaded new revision
2018-11-06
09 (System) Sub state has been changed to AD Followup from Revised ID Needed
2018-11-06
09 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2018-11-06
09 Michael Behringer New version available: draft-ietf-anima-reference-model-09.txt
2018-11-06
09 (System) New version approved
2018-11-06
09 (System) Request for posting confirmation emailed to previous authors: anima-chairs@ietf.org, Laurent Ciavaglia , Michael Behringer , Toerless Eckert , Brian Carpenter , Jeferson Nobre
2018-11-06
09 Michael Behringer Uploaded new revision
2018-10-26
08 Benjamin Kaduk
[Ballot comment]
Removing my Discuss since the issue is addressed in the latest editor's copy.
For posterity, the discuss point was:

Section 9.2 says:

  …
[Ballot comment]
Removing my Discuss since the issue is addressed in the latest editor's copy.
For posterity, the discuss point was:

Section 9.2 says:

  An autonomic network consists of autonomic devices that form a
  distributed self-managing system.  Devices within a domain share a
  common trust anchor and thus implicitly trust each other.  [...]

This seems to be a fundamental misstatement of how
trust anchors work.  Sharing a trust anchor means that you are willing to
trust the same entity, the holder of the private key for that trust anchor.
It does not imply any relationship between the two entiteis that trust the
trust anchor.

To be clear,  I think that the authors do understand the actual trust
and security situation here, and the rest of the subsection makes sense; I
just think that this text needs to be changed to make the situation clear
to the reader in an accurate way.

and the original COMMENT (also preserved for posterity):

Section 5

I think it would be good to explicitly mention that in order to provide the
autonomic nature, trust is extremely coarse-grained, in that a device is
either in the PKI, in which case it is (essentially) fully trusted and
authorized for all actions, or it is not in the PKI and totally untrusted.

Section 9.1

I think it's better to say that packets have confidentiality protection
than to say that they are encrypted.

I would also be reluctant to speculate too much about the possibilities for
traffic analysis; as is often said, "attacks can only get better; they
never get worse".
2018-10-26
08 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss
2018-10-25
08 Cindy Morgan Changed consensus to Yes from Unknown
2018-10-25
08 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2018-10-25
08 Benjamin Kaduk
[Ballot discuss]
Section 9.2 says:

  An autonomic network consists of autonomic devices that form a
  distributed self-managing system.  Devices within a domain share …
[Ballot discuss]
Section 9.2 says:

  An autonomic network consists of autonomic devices that form a
  distributed self-managing system.  Devices within a domain share a
  common trust anchor and thus implicitly trust each other.  [...]

This seems to be a fundamental misstatement of how
trust anchors work.  Sharing a trust anchor means that you are willing to
trust the same entity, the holder of the private key for that trust anchor.
It does not imply any relationship between the two entiteis that trust the
trust anchor.

To be clear,  I think that the authors do understand the actual trust
and security situation here, and the rest of the subsection makes sense; I
just think that this text needs to be changed to make the situation clear
to the reader in an accurate way.
2018-10-25
08 Benjamin Kaduk
[Ballot comment]
Section 5

I think it would be good to explicitly mention that in order to provide the
autonomic nature, trust is extremely coarse-grained, …
[Ballot comment]
Section 5

I think it would be good to explicitly mention that in order to provide the
autonomic nature, trust is extremely coarse-grained, in that a device is
either in the PKI, in which case it is (essentially) fully trusted and
authorized for all actions, or it is not in the PKI and totally untrusted.

Section 9.1

I think it's better to say that packets have confidentiality protection
than to say that they are encrypted.

I would also be reluctant to speculate too much about the possibilities for
traffic analysis; as is often said, "attacks can only get better; they
never get worse".
2018-10-25
08 Benjamin Kaduk [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk
2018-10-25
08 Mirja Kühlewind
[Ballot comment]
One comment: I'm just wondering if there is any insider (or outsider) attack where an attacker node could disconnect all or some other …
[Ballot comment]
One comment: I'm just wondering if there is any insider (or outsider) attack where an attacker node could disconnect all or some other nodes, or at least overload the network such that is would be unusable. Would be nice to see some more discussion about this in the security considerations section!
2018-10-25
08 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2018-10-25
08 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2018-10-25
08 Alissa Cooper
[Ballot comment]
Since draft-ietf-anima-bootstrapping-keyinfra is a normative reference in this document, IDevID seems like it should be as well. That is, it seems to be …
[Ballot comment]
Since draft-ietf-anima-bootstrapping-keyinfra is a normative reference in this document, IDevID seems like it should be as well. That is, it seems to be used in a normative way in the same manner as the other normative references in this document. If the document were not going to have any normative references, then I think IDevID could be informative.
2018-10-25
08 Alissa Cooper Ballot comment text updated for Alissa Cooper
2018-10-25
08 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2018-10-24
08 Adam Roach [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach
2018-10-24
08 Spencer Dawkins
[Ballot comment]
I'm confused here ...

  This document describes a first, simple, implementable phase of an
  Autonomic Networking solution.  It is expected that …
[Ballot comment]
I'm confused here ...

  This document describes a first, simple, implementable phase of an
  Autonomic Networking solution.  It is expected that the experience
  from this phase will be used in defining updated and extended
  specifications over time.  Some topics are considered architecturally
  in this document, but are not yet reflected in the implementation
  specifications.  They are marked with an (*).

This is true now, but when this document is approved, will it be published immediately (in which case, this is "truth decay", because it becomes less true in the unchanging RFC every time a topic is reflected in implementation specifications), or will it be held until all the (*)s are stable?
2018-10-24
08 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2018-10-24
08 Ben Campbell
[Ballot comment]
Thanks for the work on this. I just have one editorial comment:

- Several sections describe themselves as being for "informational purposes". Given …
[Ballot comment]
Thanks for the work on this. I just have one editorial comment:

- Several sections describe themselves as being for "informational purposes". Given that this is an informational document, isn't that true of all sections?
2018-10-24
08 Ben Campbell [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell
2018-10-24
08 Deborah Brungard
[Ballot comment]
In discussing the Autonomic Control Plane (section 4.6), it says "is implemented as an overlay network".
"Overlay" in routing documents (e.g. GMPLS) refers …
[Ballot comment]
In discussing the Autonomic Control Plane (section 4.6), it says "is implemented as an overlay network".
"Overlay" in routing documents (e.g. GMPLS) refers to an abstraction of the underlying data layer.
The rtgdir reviewer (Chris) was also confused on the use of "overlay". Is your intention for the
control plane to be independent of the topology of the data plane layer? For GMPLS, where the control
plane and data plane are clearly separated, the control and data planes are said to be "decoupled"
(control plane neighbors may not necessarily be data plane neighbors). Suggest not to use "overlay" if
your intention is for it to be decoupled. If the intention is for it to reflect an (abstracted) connectivity of
the data plane layer than could use '"overlay" though it would be helpful to define what is meant.

Please review Chris's other comments.
2018-10-24
08 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2018-10-24
08 Eric Rescorla
[Ballot comment]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3602



COMMENTS
S 2.
>      +- - - - - - - - - - …
[Ballot comment]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3602



COMMENTS
S 2.
>      +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
>      :                Autonomic Networking Infrastructure              :
>      +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
>      +--------+  :    +--------+  :    +--------+  :        +--------+
>      | Node 1 |--------| Node 2 |--------| Node 3 |----...-----| Node n |
>      +--------+  :    +--------+  :    +--------+  :        +--------+

This diagram is kind of hard to follow. You say ASAs are instantiated
on nodes, but these ASAs don't seem to be attached to any particular
nodes.


S 4.3.

>  4.3.  Discovery

>      Traditionally, most of the information a node requires is provided
>      through configuration or northbound interfaces.  An autonomic
>      function should rely on such northbound interfaces minimally or not

is "northbound" a synonym for "configuration"?


S 6.1.
>      Thus we can distinguish at least three classes of ASAs:

>      o  Simple ASAs with a small footprint that could run anywhere.

>      o  Complex, possibly multi-threaded ASAs that have a significant
>        resource requirement and will only run on selected nodes.

This is kind of nitpicking but there are plenty of languages where
multithreading is natural even in simple programs (e.g., Rust or to
some extent Go).


S 6.1.
>      components.  Also, they may be coded in a variety of programming
>      languages, in particular including languages that support object
>      constructs as well as traditional variables and structures.  The APIs
>      should be designed with these factors in mind.

>      It must be possible to run ASAs as non-privileged (user space)

You probably don't want parentheses here. non-privileged and user
space are different thigns.


S 6.1.
>      negotiation failures must be treated as routine, with the ASA
>      retrying the failed operation, preferably with an exponential back-
>      off in the case of persistent errors.  When multiple threads are
>      started within an ASA, these threads must be monitored for failures
>      and hangups, and appropriate action taken.  Attention must be given
>      to garbage collection, so that ASAs never run out of resources.

Hmm.... This is PL nitpickery again, but many languages don't have
garbage collection. Perhaps you mean "memory management"


S 9.1.

>      Here, we assume that all systems involved in an autonomic network are
>      secured and operated according to best current practices.  These
>      protection methods comprise traditional security implementation and
>      operation methods (such as code security, strong randomization
>      algorithms, strong passwords, etc.) as well as mechanisms specific to

"randomization" is a term of art here that means that the algorithms
are randomized (as in randomized hashing) not that you generate strong
random numbers.


S 9.1.
>      valuable information about network configuration, security
>      precautions in use, individual users, and their traffic patterns.  If
>      encrypted, AN messages might still reveal some information via
>      traffic analysis, but this would be quite limited (for example, this
>      would be highly unlikely to reveal any specific information about
>      user traffic).

Don't bet on this. Traffic analysis is very powerful.


S 9.2.
>        AN or other protocols.  Also this is a generic threat that applies
>        to all network solutions.

>      The above threats are in principle comparable to other solutions: In
>      the presence of design, implementation or operational errors,
>      security is no longer guaranteed.  However, the distributed nature of

This isn't obvious to me. The issue here is that control of one non-
privileged device might let you affect others. That wouldn't be true
of centrally managed systems.
2018-10-24
08 Eric Rescorla [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla
2018-10-13
08 Ignas Bagdonas IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2018-10-11
08 Joel Halpern Request for Telechat review by GENART Completed: Ready with Nits. Reviewer: Joel Halpern. Sent review to list.
2018-10-11
08 Jean Mahoney Request for Telechat review by GENART is assigned to Joel Halpern
2018-10-11
08 Jean Mahoney Request for Telechat review by GENART is assigned to Joel Halpern
2018-10-08
08 (System) IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2018-10-08
08 Cindy Morgan Placed on agenda for telechat - 2018-10-25
2018-10-08
08 Ignas Bagdonas IESG state changed to Waiting for AD Go-Ahead from Waiting for Writeup
2018-10-08
08 Ignas Bagdonas Ballot has been issued
2018-10-08
08 Ignas Bagdonas [Ballot Position Update] New position, Yes, has been recorded for Ignas Bagdonas
2018-10-08
08 Ignas Bagdonas Created "Approve" ballot
2018-10-08
08 Ignas Bagdonas Ballot writeup was changed
2018-10-08
08 Ignas Bagdonas Ballot writeup was changed
2018-10-04
08 Michael Behringer New version available: draft-ietf-anima-reference-model-08.txt
2018-10-04
08 (System) New version approved
2018-10-04
08 (System) Request for posting confirmation emailed to previous authors: anima-chairs@ietf.org, Laurent Ciavaglia , Michael Behringer , Toerless Eckert , Brian Carpenter , Jeferson Nobre
2018-10-04
08 Michael Behringer Uploaded new revision
2018-08-26
07 Christian Hopps Request for Telechat review by RTGDIR Completed: Has Issues. Reviewer: Christian Hopps. Sent review to list.
2018-08-24
07 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2018-08-24
07 Michael Behringer New version available: draft-ietf-anima-reference-model-07.txt
2018-08-24
07 (System) New version approved
2018-08-24
07 (System) Request for posting confirmation emailed to previous authors: anima-chairs@ietf.org, Laurent Ciavaglia , Michael Behringer , Toerless Eckert , Brian Carpenter , Jeferson Nobre
2018-08-24
07 Michael Behringer Uploaded new revision
2018-08-23
06 Tero Kivinen Request for Last Call review by SECDIR Completed: Ready. Reviewer: Radia Perlman.
2018-08-21
06 (System) IESG state changed to Waiting for Writeup from In Last Call
2018-08-19
06 Tianran Zhou Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Tianran Zhou. Sent review to list.
2018-08-13
06 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2018-08-13
06 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-anima-reference-model-06, which is currently in Last Call, and has the following comments:

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

The IANA Functions Operator has reviewed draft-ietf-anima-reference-model-06, which is currently in Last Call, and has the following comments:

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

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

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

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2018-08-09
06 Joel Halpern Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Joel Halpern. Sent review to list.
2018-08-09
06 Tero Kivinen Request for Last Call review by SECDIR is assigned to Radia Perlman
2018-08-09
06 Tero Kivinen Request for Last Call review by SECDIR is assigned to Radia Perlman
2018-08-09
06 Jean Mahoney Request for Last Call review by GENART is assigned to Joel Halpern
2018-08-09
06 Jean Mahoney Request for Last Call review by GENART is assigned to Joel Halpern
2018-08-09
06 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tianran Zhou
2018-08-09
06 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tianran Zhou
2018-08-09
06 Jonathan Hardwick Request for Telechat review by RTGDIR is assigned to Christian Hopps
2018-08-09
06 Jonathan Hardwick Request for Telechat review by RTGDIR is assigned to Christian Hopps
2018-08-09
06 Alvaro Retana Requested Telechat review by RTGDIR
2018-08-07
06 Cindy Morgan IANA Review state changed to IANA - Review Needed
2018-08-07
06 Cindy Morgan
The following Last Call announcement was sent out (ends 2018-08-21):

From: The IESG
To: IETF-Announce
CC: ibagdona@gmail.com, draft-ietf-anima-reference-model@ietf.org, Toerless Eckert , anima-chairs@ietf.org, …
The following Last Call announcement was sent out (ends 2018-08-21):

From: The IESG
To: IETF-Announce
CC: ibagdona@gmail.com, draft-ietf-anima-reference-model@ietf.org, Toerless Eckert , anima-chairs@ietf.org, Sheng Jiang , anima@ietf.org, jiangsheng@huawei.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (A Reference Model for Autonomic Networking) to Informational RFC


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

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

Abstract


  This document describes a reference model for Autonomic Networking.
  It defines the behaviour of an autonomic node, how the various
  elements in an autonomic context work together, and how autonomic
  services can use the infrastructure.




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

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-anima-reference-model/ballot/


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




2018-08-07
06 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2018-08-07
06 Ignas Bagdonas Last call was requested
2018-08-07
06 Ignas Bagdonas Last call announcement was generated
2018-08-07
06 Ignas Bagdonas Ballot approval text was generated
2018-08-07
06 Ignas Bagdonas Ballot writeup was generated
2018-08-07
06 Ignas Bagdonas IESG state changed to Last Call Requested from AD Evaluation
2018-06-14
06 Ignas Bagdonas IESG state changed to AD Evaluation from Publication Requested
2018-05-06
06 Sheng Jiang Intended Status changed to Informational from None
2018-05-06
06 Sheng Jiang
draft-ietf-anima-autonomic-reference-model-06 write-up

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the proper type …
draft-ietf-anima-autonomic-reference-model-06 write-up

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

  Informational. The document describes a reference model for Autonomic
  Networking. It defines the behaviour of an autonomic node, how the various
  elements in an autonomic context work together, and how autonomic services
  can use the infrastructure. It is the proper type of RFC and obey the WG
  charter. The type is indicated in the title page header.

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

Technical Summary:
Relevant content can frequently be found in the abstract?
and/or introduction of the document. If not, this may be?
an indication that there are deficiencies in the abstract?
or introduction.

  The document describes a reference model for Autonomic Networking. It defines
  the behaviour of an autonomic node, how the various elements in an autonomic
  context work together, and how autonomic services can use the infrastructure.

Working Group Summary:
Was there anything in WG process that is worth noting? For example,
was there controversy about particular points or were there decisions
where the consensus was particularly rough??

  This document was called draft-behringer-anima-reference-model prior to its
  WG adoption. There was unanimous support for it in favor of adoption and
  none against, so this document was adopted in December 2015. There was
  interest in this work posts since its adoption. There was never any
  opposition for this work.

  This document went through a relevant long document development
  period (12 months for individual document period, 26 month for WG
  document period). It has been reviewed well.

Document Quality:
Are there existing implementations of the protocol? Have a significant
number of vendors indicated their plan to implement the specification?
Are there any reviewers that merit special mention as having done a?
thorough review, e.g., one that resulted in important changes or a?
conclusion that the document had no substantive issues? If there was
a MIB Doctor, Media Type or other expert review, what was its course
(briefly)? In the case of a Media Type review, on what date was the?
request posted??

  This document went through multiple reviews by multiple participants.
  So far, there is no existing implementations, which is not needed as
  an Informational document.

Personnel:

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

  Sheng Jiang is the document shepherd.
  Ignas Bagdonas is the responsible AD.

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

  I reviewed this document thorough once for -05 versions (and had
  other minor comments from time to time):

  https://www.ietf.org/mail-archive/web/anima/current/msg03292.html

  The issues raised in my reviews were promptly addressed by authors
  in -06 version along with the comments from other ANIMA WG members.
  This document -06 version is ready for publication in my opinion.

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

  No.

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

  No.

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

  There are no outstanding issues.

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

  Yes. The authors, Michael H. Behringer, Brian Carpenter,Toerless Eckert,
  Laurent Ciavaglia and Jeferson Campos Nobre have confirmed in writing that
  they are not aware of any IPR, and that any and all appropriate IPR
  disclosures required for full conformance with the provisions of BCP 78 and
  BCP 79 have already been filed.

(8) Has an IPR disclosure been filed that references this document? If so,
summarize any WG discussion and conclusion regarding the IPR disclosures.

  No.

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

  There was broad support for this document. It was reviewed by active WG
  participants.

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

  No. There was unanimous support for this work and nobody raised any objections.

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

  This document is now ID nits free.

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

  No MIB Doctor, media type, URI type or similar apply to this document.

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

  Yes.

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

  The three normative references are other ANIMA WG documents and they were
  sent to IESG for publishing before shepherding this document. They should
  not be hinders for publishing this document as RFC.

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

  No.

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

  No. This document does not update any existing RFCs.

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

  No. There is no IANA action requested by this document.

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

  No such registry is requested in this document.

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

  There are no such parts to the document.
2018-05-06
06 Sheng Jiang Responsible AD changed to Ignas Bagdonas
2018-05-06
06 Sheng Jiang IETF WG state changed to Submitted to IESG for Publication from WG Document
2018-05-06
06 Sheng Jiang IESG state changed to Publication Requested
2018-05-06
06 Sheng Jiang IESG process started in state Publication Requested
2018-02-23
06 Michael Behringer New version available: draft-ietf-anima-reference-model-06.txt
2018-02-23
06 (System) New version approved
2018-02-23
06 (System)
Request for posting confirmation emailed to previous authors: anima-chairs@ietf.org, John Strassner , Peloso Pierre , Michael Behringer , Toerless Eckert , Laurent Ciavaglia , …
Request for posting confirmation emailed to previous authors: anima-chairs@ietf.org, John Strassner , Peloso Pierre , Michael Behringer , Toerless Eckert , Laurent Ciavaglia , Jeferson Nobre , Bing Liu , Brian Carpenter
2018-02-23
06 Michael Behringer Uploaded new revision
2017-10-19
05 Michael Behringer New version available: draft-ietf-anima-reference-model-05.txt
2017-10-19
05 (System) New version approved
2017-10-19
05 (System)
Request for posting confirmation emailed to previous authors: anima-chairs@ietf.org, John Strassner , Peloso Pierre , Michael Behringer , Toerless Eckert , Laurent Ciavaglia , …
Request for posting confirmation emailed to previous authors: anima-chairs@ietf.org, John Strassner , Peloso Pierre , Michael Behringer , Toerless Eckert , Laurent Ciavaglia , Jeferson Nobre , Bing Liu , Brian Carpenter
2017-10-19
05 Michael Behringer Uploaded new revision
2017-07-06
04 Sheng Jiang Notification list changed to Toerless Eckert <tte+anima@cs.fau.de>, Sheng Jiang <jiangsheng@huawei.com> from Toerless Eckert <tte+anima@cs.fau.de>
2017-07-06
04 Sheng Jiang Document shepherd changed to Sheng Jiang
2017-07-06
04 Sheng Jiang IETF WG state changed to WG Document from In WG Last Call
2017-07-06
04 Sheng Jiang Notification list changed to Toerless Eckert <tte+anima@cs.fau.de>
2017-07-06
04 Sheng Jiang Document shepherd changed to Toerless Eckert
2017-07-06
04 Sheng Jiang start June 27th, 2017; end  July 10th, 2017. two weeks
2017-07-06
04 Sheng Jiang IETF WG state changed to In WG Last Call from WG Document
2017-07-03
04 Michael Behringer New version available: draft-ietf-anima-reference-model-04.txt
2017-07-03
04 (System) New version approved
2017-07-03
04 (System)
Request for posting confirmation emailed to previous authors: Michael Behringer , John Strassner , Peloso Pierre , anima-chairs@ietf.org, Toerless Eckert , Laurent Ciavaglia , …
Request for posting confirmation emailed to previous authors: Michael Behringer , John Strassner , Peloso Pierre , anima-chairs@ietf.org, Toerless Eckert , Laurent Ciavaglia , Jeferson Nobre , Bing Liu , Brian Carpenter
2017-07-03
04 Michael Behringer Uploaded new revision
2017-03-13
03 Michael Behringer New version available: draft-ietf-anima-reference-model-03.txt
2017-03-13
03 (System) New version approved
2017-03-13
03 (System)
Request for posting confirmation emailed to previous authors: =?utf-8?q?J=C3=A9ferson_Nobre?= , Michael Behringer , anima-chairs@ietf.org, Toerless Eckert , Peloso Pierre , Laurent Ciavaglia , John …
Request for posting confirmation emailed to previous authors: =?utf-8?q?J=C3=A9ferson_Nobre?= , Michael Behringer , anima-chairs@ietf.org, Toerless Eckert , Peloso Pierre , Laurent Ciavaglia , John Strassner , Bing Liu , Brian Carpenter
2017-03-13
03 Michael Behringer Uploaded new revision
2017-01-09
02 (System) Document has expired
2016-11-15
02 Sheng Jiang Added to session: IETF-97: anima  Wed-0930
2016-11-15
02 Sheng Jiang Removed from session: IETF-97: anima  Fri-0930
2016-11-15
02 Sheng Jiang Added to session: IETF-97: anima  Fri-0930
2016-07-08
02 Michael Behringer New version available: draft-ietf-anima-reference-model-02.txt
2016-04-04
01 Sheng Jiang This document now replaces draft-behringer-anima-reference-model instead of None
2016-03-21
01 Michael Behringer New version available: draft-ietf-anima-reference-model-01.txt
2016-01-11
00 Michael Behringer New version available: draft-ietf-anima-reference-model-00.txt