Using an Autonomic Control Plane for Stable Connectivity of Network Operations, Administration, and Maintenance (OAM)
draft-ietf-anima-stable-connectivity-10
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2018-05-08
|
10 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2018-04-02
|
10 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2018-04-02
|
10 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2018-03-27
|
10 | (System) | RFC Editor state changed to EDIT from AUTH |
2018-03-26
|
10 | (System) | RFC Editor state changed to AUTH from EDIT |
2018-03-13
|
10 | Bernie Volz | Closed request for Last Call review by INTDIR with state 'No Response' |
2018-02-12
|
10 | (System) | IANA Action state changed to No IC from In Progress |
2018-02-12
|
10 | (System) | IANA Action state changed to In Progress |
2018-02-12
|
10 | (System) | RFC Editor state changed to EDIT |
2018-02-12
|
10 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2018-02-12
|
10 | (System) | Announcement was received by RFC Editor |
2018-02-12
|
10 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2018-02-12
|
10 | Amy Vezza | IESG has approved the document |
2018-02-12
|
10 | Amy Vezza | Closed "Approve" ballot |
2018-02-12
|
10 | Amy Vezza | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2018-02-12
|
10 | Amy Vezza | Ballot approval text was generated |
2018-02-09
|
10 | Mirja Kühlewind | [Ballot comment] Thanks for addressing my discuss by rather describing requirements for the transport than scratching out an MPTCP-based solution! I like the new text! … [Ballot comment] Thanks for addressing my discuss by rather describing requirements for the transport than scratching out an MPTCP-based solution! I like the new text! Also thanks again to Yoshi for the TSV review! |
2018-02-09
|
10 | Mirja Kühlewind | [Ballot Position Update] Position for Mirja Kühlewind has been changed to No Objection from Discuss |
2018-02-05
|
10 | Toerless Eckert | New version available: draft-ietf-anima-stable-connectivity-10.txt |
2018-02-05
|
10 | (System) | New version approved |
2018-02-05
|
10 | (System) | Request for posting confirmation emailed to previous authors: anima-chairs@ietf.org, Toerless Eckert , Michael Behringer |
2018-02-05
|
10 | Toerless Eckert | Uploaded new revision |
2018-01-26
|
09 | Toerless Eckert | New version available: draft-ietf-anima-stable-connectivity-09.txt |
2018-01-26
|
09 | (System) | New version approved |
2018-01-26
|
09 | (System) | Request for posting confirmation emailed to previous authors: anima-chairs@ietf.org, Toerless Eckert , Michael Behringer |
2018-01-26
|
09 | Toerless Eckert | Uploaded new revision |
2018-01-18
|
08 | Alvaro Retana | [Ballot Position Update] Position for Alvaro Retana has been changed to Yes from Discuss |
2018-01-16
|
08 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2018-01-16
|
08 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2018-01-16
|
08 | Toerless Eckert | New version available: draft-ietf-anima-stable-connectivity-08.txt |
2018-01-16
|
08 | (System) | New version approved |
2018-01-16
|
08 | (System) | Request for posting confirmation emailed to previous authors: anima-chairs@ietf.org, Toerless Eckert , Michael Behringer |
2018-01-16
|
08 | Toerless Eckert | Uploaded new revision |
2018-01-11
|
07 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2018-01-11
|
07 | Alissa Cooper | [Ballot comment] The Gen-ART reviewer identified a bunch of nits that should be addressed. |
2018-01-11
|
07 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2018-01-10
|
07 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2018-01-10
|
07 | Eric Rescorla | [Ballot comment] secure ACP was extendable via untrusted routers then it would be a lot more verify the secure domain assertion. Therefore the ACP … [Ballot comment] secure ACP was extendable via untrusted routers then it would be a lot more verify the secure domain assertion. Therefore the ACP edge devices are not supposed to redistribute routes from non-ACP routers There's something grammatically wrong here and I can't make sense of this sentence. TLS/DTLS ([RFC5246])/([RFC6347]) with mutual AN-domain certificate authentication - and does not incur new key management. This isn't entirely clear to me. What are the identities that these devices are using to talk to each other? Are they always FQDNs? into IPv4 support for ACP will have a longer term benefit or enough critical short-term use-cases. Support for IPv4-only for ACP is purely a strategic choice to focus on the known important long term I think this probably should say IPv6 only address collision even though there is no central assignment authority. This is helped by the expectation, that ACPs are never expected to connect all together, but only few ACPs may ever need to Nit: no comma between "expectation" and "that" ACP packets can be recognized to come from you, you may need to list your prefixes in multiple of those sites. As I read this, it helps others to list, not yourself, right? Any current and future protocols must rely on secure end-to-end communications (TLS/DTLS) and identification and authentication via This looks normative. Should it be MUST? |
2018-01-10
|
07 | Eric Rescorla | [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla |
2018-01-10
|
07 | Suresh Krishnan | [Ballot comment] * The first paragraph of Section 2.1.4. is extremely difficult to read and the sentences seem incomplete/malformed. Please consider rewording " ACP does … [Ballot comment] * The first paragraph of Section 2.1.4. is extremely difficult to read and the sentences seem incomplete/malformed. Please consider rewording " ACP does not support IPv4: Single stack IPv6 management of the network via ACP and (as needed) data plane. Independent of whether the data plane is dual-stack, has IPv4 as a service or is single stack IPv6. Dual plane management, IPv6 for ACP, IPv4 for the data plane is likewise an architecturally simple option." |
2018-01-10
|
07 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2018-01-10
|
07 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2018-01-10
|
07 | Ben Campbell | [Ballot comment] I am skeptical that there are no normative references at all. Is it reasonable that a reader could skip all the references and … [Ballot comment] I am skeptical that there are no normative references at all. Is it reasonable that a reader could skip all the references and still fully understand this document? |
2018-01-10
|
07 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2018-01-10
|
07 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2018-01-10
|
07 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2018-01-10
|
07 | Carlos Martínez | Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Carlos Martinez. Sent review to list. |
2018-01-09
|
07 | Yoshifumi Nishida | Request for Telechat review by TSVART Completed: Almost Ready. Reviewer: Yoshifumi Nishida. |
2018-01-08
|
07 | Martin Stiemerling | Request for Telechat review by TSVART is assigned to Yoshifumi Nishida |
2018-01-08
|
07 | Martin Stiemerling | Request for Telechat review by TSVART is assigned to Yoshifumi Nishida |
2018-01-05
|
07 | Mirja Kühlewind | Requested Telechat review by TSVART |
2018-01-05
|
07 | Mirja Kühlewind | [Ballot discuss] Section 2.1.5 talks about use of MPTCP: "DNS naming is set up to provide the ACP IPv6 address of network devices. Unbeknownst … [Ballot discuss] Section 2.1.5 talks about use of MPTCP: "DNS naming is set up to provide the ACP IPv6 address of network devices. Unbeknownst to the application, MPTCP is used. MPTCP mutually discovers between the NOC and network device the data-plane address and caries all traffic across it when that MPTCP subflow across the data-plane can be built." However, I'm actually uncertain how this is supposed to work and what "Unbeknownst to the application" should mean. If another address should be signaled to the other host, this needs to be indicated by the application or at least some kind of policy framework above MPTCP. Also MPTCP will by default use both paths simultaneously while still looking like one connection to the application, meaning the application has no control which path is used for which traffic. I guess you can open a second subflow and then configure the first subflow as backup path but I'm not sure if that's what you want (given the application/policy framework will still not know which path is used)..? Please provide more information about what the expected usage scenario is here. |
2018-01-05
|
07 | Mirja Kühlewind | [Ballot Position Update] Position for Mirja Kühlewind has been changed to Discuss from No Record |
2018-01-05
|
07 | Mirja Kühlewind | [Ballot comment] Section 2.1.5 says: "DNS naming is set up to provide the ACP IPv6 address of network devices. Unbeknownst to the application, MPTCP … [Ballot comment] Section 2.1.5 says: "DNS naming is set up to provide the ACP IPv6 address of network devices. Unbeknownst to the application, MPTCP is used. MPTCP mutually discovers between the NOC and network device the data-plane address and caries all traffic across it when that MPTCP subflow across the data-plane can be built." However I'm actally uncertain how this is supposed to work and what "Unbeknownst to the application" should mean. If another address should be signaled to the other host, this needs to be configured by the application. Also MPTCP will use both paths simulatinuously while still looking like one connestion to the application. I think want you want to a new, second TCP connection to carry all the OAM traffic. You cannot/should not use MPTCP for that. I guess you can open a second subflow and the close the first subflow but I'm not sue if that's what you want either..? |
2018-01-05
|
07 | Mirja Kühlewind | Ballot comment text updated for Mirja Kühlewind |
2018-01-05
|
07 | Mirja Kühlewind | [Ballot comment] Section 2.1.5 says: "DNS naming is set up to provide the ACP IPv6 address of network devices. Unbeknownst to the application, MPTCP … [Ballot comment] Section 2.1.5 says: "DNS naming is set up to provide the ACP IPv6 address of network devices. Unbeknownst to the application, MPTCP is used. MPTCP mutually discovers between the NOC and network device the data-plane address and caries all traffic across it when that MPTCP subflow across the data-plane can be built." However I'm actally uncertain how this is supposed to work and what "Unbeknownst to the application" should mean. If another address should be signaled to the other host, this needs to be configured by the application. Also MPTCP will use both paths simulatinuously while still looking like one connestion to the application. I think want you want to a new, second TCP connection to carry all the OAM traffic. You cannot/should not use MPTCP for that. I guess you can open a second subflow and the close the first subflow but I'm not if that's what you want either..? |
2018-01-05
|
07 | Mirja Kühlewind | Ballot comment text updated for Mirja Kühlewind |
2018-01-04
|
07 | Alvaro Retana | [Ballot discuss] I like this document, and look forward to it being published. However, it caught my attention that there are no Normative References. It … [Ballot discuss] I like this document, and look forward to it being published. However, it caught my attention that there are no Normative References. It seems clear to me that (at least) an understanding of the ACP is necessary to properly achieve the objective of the document: "how to integrate OAM processes with the autonomic control plane (ACP) in Autonomic Networks (AN) in order to provide stable and secure connectivity for those OAM processes." I then think that the reference to I-D.ietf-anima-autonomic-control-plane should be Normative. |
2018-01-04
|
07 | Alvaro Retana | [Ballot Position Update] New position, Discuss, has been recorded for Alvaro Retana |
2018-01-03
|
07 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2017-12-13
|
07 | Francesca Palombini | Request for Last Call review by IOTDIR Completed: Ready with Nits. Reviewer: Francesca Palombini. Sent review to list. |
2017-12-11
|
07 | Ari Keränen | Request for Last Call review by IOTDIR is assigned to Francesca Palombini |
2017-12-11
|
07 | Ari Keränen | Request for Last Call review by IOTDIR is assigned to Francesca Palombini |
2017-12-10
|
07 | Terry Manderson | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2017-12-10
|
07 | Terry Manderson | Placed on agenda for telechat - 2018-01-11 |
2017-12-10
|
07 | Terry Manderson | Ballot has been issued |
2017-12-10
|
07 | Terry Manderson | [Ballot Position Update] New position, Yes, has been recorded for Terry Manderson |
2017-12-10
|
07 | Terry Manderson | Created "Approve" ballot |
2017-12-10
|
07 | Terry Manderson | Ballot writeup was changed |
2017-12-10
|
07 | Terry Manderson | Changed consensus to Yes from Unknown |
2017-12-10
|
07 | Terry Manderson | IESG state changed to Waiting for AD Go-Ahead from Waiting for Writeup |
2017-11-27
|
07 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Magnus Nystrom. |
2017-11-26
|
07 | Matthew Miller | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Matthew Miller. Sent review to list. |
2017-11-26
|
07 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2017-11-21
|
07 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Carlos Martinez |
2017-11-21
|
07 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Carlos Martinez |
2017-11-18
|
07 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Magnus Nystrom |
2017-11-18
|
07 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Magnus Nystrom |
2017-11-16
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Matthew Miller |
2017-11-16
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Matthew Miller |
2017-11-15
|
07 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2017-11-12
|
07 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2017-11-12
|
07 | Cindy Morgan | The following Last Call announcement was sent out (ends 2017-11-26): From: The IESG To: IETF-Announce CC: draft-ietf-anima-stable-connectivity@ietf.org, anima-chairs@ietf.org, Sheng Jiang , terry.manderson@icann.org, … The following Last Call announcement was sent out (ends 2017-11-26): From: The IESG To: IETF-Announce CC: draft-ietf-anima-stable-connectivity@ietf.org, anima-chairs@ietf.org, Sheng Jiang , terry.manderson@icann.org, anima@ietf.org, jiangsheng@huawei.com Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Using Autonomic Control Plane for Stable Connectivity of Network OAM) to Informational RFC The IESG has received a request from the Autonomic Networking Integrated Model and Approach WG (anima) to consider the following document: - 'Using Autonomic Control Plane for Stable Connectivity of Network OAM' 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 2017-11-26. 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 OAM (Operations, Administration and Maintenance - as per BCP161, (RFC6291) processes for data networks are often subject to the problem of circular dependencies when relying on connectivity provided by the network to be managed for the OAM purposes. 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. This document describes how to integrate OAM processes with the autonomic control plane (ACP) in Autonomic Networks (AN) in order to provide stable and secure connectivity for those OAM processes. This connectivity is not subject to aforementioned circular dependencies. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-anima-stable-connectivity/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-anima-stable-connectivity/ballot/ No IPR declarations have been submitted directly on this I-D. |
2017-11-12
|
07 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2017-11-12
|
07 | Bernie Volz | Request for Last Call review by INTDIR is assigned to DENG Hui |
2017-11-12
|
07 | Bernie Volz | Request for Last Call review by INTDIR is assigned to DENG Hui |
2017-11-12
|
07 | Terry Manderson | Requested Last Call review by IOTDIR |
2017-11-12
|
07 | Terry Manderson | Requested Last Call review by INTDIR |
2017-11-12
|
07 | Terry Manderson | Requested Last Call review by SECDIR |
2017-11-12
|
07 | Terry Manderson | Last call was requested |
2017-11-12
|
07 | Terry Manderson | Ballot approval text was generated |
2017-11-12
|
07 | Terry Manderson | Ballot writeup was generated |
2017-11-12
|
07 | Terry Manderson | IESG state changed to Last Call Requested from Publication Requested |
2017-11-12
|
07 | Terry Manderson | Last call announcement was generated |
2017-10-21
|
07 | Sheng Jiang | Tag Doc Shepherd Follow-up Underway cleared. |
2017-10-21
|
07 | Sheng Jiang | Document Writeup, template from IESG area on ietf.org, dated October 21, 2017. draft-ietf-anima-stable-connectivity-07 write-up (1) What type of RFC is being requested (BCP, Proposed … Document Writeup, template from IESG area on ietf.org, dated October 21, 2017. draft-ietf-anima-stable-connectivity-07 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 how to integrate OAM processes with the autonomic control plane (ACP) in Autonomic Networks (AN) in order to provide stable and secure connectivity for those OAM processes. The type clearly of RFC 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. This document describes how to integrate OAM processes with the autonomic control plane (ACP) in Autonomic Networks (AN) in order to provide stable and secure connectivity for those OAM processes. 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-eckert-anima-stable-connectivity prior to its 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, 22 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. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Sheng Jiang is the document shepherd. Terry Manderson 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 -02 versions (and had other minor comments from time to time): https://www.ietf.org/mail-archive/web/anima/current/msg02777.html The issues raised in my reviews were promptly addressed by authors in -03 and -04 version along with the comments from other ANIMA WG members. This document -07 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 and Toerless Eckert 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? No. All normative references are published RFCs. (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. This document does not have any IANA consideration as an Informational 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. |
2017-10-21
|
07 | Sheng Jiang | Responsible AD changed to Terry Manderson |
2017-10-21
|
07 | Sheng Jiang | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2017-10-21
|
07 | Sheng Jiang | IESG state changed to Publication Requested |
2017-10-21
|
07 | Sheng Jiang | IESG process started in state Publication Requested |
2017-10-21
|
07 | Sheng Jiang | Changed document writeup |
2017-10-18
|
07 | Toerless Eckert | New version available: draft-ietf-anima-stable-connectivity-07.txt |
2017-10-18
|
07 | (System) | New version approved |
2017-10-18
|
07 | (System) | Request for posting confirmation emailed to previous authors: anima-chairs@ietf.org, Toerless Eckert , Michael Behringer |
2017-10-18
|
07 | Toerless Eckert | Uploaded new revision |
2017-09-17
|
06 | Toerless Eckert | New version available: draft-ietf-anima-stable-connectivity-06.txt |
2017-09-17
|
06 | (System) | New version approved |
2017-09-17
|
06 | (System) | Request for posting confirmation emailed to previous authors: Toerless Eckert , Michael Behringer , anima-chairs@ietf.org |
2017-09-17
|
06 | Toerless Eckert | Uploaded new revision |
2017-08-27
|
05 | Sheng Jiang | waiting for authors' IPR disclosure confirmation and another minor update |
2017-08-27
|
05 | Sheng Jiang | Tag Doc Shepherd Follow-up Underway set. |
2017-08-27
|
05 | Sheng Jiang | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2017-08-02
|
05 | Toerless Eckert | New version available: draft-ietf-anima-stable-connectivity-05.txt |
2017-08-02
|
05 | (System) | New version approved |
2017-08-02
|
05 | (System) | Request for posting confirmation emailed to previous authors: Toerless Eckert , Michael Behringer , anima-chairs@ietf.org |
2017-08-02
|
05 | Toerless Eckert | Uploaded new revision |
2017-07-27
|
04 | Toerless Eckert | New version available: draft-ietf-anima-stable-connectivity-04.txt |
2017-07-27
|
04 | (System) | New version approved |
2017-07-27
|
04 | (System) | Request for posting confirmation emailed to previous authors: Toerless Eckert , Michael Behringer , anima-chairs@ietf.org |
2017-07-27
|
04 | Toerless Eckert | Uploaded new revision |
2017-07-18
|
03 | Sheng Jiang | Started July 15th, will end July 28th |
2017-07-18
|
03 | Sheng Jiang | IETF WG state changed to In WG Last Call from WG Document |
2017-07-03
|
03 | Toerless Eckert | New version available: draft-ietf-anima-stable-connectivity-03.txt |
2017-07-03
|
03 | (System) | New version approved |
2017-07-03
|
03 | (System) | Request for posting confirmation emailed to previous authors: Toerless Eckert , anima-chairs@ietf.org, Michael Behringer |
2017-07-03
|
03 | Toerless Eckert | Uploaded new revision |
2017-02-08
|
02 | Sheng Jiang | Notification list changed to "Sheng Jiang" <jiangsheng@huawei.com> |
2017-02-08
|
02 | Sheng Jiang | Document shepherd changed to Sheng Jiang |
2017-02-08
|
02 | Sheng Jiang | Intended Status changed to Informational from None |
2017-02-07
|
02 | Toerless Eckert | New version available: draft-ietf-anima-stable-connectivity-02.txt |
2017-02-07
|
02 | (System) | New version approved |
2017-02-07
|
02 | (System) | Request for posting confirmation emailed to previous authors: anima-chairs@ietf.org, "Toerless Eckert" , "Michael Behringer" |
2017-02-07
|
02 | Toerless Eckert | Uploaded new revision |
2017-01-09
|
01 | (System) | Document has expired |
2016-07-08
|
01 | Toerless Eckert | New version available: draft-ietf-anima-stable-connectivity-01.txt |
2016-01-13
|
00 | Sheng Jiang | This document now replaces draft-eckert-anima-stable-connectivity instead of None |
2016-01-13
|
00 | Toerless Eckert | New version available: draft-ietf-anima-stable-connectivity-00.txt |