draft-ietf-netmod-yang-instance-file-format-08.txt   draft-ietf-netmod-yang-instance-file-format-09.txt 
Netmod B. Lengyel Netmod B. Lengyel
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track B. Claise Intended status: Standards Track B. Claise
Expires: September 10, 2020 Cisco Systems, Inc. Expires: September 18, 2020 Cisco Systems, Inc.
March 9, 2020 March 17, 2020
YANG Instance Data File Format YANG Instance Data File Format
draft-ietf-netmod-yang-instance-file-format-08 draft-ietf-netmod-yang-instance-file-format-09
Abstract Abstract
There is a need to document data defined in YANG models when a live There is a need to document data defined in YANG models when a live
server is not available. Data is often needed already at design or server is not available. Data is often needed already at design or
implementation time or needed by groups that do not have a live implementation time or needed by groups that do not have a live
running server available. This document specifies a standard file running server available. This document specifies a standard file
format for YANG instance data, which follows the syntax and semantics format for YANG instance data, which follows the syntax and semantics
of existing YANG models, and annotates it with metadata. of existing YANG models, and annotates it with metadata.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 10, 2020. This Internet-Draft will expire on September 18, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 31 skipping to change at page 2, line 31
4.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 12
4.2. YANG Model . . . . . . . . . . . . . . . . . . . . . . . 13 4.2. YANG Model . . . . . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
6.1. URI Registration . . . . . . . . . . . . . . . . . . . . 19 6.1. URI Registration . . . . . . . . . . . . . . . . . . . . 19
6.2. YANG Module Name Registration . . . . . . . . . . . . . . 19 6.2. YANG Module Name Registration . . . . . . . . . . . . . . 19
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . 20 8.1. Normative References . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . 21 8.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . 22 Appendix A. Changes between revisions . . . . . . . . . . . . . 22
Appendix B. Changes between revisions . . . . . . . . . . . . . 22 Appendix B. Backwards Compatibility . . . . . . . . . . . . . . 24
Appendix C. Backwards Compatibility . . . . . . . . . . . . . . 24 Appendix C. Detailed Use Cases - Non-Normative . . . . . . . . . 25
Appendix D. Detailed Use Cases - Non-Normative . . . . . . . . . 24 C.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 25
D.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 24 C.1.1. Use Case 1: Early Documentation of Server
D.1.1. Use Case 1: Early Documentation of Server Capabilities . . . . . . . . . . . . . . . . . . . . 25
Capabilities . . . . . . . . . . . . . . . . . . . . 24 C.1.2. Use Case 2: Preloading Data . . . . . . . . . . . . . 26
D.1.2. Use Case 2: Preloading Data . . . . . . . . . . . . . 26 C.1.3. Use Case 3: Documenting Factory Default Settings . . 26
D.1.3. Use Case 3: Documenting Factory Default Settings . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Terminology 1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
skipping to change at page 3, line 50 skipping to change at page 3, line 50
UC5 Storing diagnostics data UC5 Storing diagnostics data
UC6 Allowing YANG instance data to potentially be carried within UC6 Allowing YANG instance data to potentially be carried within
other IPC message formats other IPC message formats
UC7 Default instance data used as part of a templating solution UC7 Default instance data used as part of a templating solution
UC8 Providing data examples in RFCs or internet drafts UC8 Providing data examples in RFCs or internet drafts
In Appendix D we describe the first three use cases in detail. In Appendix C we describe the first three use cases in detail.
There are many and varied use cases where YANG instance data could be There are many and varied use cases where YANG instance data could be
used. We do not want to limit future uses of instance data sets, so used. We do not want to limit future uses of instance data sets, so
specifying how and when to use YANG instance data is out of scope for specifying how and when to use YANG instance data is out of scope for
this document. It is anticipated that other documents will define this document. It is anticipated that other documents will define
specific use cases. Use cases are listed here only to indicate the specific use cases. Use cases are listed here only to indicate the
need for this work. need for this work.
2.1. Principles 2.1. Principles
The following is a list of the basic principles of the instance data The following is a list of the basic principles of the instance data
format: format:
P1 Two standard formats shall be defined based on the XML and JSON P1 Two standard formats shall be defined based on the XML and JSON
encodings. encodings.
P2 Instance data shall reuse existing encoding rules for YANG P2 Instance data shall reuse existing encoding rules for YANG
defined data. Its format will be similar to the response of a defined data.
NETCONF <get> operation or the RESTCONF response to a GET method
invocation on the (unified) datastore resource.
P3 Metadata about the instance data set (Section 3, Paragraph 9) P3 Metadata about the instance data set (Section 3, Paragraph 9)
shall be defined. shall be defined.
P4 A YANG instance data set shall be allowed to contain data for P4 A YANG instance data set shall be allowed to contain data for
multiple YANG modules. multiple YANG modules.
P5 Instance data shall be allowed to contain configuration data, P5 Instance data shall be allowed to contain configuration data,
state data, or a mix of the two. state data, or a mix of the two.
skipping to change at page 8, line 37 skipping to change at page 8, line 37
If a referenced instance data file is not available, content-schema If a referenced instance data file is not available, content-schema
is unknown. is unknown.
The URI method is advantageous when the user wants to avoid the The URI method is advantageous when the user wants to avoid the
overhead of specifying the content-schema in each instance data file: overhead of specifying the content-schema in each instance data file:
E.g., In Use Case 6, when the system creates a diagnostic file every E.g., In Use Case 6, when the system creates a diagnostic file every
minute to document the state of the server. minute to document the state of the server.
3.2. Examples 3.2. Examples
The following examples use artwork folding
[I-D.ietf-netmod-artwork-folding] for better formatting.
The following example is based on "UC1, Documenting Server The following example is based on "UC1, Documenting Server
Capabilities". It provides (a shortened) list of supported YANG Capabilities". It provides (a shortened) list of supported YANG
modules and NETCONF capabilities for a server. It uses the inline modules and NETCONF capabilities for a server. It uses the inline
method to specify the content-schema. method to specify the content-schema.
========== NOTE: '\' line wrapping per BCP XXX (RFC XXXX) ===========
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<instance-data-set xmlns= <instance-data-set xmlns=\
"urn:ietf:params:xml:ns:yang:ietf-yang-instance-data"> "urn:ietf:params:xml:ns:yang:ietf-yang-instance-data">
<name>acme-router-modules</name> <name>acme-router-modules</name>
<format-version>2020-03-06</format-version> <format-version>2020-03-06</format-version>
<content-schema> <content-schema>
<inline-module> <inline-module>ietf-yang-library@2016-06-21</inline-module>
ietf-yang-library@2016-06-21
</inline-module>
<inline-schema> <inline-schema>
<modules-state <modules-state \
xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library"> xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library">
<module> <module>
<name>ietf-yang-library</name> <name>ietf-yang-library</name>
<revision>2016-06-21</revision> <revision>2016-06-21</revision>
</module> </module>
<module> <module>
<name>ietf-netconf-monitoring</name> <name>ietf-netconf-monitoring</name>
<revision>2010-10-04</revision> <revision>2010-10-04</revision>
</module> </module>
</modules-state> </modules-state>
</inline-schema> </inline-schema>
<content-schema> <content-schema>
<revision> <revision>
<date>1956-10-23</date> <date>1956-10-23</date>
<description>Initial version</description> <description>Initial version</description>
</revision> </revision>
<description>Defines the minimal set of modules that any acme-router <description>Defines the minimal set of modules that any \
will contain.</description> acme-router will contain.</description>
<contact>info@acme.com</contact> <contact>info@acme.com</contact>
<content-data> <content-data>
<!-- The example lists only 4 modules, but it could list the <!-- The example lists only 4 modules, but it could list the
full set of supported modules for a server, potentially many full set of supported modules for a server, potentially many
dozens of modules --> dozens of modules -->
<modules-state <modules-state \
xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library"> xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library">
<module> <module>
<name>ietf-yang-library</name> <name>ietf-yang-library</name>
<revision>2016-06-21</revision> <revision>2016-06-21</revision>
<namespace> <namespace>\
urn:ietf:params:xml:ns:yang:ietf-yang-library urn:ietf:params:xml:ns:yang:ietf-yang-library\
</namespace> </namespace>
<conformance-type>implement</conformance-type> <conformance-type>implement</conformance-type>
</module> </module>
<module> <module>
<name>ietf-system</name> <name>ietf-system</name>
<revision>2014-08-06</revision> <revision>2014-08-06</revision>
<namespace>urn:ietf:params:xml:ns:yang:ietf-system</namespace> <namespace>urn:ietf:params:xml:ns:yang:ietf-system</namespace>
<feature>sys:authentication</feature> <feature>sys:authentication</feature>
<feature>sys:local-users</feature> <feature>sys:local-users</feature>
<deviation> <deviation>
<name>acme-system-ext</name> <name>acme-system-ext</name>
<revision>2018-08-06</revision> <revision>2018-08-06</revision>
</deviation> </deviation>
<conformance-type>implement</conformance-type> <conformance-type>implement</conformance-type>
</module> </module>
<module> <module>
<name>ietf-yang-types</name> <name>ietf-yang-types</name>
<revision>2013-07-15</revision> <revision>2013-07-15</revision>
<namespace>urn:ietf:params:xml:ns:yang:ietf-yang-types <namespace>urn:ietf:params:xml:ns:yang:ietf-yang-types\
</namespace> </namespace>
<conformance-type>import</conformance-type> <conformance-type>import</conformance-type>
</module> </module>
<module> <module>
<name>acme-system-ext</name> <name>acme-system-ext</name>
<revision>2018-08-06</revision> <revision>2018-08-06</revision>
<namespace>urn:rdns:acme.com:oammodel:acme-system-ext <namespace>urn:rdns:acme.com:oammodel:acme-system-ext\
</namespace> </namespace>
<conformance-type>implement</conformance-type> <conformance-type>implement</conformance-type>
</module> </module>
</modules-state> </modules-state>
<netconf-state <netconf-state \
xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring"> xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring">
<capabilities> <capabilities>
<capability> <capability>\
urn:ietf:params:netconf:capability:validate:1.1 urn:ietf:params:netconf:capability:validate:1.1\
</capability> </capability>
</capabilities> </capabilities>
</netconf-state> </netconf-state>
</content-data> </content-data>
</instance-data-set> </instance-data-set>
Figure 1: XML Instance Data Set - Use case 1, Documenting server Figure 1: XML Instance Data Set - Use case 1, Documenting server
capabilities capabilities
The following example is based on "UC2, Preloading Default The following example is based on "UC2, Preloading Default
Configuration". It provides a (shortened) default rule set for a Configuration". It provides a (shortened) default rule set for a
read-only operator role. It uses the inline method for specifying read-only operator role. It uses the inline method for specifying
the content-schema. the content-schema.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<instance-data-set xmlns= <instance-data-set
"urn:ietf:params:xml:ns:yang:ietf-yang-instance-data"> xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-instance-data">
<name>read-only-acm-rules</name> <name>read-only-acm-rules</name>
<format-version>2020-03-06</format-version> <format-version>2020-03-06</format-version>
<content-schema> <content-schema>
<inline-module>ietf-yang-library@2019-01-04</inline-module> <inline-module>ietf-yang-library@2019-01-04</inline-module>
<inline-schema> <inline-schema>
<yang-library <yang-library
xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library"> xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library">
<module-set> <module-set>
<name>all</name> <name>all</name>
<module> <module>
skipping to change at page 21, line 33 skipping to change at page 21, line 33
<https://www.rfc-editor.org/info/rfc8526>. <https://www.rfc-editor.org/info/rfc8526>.
[RFC8527] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., [RFC8527] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "RESTCONF Extensions to Support the Network and R. Wilton, "RESTCONF Extensions to Support the Network
Management Datastore Architecture", RFC 8527, Management Datastore Architecture", RFC 8527,
DOI 10.17487/RFC8527, March 2019, DOI 10.17487/RFC8527, March 2019,
<https://www.rfc-editor.org/info/rfc8527>. <https://www.rfc-editor.org/info/rfc8527>.
8.2. Informative References 8.2. Informative References
[I-D.ietf-netmod-artwork-folding]
Watsen, K., Auerswald, E., Farrel, A., and Q. WU,
"Handling Long Lines in Inclusions in Internet-Drafts and
RFCs", draft-ietf-netmod-artwork-folding-12 (work in
progress), January 2020.
[I-D.ietf-netmod-factory-default] [I-D.ietf-netmod-factory-default]
WU, Q., Lengyel, B., and Y. Niu, "A YANG Data Model for WU, Q., Lengyel, B., and Y. Niu, "A YANG Data Model for
Factory Default Settings", draft-ietf-netmod-factory- Factory Default Settings", draft-ietf-netmod-factory-
default-14 (work in progress), February 2020. default-14 (work in progress), February 2020.
[I-D.verdt-netmod-yang-module-versioning] [I-D.verdt-netmod-yang-module-versioning]
Claise, B., Clarke, J., Rahman, R., Wilton, R., Lengyel, Claise, B., Clarke, J., Rahman, R., Wilton, R., Lengyel,
B., Sterne, J., and K. D'Souza, "Updated YANG Module B., Sterne, J., and K. D'Souza, "Updated YANG Module
Revision Handling", draft-verdt-netmod-yang-module- Revision Handling", draft-verdt-netmod-yang-module-
versioning-01 (work in progress), October 2019. versioning-01 (work in progress), October 2019.
skipping to change at page 22, line 13 skipping to change at page 22, line 18
<https://www.rfc-editor.org/info/rfc6020>. <https://www.rfc-editor.org/info/rfc6020>.
[RFC8632] Vallin, S. and M. Bjorklund, "A YANG Data Model for Alarm [RFC8632] Vallin, S. and M. Bjorklund, "A YANG Data Model for Alarm
Management", RFC 8632, DOI 10.17487/RFC8632, September Management", RFC 8632, DOI 10.17487/RFC8632, September
2019, <https://www.rfc-editor.org/info/rfc8632>. 2019, <https://www.rfc-editor.org/info/rfc8632>.
[RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications
for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641,
September 2019, <https://www.rfc-editor.org/info/rfc8641>. September 2019, <https://www.rfc-editor.org/info/rfc8641>.
Appendix A. Open Issues Appendix A. Changes between revisions
o - Note to RFC Editor (To be removed by RFC Editor)
Appendix B. Changes between revisions v08 - v09
o Removed reference to similar to get reply
o Introduced artwork folding in the examples
v07 - v08 v07 - v08
o Moved compatibility into appendix o Moved compatibility into appendix
o Renamed yid-version to format-version as "yid" can be regarded as o Renamed yid-version to format-version as "yid" can be regarded as
a racial slur. Changed format to date of the YANG module a racial slur. Changed format to date of the YANG module
o Made support of ietf-yang-library mandatory if inline-content- o Made support of ietf-yang-library mandatory if inline-content-
schema is supported schema is supported
skipping to change at page 24, line 14 skipping to change at page 24, line 26
o Removed usage of dedicated .yid file extension o Removed usage of dedicated .yid file extension
o Added list of use cases o Added list of use cases
o Added list of principles o Added list of principles
o Updated examples o Updated examples
o Moved detailed use case descriptions to appendix o Moved detailed use case descriptions to appendix
Appendix C. Backwards Compatibility Appendix B. Backwards Compatibility
The concept of backwards compatibility and what changes are backwards The concept of backwards compatibility and what changes are backwards
compatible are not defined for instance data sets as it is highly compatible are not defined for instance data sets as it is highly
dependent on the specific use case and the content-schema. dependent on the specific use case and the content-schema.
For instance data that is the result of a design or specification For instance data that is the result of a design or specification
activity, some changes that may be good to avoid are listed. YANG activity, some changes that may be good to avoid are listed. YANG
uses the concept of managed entities identified by key values; if the uses the concept of managed entities identified by key values; if the
connection between the represented entity and the key value is not connection between the represented entity and the key value is not
preserved during an update, this may lead to problems. preserved during an update, this may lead to problems.
skipping to change at page 24, line 38 skipping to change at page 25, line 5
list entry as new. list entry as new.
o If the meaning of a list entry is changed, but the key values are o If the meaning of a list entry is changed, but the key values are
not (e.g., redefining an alarm-type but not changing its alarm- not (e.g., redefining an alarm-type but not changing its alarm-
type-id) the change may not be noticed. type-id) the change may not be noticed.
o If the key value of a previously removed list entry is reused for o If the key value of a previously removed list entry is reused for
a different entity, the change may be misinterpreted as a different entity, the change may be misinterpreted as
reintroducing the previous entity. reintroducing the previous entity.
Appendix D. Detailed Use Cases - Non-Normative Appendix C. Detailed Use Cases - Non-Normative
D.1. Use Cases C.1. Use Cases
We present a number of use cases were YANG instance data is needed. We present a number of use cases were YANG instance data is needed.
D.1.1. Use Case 1: Early Documentation of Server Capabilities C.1.1. Use Case 1: Early Documentation of Server Capabilities
A server has a number of server-capabilities that are defined in YANG A server has a number of server-capabilities that are defined in YANG
modules and can be retrieved from the server using protocols like modules and can be retrieved from the server using protocols like
NETCONF or RESTCONF. Server capabilities include: NETCONF or RESTCONF. Server capabilities include:
o data defined in ietf-yang-library: YANG modules, submodules, o data defined in ietf-yang-library: YANG modules, submodules,
features, deviations, schema-mounts, and datastores supported features, deviations, schema-mounts, and datastores supported
([RFC8525]) ([RFC8525])
o alarms supported ([RFC8632]) o alarms supported ([RFC8632])
skipping to change at page 26, line 5 skipping to change at page 26, line 14
Most server-capabilities are relatively stable and change only during Most server-capabilities are relatively stable and change only during
upgrade or due to licensing or the addition or removal of hardware. upgrade or due to licensing or the addition or removal of hardware.
They are usually defined by a vendor at design time, before the They are usually defined by a vendor at design time, before the
product is released. It is feasible and advantageous to define/ product is released. It is feasible and advantageous to define/
document them early e.g., in a YANG instance data File. document them early e.g., in a YANG instance data File.
It is anticipated that a separate IETF document will define in detail It is anticipated that a separate IETF document will define in detail
how and which set of server capabilities should be documented. how and which set of server capabilities should be documented.
D.1.2. Use Case 2: Preloading Data C.1.2. Use Case 2: Preloading Data
There are parts of the configuration that must be fully configurable There are parts of the configuration that must be fully configurable
by the operator. However, often a simple default configuration will by the operator. However, often a simple default configuration will
be sufficient. be sufficient.
One example is access control groups/roles and related rules. While One example is access control groups/roles and related rules. While
a sophisticated operator may define dozens of different groups, often a sophisticated operator may define dozens of different groups, often
a basic (read-only operator, read-write system administrator, a basic (read-only operator, read-write system administrator,
security-administrator) triplet will be enough. Vendors will often security-administrator) triplet will be enough. Vendors will often
provide such default configuration data to make device configuration provide such default configuration data to make device configuration
easier for an operator. easier for an operator.
Defining access control data is a complex task. To help, the device Defining access control data is a complex task. To help, the device
vendor predefines a set of default groups (/nacm:nacm/groups) and vendor predefines a set of default groups (/nacm:nacm/groups) and
rules for these groups to access specific parts of common models rules for these groups to access specific parts of common models
(/nacm:nacm/rule-list/rule). (/nacm:nacm/rule-list/rule).
YANG instance data files are used to document and/or preload the YANG instance data files are used to document and/or preload the
default configuration. default configuration.
D.1.3. Use Case 3: Documenting Factory Default Settings C.1.3. Use Case 3: Documenting Factory Default Settings
Nearly every server has a factory default configuration. If the Nearly every server has a factory default configuration. If the
system is really badly misconfigured or if the current configuration system is really badly misconfigured or if the current configuration
is to be abandoned, the system can be reset the default factory is to be abandoned, the system can be reset the default factory
configuration. configuration.
In NETCONF, the <delete-config> operation can already be used to In NETCONF, the <delete-config> operation can already be used to
reset the startup datastore. There are ongoing efforts to introduce reset the startup datastore. There are ongoing efforts to introduce
a new, more generic factory-reset operation for the same purpose a new, more generic factory-reset operation for the same purpose
[I-D.ietf-netmod-factory-default] [I-D.ietf-netmod-factory-default]
 End of changes. 29 change blocks. 
43 lines changed or deleted 53 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/