A Reference Model for Autonomic Networking
draft-ietf-anima-reference-model-10
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
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 |