A Framework for Automating Service and Network Management with YANG
draft-ietf-opsawg-model-automation-framework-10
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2024-01-26
|
10 | Gunter Van de Velde | Request closed, assignment withdrawn: Jon Mitchell Last Call OPSDIR review |
2024-01-26
|
10 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'Overtaken by Events': Cleaning up stale OPSDIR queue |
2021-01-12
|
10 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2020-12-14
|
10 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2020-11-17
|
10 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2020-10-26
|
10 | (System) | RFC Editor state changed to EDIT |
2020-10-26
|
10 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2020-10-26
|
10 | (System) | Announcement was received by RFC Editor |
2020-10-26
|
10 | Christian Huitema | Request for Telechat review by SECDIR Completed: Ready. Reviewer: Christian Huitema. Sent review to list. |
2020-10-26
|
10 | (System) | IANA Action state changed to No IANA Actions from In Progress |
2020-10-26
|
10 | (System) | IANA Action state changed to In Progress |
2020-10-26
|
10 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent::AD Followup |
2020-10-26
|
10 | Amy Vezza | IESG has approved the document |
2020-10-26
|
10 | Amy Vezza | Closed "Approve" ballot |
2020-10-26
|
10 | Robert Wilton | Ballot approval text was generated |
2020-10-25
|
10 | Mohamed Boucadair | New version available: draft-ietf-opsawg-model-automation-framework-10.txt |
2020-10-25
|
10 | (System) | New version approved |
2020-10-25
|
10 | (System) | Request for posting confirmation emailed to previous authors: Liang Geng , Diego Lopez , Qin WU , Mohamed Boucadair , Chongfeng Xie |
2020-10-25
|
10 | Mohamed Boucadair | Uploaded new revision |
2020-10-23
|
09 | Mohamed Boucadair | New version available: draft-ietf-opsawg-model-automation-framework-09.txt |
2020-10-23
|
09 | (System) | New version approved |
2020-10-23
|
09 | (System) | Request for posting confirmation emailed to previous authors: Diego Lopez , Chongfeng Xie , Qin WU , Liang Geng , Mohamed Boucadair |
2020-10-23
|
09 | Mohamed Boucadair | Uploaded new revision |
2020-10-23
|
08 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2020-10-23
|
08 | Mohamed Boucadair | New version available: draft-ietf-opsawg-model-automation-framework-08.txt |
2020-10-23
|
08 | (System) | New version approved |
2020-10-23
|
08 | (System) | Request for posting confirmation emailed to previous authors: Diego Lopez , Mohamed Boucadair , Chongfeng Xie , Liang Geng , Qin WU |
2020-10-23
|
08 | Mohamed Boucadair | Uploaded new revision |
2020-10-22
|
07 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Christian Huitema |
2020-10-22
|
07 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Christian Huitema |
2020-10-22
|
07 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation |
2020-10-22
|
07 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2020-10-22
|
07 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2020-10-22
|
07 | Murray Kucherawy | [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy |
2020-10-21
|
07 | Benjamin Kaduk | [Ballot comment] Sorry that there are so many editorial nits mixed in with actual content-ful comments. I think they are all marked as such, at … [Ballot comment] Sorry that there are so many editorial nits mixed in with actual content-ful comments. I think they are all marked as such, at least. Section 1 o The lack of standard data input/output (i.e., data model) raises many challenges in system integration and often results in manual configuration tasks. (nit) I feel like this would read better with "interfaces" after "input/output". o Ease data inheritance and reusability among the various architecture layers promoting thus a network-wise provisioning instead of device-specific configuration. nit: this looks better with "thus" and "promoting" swapped. o Dynamically fed a decision-making process (e.g., Controllers, nit: s/fed/feed/. Orchestrators) with notifications that will trigger appropriate actions allowing thus to continuously adjust a network (and thus involved resources) to comply the intended service to deliver. nit: the wording here also feels a bit unusual. Perhaps: % o Dynamically fedd a decision-making process (e.g., Controllers, % Orchestrators) with notifications that will trigger appropriate % actions, allowing them to continuously adjust a network (and % thus, the involved resources) to deliver service that conforms % to the intended parameters. Section 2.2 "AP" should probably be in the list as well. We don't seem to define "PM" as such anywhere (though "Performance Monitoring" appears four or five times), but do use it in Appendix A.4.4. Section 3.1 Each level maintains a view of the supported YANG modules provided by low-levels (see for example, Appendix A). nit(?): "lower levels" Section 3.2 Distributed Denial-of-Service (DDoS) attacks [RFC8783]. The service filtering request modelled using [RFC8783] will be translated into device-specific filtering (e.g., ACLs defined in [RFC8519]) that to fulfil the service request. nit: s/that to/that/ Section 3.3 Note that it is important to correlate telemetry data with configuration data to be used for closed loops at the different stages of service delivery, from resource allocation to service operation, in particular. Is "closed loops" a well-known term in this space? Section 4.1.2 service requirements in the service request can be met (i.e., whether there is sufficient resources that can be allocated with the requested guarantees). nit: s/is/are/ In addition, a customer may require to change the underlying network infrastructure to adapt to new customer's needs and service requirements. This service modification can be issued following the same Service Model used by the service request. I'm not sure I understand what "underlying network infrastructure" means here -- are there supposed to come into being new routers because the customer issues a request in the Service Model? Section 4.1.3 Performance measurement telemetry model can tie with Service or Network Models to monitor network performance or Service Level Agreement. nit: missing article (e.g., "The performance measurement telemetry model"). Section 4.1.4 Service optimization is a technique that gets the configuration of the network updated due to network changes, incidents mitigation, or nit: s/incidents/incident/ Section 4.2.1 configuration models for network elements; the configuration information includes: [...] o Security I think we need some more details than just "Security". Are these security protocols? Security properties? Physical security? What is in or out of scope for being covered by any indicated security mechanisms? Section 4.2.2 For example, a customer creates an interface "eth-0/0/0" but the interface does not physically exist at this point, then configuration data appears in the status but does not appear in datastore. nit: I think this reads better as "if a customer creates" (added "if"). Section 4.2.3 When a configuration is in effect in a device, nit: "the ". Section 4.3 Another example is to map service parameters in the L3SM into Traffic Engineered (TE) tunnel parameter (e.g., Tunnel ID) in TE model and nit: "parameters" plural. Section 5.1 L3NM inherits some of data elements from the L3SM. Nevertheless, the L3NM does not expose some information to the above layer such as the capabilities of an underlying network (which can be used to drive service order handling) or notifications (to notify subscribers about specific events or degradations as per agreed SLAs). Some of this I'm having a bit of trouble putting this bit together -- specifically the "not" in "does not expose". The rest of the text makes it sound like having the Service layer know some capabilities of the underlying network, or receive notifications from network-layer events, will be useful to the Orchestrator. But the text as-is seems to say that such information will not be provided to the Service layer. Section 5.2 3. The customer exchanges with the Orchestrator the connectivity matrix on the abstract node and explicit paths using the TE nit: I think this is still the "abstract node topology". 4. The telemetry model which augments the VN model and corresponding TE tunnel model can be used to subscribe to performance measurement data and notify all the parameter changes and network nit: "notify" takes an object that is the entity receiving the notifications; the current wording as literally written says that "all the parameter changes and network performance changes" will receive notifications; I believe that the intent is that notifications about such changes are delivered to something (the Orchestrator?), so we should instead say "provide notifications about" or specify the actual object of "notify". Section 5.3 actions are defined and correlated with network events (e.g., allow the NETCONF server to send updates only when the value exceeds a certain threshold for the first time, but not again until the threshold is cleared), which constitute an It's perhaps a little risky to mention such threshold-based behavior without mentioning hysteresis as well. the server via YANG Push subscription [RFC8641], monitors state parameters, and takes simple and instant actions when associated event condition on state parameters is met. ECA notifications nit: "an" or "the" associated event condition. Section 6 I agree with the secdir reviewer that it's worth repeating the disclaimer that customer/provider interfaces (and thus, the security considerations thereof) are out of scope for this document. When the service configuration incluedes "security" parameters (see my comment on §4.2.1), it is important to include the relevant information in the monitoring/assurance pipelines so that the correct functioning of the security mechanisms is tracked. In order to prevent leaking sensitive information, special care should be considered when translating between the various layers in Section 4 or when aggregating data retrieved from various sources. It's also important to perform the necessary authentication and authorization checks (more specifically than just "special care") for operations that cross abstraction-layer boundaries. The "confused deputy problem" may be relevant for some of these cases, and is an important topic to mention as well. Section 6.1 providers. The characterization of a service disruption (including, mean time between failures, mean time to repair), the escalation procedure, and penalties are usually documented in contractual agreements (e.g., Section 2.1 of [RFC4176]). Misbehaving peer nit: pedantically, this is saying that Section 2.1 of RFC 4176 is an example of a contracutal agreement; we may want to say "e.g., as described in Section 2.1 of [RFC4176]" instead. Section 6.2 o Some Service Models may include a traffic isolation clause, appropriate technology-specific actions must be enforced at the underlying network (and thus involved network devices) to avoid that such traffic is accessible to non-authorized parties. It may be worth mentioning the potential misconception that a "virtual private network" always provides privacy against an attacker able to tap the network link(s); only some VPN technologies (can be configured to) do so. In some sense, whether such wire-level encryption is in use could be an aspect exposed at the service model layer. Section A.3 o Network Topologies Model: [RFC8345] defines a base model for network topology and inventories. Network topology data include link resource, node resource, and terminate-point resources. nit: probably all three instances should be "resources" plural? Section A.4 Network Element models (Figure 10) are used to describe how a service can be implemented by activating and tweaking a set of functions (enabled in one or multiple devices, or hosted in cloud infrastructures) that are involved in the service delivery. I don't really see how Figure 10 helps demonstrate *how* "a service can be implemented by activating and tweaking a set of functions"; it seems to just be a listing/categorization of things that have YANG models. |
2020-10-21
|
07 | Benjamin Kaduk | [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk |
2020-10-21
|
07 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2020-10-21
|
07 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2020-10-20
|
07 | Erik Kline | [Ballot comment] [[ nits ]] [ section 1 ] * "processing of customer's" -> "processing of customer", perhaps * The colon-delimited sentence ending the paragraph … [Ballot comment] [[ nits ]] [ section 1 ] * "processing of customer's" -> "processing of customer", perhaps * The colon-delimited sentence ending the paragraph doesn't seem to imply that list is what should logically follow. I think the sentence aims to imply that in-house and silo nature of existing work has lead the some challenges, including the ones listed. I think a slight reword might fix this up pretty easily. * "between a NETCONF/RESTCONF clients and servers" -> "between NETCONF/RESTCONF clients and servers" * "YANG is transport independent" -> "YANG is a transport-independent" * "model composing" -> "model composition" perhaps? * "out of the scope" -> "out of scope" [ section 3.2 ] * "that to fulfil the service request"? perhaps "that fulfill the service request"? [ section 3.4 ] * "to support newly added module", suggest either: "to support newly added modules" or "to support a newly added module" (probably the former, given subsequent "and features") [ section 4.2.4 ] * "or network resources be mis-allocated" -> "or network resources might be mis-allocated" |
2020-10-20
|
07 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2020-10-20
|
07 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2020-10-20
|
07 | Roman Danyliw | [Ballot comment] Thank you for responding to the SECDIR Review (and thank you to Christian Huitema for providing the review) Focusing primarily on Section 3 … [Ballot comment] Thank you for responding to the SECDIR Review (and thank you to Christian Huitema for providing the review) Focusing primarily on Section 3 and 4 (and ignoring the examples in Section 5), I didn’t find much guidance on using YANG as was suggested by the introductory materials. ** Section 3.1. Figure 2 notes “full guarantees class” and “delay guarantees class” which seems to speak to a particular class of traffic, but I didn’t follow what these were. ** Section 6. Per “ The YANG modules cited in this document define schema for data that are designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]”, this seems to conflict with Section 1 which reminds us that “any of the YANG modules listed in this document are used to exchange data between a NETCONF/RESTCONF clients and servers [RFC6241][RFC8040]. Nevertheless, YANG is transport independent data modeling language. It can thus be used independently of NETCONF/RESTOCNF.” To be clear, the behavior described in the latter is not part of this architecture? ** Section 6. The following architectural assumptions seem to conflict: -- Section 3.1, “All these elements (i.e., Orchestrator(s), Controller(s), device(s)) are under the responsibility of the same operator. -- Section 6.1. “A provider may rely on services offered by other providers to build composite services.” Is the assumption that “under the responsibility of” to include contractual arrangement with the service provider? ** Section 6. Per “In order to prevent leaking sensitive information, special care should be considered when translating between the various layers in Section 4 or when aggregating data retrieved from various sources.”, agreed. However, as Section 6.1. suggests that services from other providers may also be used, this caution should extend to be both in the layer and inter and intra layers. ** Editorial Nits Section 1. Editorial. s/Dynamically fed/Dynamically feed/ Section 3.1. Typo. s/Connectivty/Connectivity/ Section 3.3. Typo. s/Fullfillment/Fulfillment/ |
2020-10-20
|
07 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2020-10-20
|
07 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2020-10-19
|
07 | Éric Vyncke | [Ballot comment] Thank you for the work put into this document. Please find below a couple of non-blocking COMMENT points and nits. I hope that … [Ballot comment] Thank you for the work put into this document. Please find below a couple of non-blocking COMMENT points and nits. I hope that this helps to improve the document, Regards, -éric == COMMENTS == A generic comment: it hurts my eyes to see several occurrences of "NAT" as a service in an IETF document in 2020... Should there be a reference to draft-claise-opsawg-service-assurance-architecture (albeit not yet an adopted document) ? There are a lot of detailed service creations with a good decomposition of all the required steps; but, little is written on the importance of YANG models (as opposed to any standard data exchange), so, the current title seems a little misleading. -- Abstract -- To be honest, I fail to understand why data models can be used to 'derive' configuration information. Did the authors mean 'describe' or 'specify' ? Later "This document describes an architecture" while the title of this document if "framework" ? Slight semantic difference ;-) And later "accommodate modules that", is it 'YANG modules' or 'data models' ? -- Section 4 -- The complex figure 4 would benefit from some textual introduction referring to the subsections. Also, the meaning of the arrow would gain if specified. E.g., why "Service Diagnosis" does not have a loop back to optimization or assurance ? -- Section 4.2.2 -- If not mistaken, this is the first appearance of the notation "". Do the angle brackets have a specific meaning? -- Section 4.2.3 -- Suggestion to use the figure 4 wording as the title esp. since the wording of MDT is not really used in the sub-section. -- Section 6 -- Is it required/useful to have the 'standard YANG security considerations" in this document that does not contain any YANG module? -- Section 10.1 -- Most of the references should probably be informational only. == NITS == Generic nit, I found the use of capitalized "Service Model" or "Network Models" a little disturbing. -- Section 1 -- "how different layer YANG data models" is rather difficult to parse, suggest to rephrase it. -- Section 4.4 -- Is it "service decomposing" or "service decomposition" ? |
2020-10-19
|
07 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2020-10-15
|
07 | Amanda Baber | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2020-10-13
|
07 | Martin Duke | [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke |
2020-10-12
|
07 | Amy Vezza | Placed on agenda for telechat - 2020-10-22 |
2020-10-12
|
07 | Robert Wilton | IESG state changed to IESG Evaluation from Waiting for Writeup |
2020-10-12
|
07 | Robert Wilton | Changed consensus to Yes from Unknown |
2020-10-12
|
07 | Robert Wilton | Ballot has been issued |
2020-10-12
|
07 | Robert Wilton | [Ballot Position Update] New position, Yes, has been recorded for Robert Wilton |
2020-10-12
|
07 | Robert Wilton | Created "Approve" ballot |
2020-10-12
|
07 | Robert Wilton | Ballot writeup was changed |
2020-10-12
|
07 | Robert Wilton | Ballot approval text was generated |
2020-10-12
|
07 | Ines Robles | Request for Last Call review by GENART Completed: Ready. Reviewer: Ines Robles. Review has been revised by Ines Robles. |
2020-10-11
|
07 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2020-10-11
|
07 | Mohamed Boucadair | New version available: draft-ietf-opsawg-model-automation-framework-07.txt |
2020-10-11
|
07 | (System) | New version approved |
2020-10-11
|
07 | (System) | Request for posting confirmation emailed to previous authors: Mohamed Boucadair , Liang Geng , Qin WU , Diego Lopez , Chongfeng Xie |
2020-10-11
|
07 | Mohamed Boucadair | Uploaded new revision |
2020-10-08
|
06 | Ines Robles | Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Ines Robles. Sent review to list. |
2020-10-08
|
06 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2020-10-06
|
06 | Tommy Pauly | Request for Last Call review by TSVART Completed: Ready with Issues. Reviewer: Tommy Pauly. Sent review to list. |
2020-10-03
|
06 | Christian Huitema | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Christian Huitema. Sent review to list. |
2020-10-02
|
06 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2020-10-02
|
06 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-opsawg-model-automation-framework-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-opsawg-model-automation-framework-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 |
2020-10-02
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Ines Robles |
2020-10-02
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Ines Robles |
2020-09-28
|
06 | Wesley Eddy | Request for Last Call review by TSVART is assigned to Tommy Pauly |
2020-09-28
|
06 | Wesley Eddy | Request for Last Call review by TSVART is assigned to Tommy Pauly |
2020-09-28
|
06 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Jon Mitchell |
2020-09-28
|
06 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Jon Mitchell |
2020-09-24
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Christian Huitema |
2020-09-24
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Christian Huitema |
2020-09-24
|
06 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2020-09-24
|
06 | Cindy Morgan | The following Last Call announcement was sent out (ends 2020-10-08): From: The IESG To: IETF-Announce CC: opsawg-chairs@ietf.org, draft-ietf-opsawg-model-automation-framework@ietf.org, Adrian Farrel , opsawg@ietf.org, … The following Last Call announcement was sent out (ends 2020-10-08): From: The IESG To: IETF-Announce CC: opsawg-chairs@ietf.org, draft-ietf-opsawg-model-automation-framework@ietf.org, Adrian Farrel , opsawg@ietf.org, rwilton@cisco.com, adrian@olddog.co.uk Reply-To: last-call@ietf.org Sender: Subject: Last Call: (A Framework for Automating Service and Network Management with YANG) to Informational RFC The IESG has received a request from the Operations and Management Area Working Group WG (opsawg) to consider the following document: - 'A Framework for Automating Service and Network Management with YANG' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2020-10-08. 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 Data models provide a programmatic approach to represent services and networks. Concretely, they can be used to derive configuration information for network and service components, and state information that will be monitored and tracked. Data models can be used during the service and network management life cycle, such as service instantiation, provisioning, optimization, monitoring, diagnostic, and assurance. Data models are also instrumental in the automation of network management, and they can provide closed-loop control for adaptive and deterministic service creation, delivery, and maintenance. This document describes an architecture for service and network management automation that takes advantage of YANG modeling technologies. This architecture is drawn from a network operator perspective irrespective of the origin of a data module; it can thus accommodate modules that are developed outside the IETF. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-opsawg-model-automation-framework/ No IPR declarations have been submitted directly on this I-D. |
2020-09-24
|
06 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2020-09-24
|
06 | Robert Wilton | Last call was requested |
2020-09-24
|
06 | Robert Wilton | Ballot approval text was generated |
2020-09-24
|
06 | Robert Wilton | Ballot writeup was generated |
2020-09-24
|
06 | Robert Wilton | IESG state changed to Last Call Requested from Publication Requested |
2020-09-24
|
06 | Robert Wilton | Last call announcement was generated |
2020-09-24
|
06 | Robert Wilton | Last call announcement was generated |
2020-09-24
|
06 | Robert Wilton | Last call announcement was changed |
2020-09-22
|
06 | Mohamed Boucadair | New version available: draft-ietf-opsawg-model-automation-framework-06.txt |
2020-09-22
|
06 | (System) | New version accepted (logged-in submitter: Mohamed Boucadair) |
2020-09-22
|
06 | Mohamed Boucadair | Uploaded new revision |
2020-09-08
|
05 | Mohamed Boucadair | New version available: draft-ietf-opsawg-model-automation-framework-05.txt |
2020-09-08
|
05 | (System) | New version accepted (logged-in submitter: Mohamed Boucadair) |
2020-09-08
|
05 | Mohamed Boucadair | Uploaded new revision |
2020-06-21
|
04 | Tianran Zhou | Shepherd write-up for draft-ietf-opsawg-model-automation-framework-04 > (1) What type of RFC is being requested (BCP, Proposed Standard, > Internet Standard, Informational, Experimental, or Historic)? Why … Shepherd write-up for draft-ietf-opsawg-model-automation-framework-04 > (1) What type of RFC is being requested (BCP, Proposed Standard, > Internet Standard, Informational, Experimental, or Historic)? Why > is this the proper type of RFC? Is this type of RFC indicated in > the title page header? This document requests publication as an Informational RFC. That is indicated on the header page. It is appropriate for this document because it is a framework that describes the use of data models specified in other documents. It does not dictate any on-wire behavior, and does not specify any interoperablity. > (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: This document describes an architecture for service and network management automation that takes advantage of YANG modeling technologies. This architecture is drawn from a Network Operator perspective irrespective of the origin of a data module; it can thus accommodate modules that are developed outside the IETF. Data models provide a programmatic approach to represent services and networks. Concretely, they can be used to derive configuration information for network and service components, and state information that will be monitored and tracked. Data models can be used during the service and network management life cycle, such as service instantiation, provisioning, optimization, monitoring, diagnostic, and assurance. Data models are also instrumental in the automation of network management, and they can provide closed-loop control for adaptive and deterministic service creation, delivery, and maintenance. > Working Group Summary: This document ran eight versions before adoption into the working group. The adoption poll included responses from fifteen people and general support was indicated. There was some debate about the filename at the time of adoption, and the result was a name that better matched the purpose of the document. The WG draft was presented at one physical meeting and at the IETF-107 virtual meeting. Points were raised and the draft updated. WG last call attracted fewer commenters, but there were several detailed reviews which were addressed. There were no points of contention. > Document Quality: This document is not intended for implementation, but as a guideline for building and deploying management systems. The involvement of four network operators in the authorship indicates that the document has been viewed carefully by those involved in deploying network management systems. > Personnel: The document shepherd is Adrian Farrel The Responsible Area Director is Rob Wilton > (3) Briefly describe the review of this document that was performed by > the Document Shepherd. I did a cursory review of this document at the time of adoption, and a detailed review during working group last call. All of my comments have been addressed. I have done a subsequent review of the document to make sure it was not broken during updates after WG last call. This version is ready for publication. > (4) Does the document Shepherd have any concerns about the depth or > breadth of the reviews that have been performed? No concerns. As usual these days, it would have been nice to receive some more reviews, but there were enough that it is reasonable to advance the document. > (5) Do portions of the document need review from a particular or from > broader perspective. There is no use of formal language in the document and no need for specific targeted reviews. As previously noted, this document concerns deployment and use of network management systems and so can benefit from additional reviews by network operators. However, sufficient operator input has been receieved to give confidence about the contents. > (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? No such concerns. > (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. All done. IPR responses can be seen at: Q. Wu: https://mailarchive.ietf.org/arch/msg/opsawg/zebmEbg9lOLZy9yYCPea94LIU6k/ M. Boucadair : https://mailarchive.ietf.org/arch/msg/opsawg/MtYvDrUqjcSoPMSsTg_ZpvR0eTQ/ D. Lopez: https://mailarchive.ietf.org/arch/msg/opsawg/zNP3w3IVZkffakWyk-pxBYuRFr8/ C. Xie: https://mailarchive.ietf.org/arch/msg/opsawg/zyDDzrs0ZF9jBIRp1IP0CZcVBbE/ L. Geng: https://mailarchive.ietf.org/arch/msg/opsawg/5TUtcJ22HCVPmb3TGD7QUu1rz6A/ C. Jacquenet: https://mailarchive.ietf.org/arch/msg/opsawg/ugSjfI7ZH_dPa0WXeflDqpJJLmg/ Luis Miguel Contreras Murillo: https://mailarchive.ietf.org/arch/msg/opsawg/n-9UACXuUvMmpCO6DDiIDqZrbVI/ Oscar Gonzalez de Dios: https://mailarchive.ietf.org/arch/msg/opsawg/h-45h77DJiV7gkUpN5w3260hIqw/ Weiqiang Cheng: https://mailarchive.ietf.org/arch/msg/opsawg/u3UKqjhZAn27R4J0Fm-eqAoC7Tc/ Young Lee: https://mailarchive.ietf.org/arch/msg/opsawg/j06bIB8h0tuiJ1PRO5lSfnGOCy0/ > (8) Has an IPR disclosure been filed that references this document? 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? Reasonable support with no dissent. I would say that part of the WG is not interested in the subject matter and so had no opinion. But with a large list of authors and contributors this catches the mood of the WG. > (10) Has anyone threatened an appeal or otherwise indicated extreme > discontent? No. > (11) Identify any ID nits the Document Shepherd has found in this > document. idnits is clean except for a number of referenced I-Ds that have moved on to later revisions. That is picked up automatically the next time the XML is processed. > (12) Describe how the document meets any required formal review > criteria No formal language used. No criteria to be met. > (13) Have all references within this document been identified as > either normative or informative? Yes. > (14) Are there normative references to documents that are not ready > for advancement or are otherwise in an unclear state? If such > normative references exist, what is the plan for their > completion? All normative references are to published RFCs. > (15) Are there downward normative references references (see > RFC 3967)? No downrefs. > (16) Will publication of this document change the status of any > existing RFCs? No. > (17) Describe the Document Shepherd's review of the IANA > considerations section. The document makes no request for any IANA action. An appropriate "null" IANA Considerations section is included. > (18) List any new IANA registries that require Expert Review for > future allocations. None. > (19) Describe reviews and automated checks performed by the Document > Shepherd to validate sections of the document written in a formal > language. No formal language is used in this document. > (20) If the document contains a YANG module The document does not contain a YANG module. |
2020-06-21
|
04 | Tianran Zhou | Responsible AD changed to Robert Wilton |
2020-06-21
|
04 | Tianran Zhou | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2020-06-21
|
04 | Tianran Zhou | IESG state changed to Publication Requested from I-D Exists |
2020-06-21
|
04 | Tianran Zhou | IESG process started in state Publication Requested |
2020-06-21
|
04 | Tianran Zhou | Intended Status changed to Informational from None |
2020-06-16
|
04 | Adrian Farrel | Shepherd write-up for draft-ietf-opsawg-model-automation-framework-04 > (1) What type of RFC is being requested (BCP, Proposed Standard, > Internet Standard, Informational, Experimental, or Historic)? Why … Shepherd write-up for draft-ietf-opsawg-model-automation-framework-04 > (1) What type of RFC is being requested (BCP, Proposed Standard, > Internet Standard, Informational, Experimental, or Historic)? Why > is this the proper type of RFC? Is this type of RFC indicated in > the title page header? This document requests publication as an Informational RFC. That is indicated on the header page. It is appropriate for this document because it is a framework that describes the use of data models specified in other documents. It does not dictate any on-wire behavior, and does not specify any interoperablity. > (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: This document describes an architecture for service and network management automation that takes advantage of YANG modeling technologies. This architecture is drawn from a Network Operator perspective irrespective of the origin of a data module; it can thus accommodate modules that are developed outside the IETF. Data models provide a programmatic approach to represent services and networks. Concretely, they can be used to derive configuration information for network and service components, and state information that will be monitored and tracked. Data models can be used during the service and network management life cycle, such as service instantiation, provisioning, optimization, monitoring, diagnostic, and assurance. Data models are also instrumental in the automation of network management, and they can provide closed-loop control for adaptive and deterministic service creation, delivery, and maintenance. > Working Group Summary: This document ran eight versions before adoption into the working group. The adoption poll included responses from fifteen people and general support was indicated. There was some debate about the filename at the time of adoption, and the result was a name that better matched the purpose of the document. The WG draft was presented at one physical meeting and at the IETF-107 virtual meeting. Points were raised and the draft updated. WG last call attracted fewer commenters, but there were several detailed reviews which were addressed. There were no points of contention. > Document Quality: This document is not intended for implementation, but as a guideline for building and deploying management systems. The involvement of four network operators in the authorship indicates that the document has been viewed carefully by those involved in deploying network management systems. > Personnel: The document shepherd is Adrian Farrel The Responsible Area Director is Rob Wilton > (3) Briefly describe the review of this document that was performed by > the Document Shepherd. I did a cursory review of this document at the time of adoption, and a detailed review during working group last call. All of my comments have been addressed. I have done a subsequent review of the document to make sure it was not broken during updates after WG last call. This version is ready for publication. > (4) Does the document Shepherd have any concerns about the depth or > breadth of the reviews that have been performed? No concerns. As usual these days, it would have been nice to receive some more reviews, but there were enough that it is reasonable to advance the document. > (5) Do portions of the document need review from a particular or from > broader perspective. There is no use of formal language in the document and no need for specific targeted reviews. As previously noted, this document concerns deployment and use of network management systems and so can benefit from additional reviews by network operators. However, sufficient operator input has been receieved to give confidence about the contents. > (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? No such concerns. > (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. All done. IPR responses can be seen at: Q. Wu: https://mailarchive.ietf.org/arch/msg/opsawg/zebmEbg9lOLZy9yYCPea94LIU6k/ M. Boucadair : https://mailarchive.ietf.org/arch/msg/opsawg/MtYvDrUqjcSoPMSsTg_ZpvR0eTQ/ D. Lopez: https://mailarchive.ietf.org/arch/msg/opsawg/zNP3w3IVZkffakWyk-pxBYuRFr8/ C. Xie: https://mailarchive.ietf.org/arch/msg/opsawg/zyDDzrs0ZF9jBIRp1IP0CZcVBbE/ L. Geng: https://mailarchive.ietf.org/arch/msg/opsawg/5TUtcJ22HCVPmb3TGD7QUu1rz6A/ C. Jacquenet: https://mailarchive.ietf.org/arch/msg/opsawg/ugSjfI7ZH_dPa0WXeflDqpJJLmg/ Luis Miguel Contreras Murillo: https://mailarchive.ietf.org/arch/msg/opsawg/n-9UACXuUvMmpCO6DDiIDqZrbVI/ Oscar Gonzalez de Dios: https://mailarchive.ietf.org/arch/msg/opsawg/h-45h77DJiV7gkUpN5w3260hIqw/ Weiqiang Cheng: https://mailarchive.ietf.org/arch/msg/opsawg/u3UKqjhZAn27R4J0Fm-eqAoC7Tc/ Young Lee: https://mailarchive.ietf.org/arch/msg/opsawg/j06bIB8h0tuiJ1PRO5lSfnGOCy0/ > (8) Has an IPR disclosure been filed that references this document? 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? Reasonable support with no dissent. I would say that part of the WG is not interested in the subject matter and so had no opinion. But with a large list of authors and contributors this catches the mood of the WG. > (10) Has anyone threatened an appeal or otherwise indicated extreme > discontent? No. > (11) Identify any ID nits the Document Shepherd has found in this > document. idnits is clean except for a number of referenced I-Ds that have moved on to later revisions. That is picked up automatically the next time the XML is processed. > (12) Describe how the document meets any required formal review > criteria No formal language used. No criteria to be met. > (13) Have all references within this document been identified as > either normative or informative? Yes. > (14) Are there normative references to documents that are not ready > for advancement or are otherwise in an unclear state? If such > normative references exist, what is the plan for their > completion? All normative references are to published RFCs. > (15) Are there downward normative references references (see > RFC 3967)? No downrefs. > (16) Will publication of this document change the status of any > existing RFCs? No. > (17) Describe the Document Shepherd's review of the IANA > considerations section. The document makes no request for any IANA action. An appropriate "null" IANA Considerations section is included. > (18) List any new IANA registries that require Expert Review for > future allocations. None. > (19) Describe reviews and automated checks performed by the Document > Shepherd to validate sections of the document written in a formal > language. No formal language is used in this document. > (20) If the document contains a YANG module The document does not contain a YANG module. |
2020-06-16
|
04 | Tianran Zhou | Notification list changed to Adrian Farrel <adrian@olddog.co.uk> |
2020-06-16
|
04 | Tianran Zhou | Document shepherd changed to Adrian Farrel |
2020-06-16
|
04 | Tianran Zhou | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2020-06-14
|
04 | Mohamed Boucadair | New version available: draft-ietf-opsawg-model-automation-framework-04.txt |
2020-06-14
|
04 | (System) | New version approved |
2020-06-14
|
04 | (System) | Request for posting confirmation emailed to previous authors: Chongfeng Xie , Liang Geng , Mohamed Boucadair , opsawg-chairs@ietf.org, Diego Lopez , Qin WU |
2020-06-14
|
04 | Mohamed Boucadair | Uploaded new revision |
2020-05-31
|
03 | Tianran Zhou | IETF WG state changed to In WG Last Call from WG Document |
2020-05-28
|
03 | Mohamed Boucadair | New version available: draft-ietf-opsawg-model-automation-framework-03.txt |
2020-05-28
|
03 | (System) | New version accepted (logged-in submitter: Mohamed Boucadair) |
2020-05-28
|
03 | Mohamed Boucadair | Uploaded new revision |
2020-03-17
|
02 | Mohamed Boucadair | New version available: draft-ietf-opsawg-model-automation-framework-02.txt |
2020-03-17
|
02 | (System) | New version approved |
2020-03-17
|
02 | (System) | Request for posting confirmation emailed to previous authors: Chongfeng Xie , Liang Geng , Mohamed Boucadair , Qin WU , Diego Lopez |
2020-03-17
|
02 | Mohamed Boucadair | Uploaded new revision |
2020-02-26
|
01 | Qin Wu | New version available: draft-ietf-opsawg-model-automation-framework-01.txt |
2020-02-26
|
01 | (System) | New version accepted (logged-in submitter: Qin Wu) |
2020-02-26
|
01 | Qin Wu | Uploaded new revision |
2019-11-19
|
00 | Tianran Zhou | Added to session: IETF-106: opsawg Wed-1000 |
2019-11-17
|
00 | Tianran Zhou | This document now replaces draft-wu-model-driven-management-virtualization instead of None |
2019-11-17
|
00 | Qin Wu | New version available: draft-ietf-opsawg-model-automation-framework-00.txt |
2019-11-17
|
00 | (System) | WG -00 approved |
2019-11-17
|
00 | Qin Wu | Set submitter to "Qin Wu ", replaces to draft-wu-model-driven-management-virtualization and sent approval email to group chairs: opsawg-chairs@ietf.org |
2019-11-17
|
00 | Qin Wu | Uploaded new revision |