Hello,
Thanks for the comments and the updated file accordingly. See below.
Regards Balazs
-----Original Message-----
From: Acee Lindem via Datatracker <noreply@xxxxxxxx>
Sent: 2019. október 30., szerda 13:59
To: yang-doctors@xxxxxxxx
Cc: draft-ietf-netmod-yang-instance-file-format.all@xxxxxxxx; last-call@xxxxxxxx; netmod@xxxxxxxx
Subject: Yangdoctors last call review of draft-ietf-netmod-yang-instance-file-format-04
Reviewer: Acee Lindem
Review result: Ready with Issues
Document: draft-ietf-netmod-yang-instance-file-format-04.txt
Reviewer: Acee Lindem
Review Date: Oct 30st, 2019
Review Type: Working Group Last Call
Intended Status: Standards Track
Summary: Ready with Issues
Modules: "ietf-yang-instance-data@xxxxxxxxxxxxxxx"
Tech Summary: The model describes mechanisms and statically specifying
instance data (XML or JSON) for YANG models. Use cases are
also discussed although not in normative text. The document
is relatively straight forward but could benefit from some
editorial cleanup.
Major Comments:
None
Minor Comments:
1. The "Security Considerations" in section 8 do not conform to the
recommended template in https://trac.ietf.org/trac/ops/wiki/yang-security-
guidelines>. The considerations may be completely dependent on the included
instance Data Set or some of the information in the model may also be
sensitive. However, it needs to be better described.
BALAZS: Updated security considerations, tried to make it more detailed.
However the template is mostly
not applicable to this draft. This draft contains very little own data, most of
the instance data is as you sad completely dependent on the included instance Data Set.
It is also planned to be accessed as a file, not via Netconf/Restconf.
2. I feel it would be helpful to explicitly state that the both read-only
and read-write instance data may be included in the instance data set.
BALAZS: OK. Chapter 3. Instance Data File Format will include the following:
" Config=true and config=false data MAY be mixed in the instance data file."
3. The document could requires some editorial cleanup. For example, use
complete sentenses for principles in section 2.1 and punctuate. Do not
begin sentenses with "E.g. ...".
BALAZS: Principles reworded.
Nits:
See diff below.
*** draft-ietf-netmod-yang-instance-file-format-04.txt.orig 2019-10-29 16:36:22.000000000 -0400
--- draft-ietf-netmod-yang-instance-file-format-04.txt 2019-10-29 21:40:06.000000000 -0400
***************
*** 20,26 ****
running server available. This document specifies a standard file
format for YANG instance data (which follows the syntax and semantic
from existing YANG models, re-using the same format as the reply to a
! <get> operation/request) and decorates it with metadata.
Status of This Memo
--- 20,26 ----
running server available. This document specifies a standard file
format for YANG instance data (which follows the syntax and semantic
from existing YANG models, re-using the same format as the reply to a
! <get> operation/request) and annotates it with metadata.
BALAZS: OK
Status of This Memo
***************
*** 114,127 ****
Internet-Draft YANG Instance Data August 2019
! Instance Data Set: A named set of data items decorated with metadata
that can be used as instance data in a YANG data tree.
Instance Data File: A file containing an instance data set formatted
according to the rules described in this document.
! Content-schema: A set of YANG modules with their revision,suupported
! features and deviations for which the instance data set contains
instance data
Content defining Yang module(s): YANG module(s) that make up the
--- 114,127 ----
Internet-Draft YANG Instance Data August 2019
! Instance Data Set: A named set of data items annotated with metadata
BALAZS: OK
that can be used as instance data in a YANG data tree.
Instance Data File: A file containing an instance data set formatted
according to the rules described in this document.
! Content-schema: A set of YANG modules with their revision, supported
BALAZS: OK
! features, and deviations for which the instance data set contains
BALAZS: OK
instance data
Content defining Yang module(s): YANG module(s) that make up the
***************
*** 138,145 ****
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
implementation time or needed by groups that do not have a live
! running server available. To facilitate this off-line delivery of
! data this document specifies a standard format for YANG instance data
sets and YANG instance data files.
The following is a list of already implemented and potential use
--- 138,145 ----
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
implementation time or needed by groups that do not have a live
! running server available. To facilitate this offline delivery of
BALAZS: OK
! data, this document specifies a standard format for YANG instance data
BALAZS: OK
sets and YANG instance data files.
The following is a list of already implemented and potential use
***************
*** 153,159 ****
UC4 Instance data used as backup
! UC5 Storing the configuration of a device, e.g. for archive or audit
purposes
UC6 Storing diagnostics data
--- 153,159 ----
UC4 Instance data used as backup
! UC5 Storing the configuration of a device, e.g., for archive or audit
Purposes
BALAZS: OK
UC6 Storing diagnostics data
***************
*** 186,201 ****
The following is a list of the basic principles of the instance data
format:
! P1 Two standard formats are based on the XML and the JSON encoding
! P2 Re-use existing formats similar to the response to a <get>
operation/request
P3 Add metadata about the instance data set (Section 3, Paragraph 9)
P4 A YANG instance data set may contain data for many YANG modules
! P5 Instance data may include configuration data, state data or a mix
of the two
P6 Partial data sets are allowed
--- 186,201 ----
The following is a list of the basic principles of the instance data
format:
! P1 Two standard formats are based on the XML and JSON encodings
BALAZS: OK
! P2 Reuse existing formats similar to the response to a <get>
BALAZS: OK
operation/request
P3 Add metadata about the instance data set (Section 3, Paragraph 9)
P4 A YANG instance data set may contain data for many YANG modules
! P5 Instance data may include configuration data, state data, or a mix
BALAZS: OK
of the two
P6 Partial data sets are allowed
***************
*** 227,233 ****
Two formats are specified based on the XML and JSON YANG encodings.
! Later as other YANG encodings (e.g. CBOR) are defined further
instance data formats may be specified.
The content-data part SHALL follow the encoding rules defined in
--- 227,233 ----
Two formats are specified based on the XML and JSON YANG encodings.
! Later as other YANG encodings (e.g., CBOR) are defined, further
BALAZS: OK
instance data formats may be specified.
The content-data part SHALL follow the encoding rules defined in
***************
*** 245,251 ****
ignored by users of YANG instance data, allowing it to be used
later for other purposes.
! in the XML format implementation specific XML attributes. Unknown
attributes MUST be ignored by users of YANG instance data,
allowing them to be used later for other purposes.
--- 245,251 ----
ignored by users of YANG instance data, allowing it to be used
later for other purposes.
! in the XML format implementation specific XML attributes, unknown
BALAZS: OK
attributes MUST be ignored by users of YANG instance data,
allowing them to be used later for other purposes.
***************
*** 271,277 ****
* instance-data-set-name ['@' revision-date] '.filetype'
! * E.g. acme-router-modules@xxxxxxxxxxxxxx
--- 271,277 ----
* instance-data-set-name ['@' revision-date] '.filetype'
! * E.g., acme-router-modules@xxxxxxxxxxxxxx
BALAZS: OK
***************
*** 282,288 ****
Internet-Draft YANG Instance Data August 2019
! If the leaf name is present in the instance data header this MUST
be used. Revision-date MUST be set to the latest revision date
inside the instance data set.
--- 282,288 ----
Internet-Draft YANG Instance Data August 2019
! If the leaf name is present in the instance data header, this MUST
BALAZS: OK
be used. Revision-date MUST be set to the latest revision date
inside the instance data set.
***************
*** 290,301 ****
* instance-data-set-name ['@' timestamp] '.filetype'
! * E.g. acme-router-modules@2018-01-25T15_06_34_3+01_00.json
! If the leaf name is present in the instance data header this MUST
be used. If the leaf timestamp is present in the instance data
! header this MUST be used; the semicolons and the decimal point if
! present shall be replaced by underscores.
The revision date or timestamp is optional. ".filetype" SHALL be
".json" or ".xml" according to the format used.
--- 290,301 ----
* instance-data-set-name ['@' timestamp] '.filetype'
! * E.g,. acme-router-modules@2018-01-25T15_06_34_3+01_00.json
BALAZS: OK
! If the leaf name is present in the instance data header, this MUST
BALAZS: OK
be used. If the leaf timestamp is present in the instance data
! header, this MUST be used; the semicolons and the decimal point, if
BALAZS: OK
! present shall, be replaced by underscores.
BALAZS: OK
The revision date or timestamp is optional. ".filetype" SHALL be
".json" or ".xml" according to the format used.
***************
*** 315,321 ****
3.1. Specifying the Content Schema
! To properly understand and use an instance data set the user needs to
know the content-schema. One of the following methods SHOULD be
used:
--- 315,321 ----
3.1. Specifying the Content Schema
! To properly understand and use an instance data set, the user needs to
BALAZS: OK
know the content-schema. One of the following methods SHOULD be
used:
***************
*** 342,359 ****
already known, or the information is available through external
documents.
! Additional methods e.g. a YANG-package based solution may be added
later.
Note, the specified content-schema only indicates the set of modules
that were used to define this YANG instance data set. Sometimes
instance data may be used for a server supporting a different YANG
! module set. (e.g. for "UC2 Preloading Data" the instance data set may
not be updated every time the YANG modules on the server are updated)
Whether the instance data set is usable for a possibly different
real-life YANG module set depends on many factors including the
! compatibility between the specified and the real-life YANG module set
! (considering modules, revisions, features, deviations), the scope of
the instance data, etc.
3.1.1. Inline Method
--- 342,359 ----
already known, or the information is available through external
documents.
! Additional methods, e.g., a YANG-package based solution may be added
BALAZS: OK
later.
Note, the specified content-schema only indicates the set of modules
that were used to define this YANG instance data set. Sometimes
instance data may be used for a server supporting a different YANG
! module set. (e.g., for "UC2 Preloading Data" the instance data set may
BALAZS: OK
not be updated every time the YANG modules on the server are updated)
Whether the instance data set is usable for a possibly different
real-life YANG module set depends on many factors including the
! compatibility between the specified and the real-life YANG module set,
BALAZS: OK
! considering modules, revisions, features, deviations, the scope of
BALAZS: OK
the instance data, etc.
3.1.1. Inline Method
***************
*** 361,372 ****
One or more inline-target-spec elements define YANG module(s) used to
specify the content defining YANG modules.
! E.g. ietf-yang-library@xxxxxxxxxxxxxxx
The anydata inline-content-schema carries instance data (conforming
to the inline-target-spec modules) that actually specifies the
content defining YANG modules including revision, supported features,
! deviations and any relevant additional data (e.g. version labels)
3.1.2. Simplified-Inline Method
--- 361,372 ----
One or more inline-target-spec elements define YANG module(s) used to
specify the content defining YANG modules.
! E.g., ietf-yang-library@xxxxxxxxxxxxxxx
BALAZS: OK
The anydata inline-content-schema carries instance data (conforming
to the inline-target-spec modules) that actually specifies the
content defining YANG modules including revision, supported features,
! deviations and any relevant additional data (e.g., version labels)
BALAZS: OK
3.1.2. Simplified-Inline Method
***************
*** 384,390 ****
The referenced instance data file MAY have no content-data if it is
used solely for specifying the content-schema. The referenced YANG
instance data file might use the INLINE method or might use the URI
! method to reference further instance data file(s). However at the
--- 384,390 ----
The referenced instance data file MAY have no content-data if it is
used solely for specifying the content-schema. The referenced YANG
instance data file might use the INLINE method or might use the URI
! method to reference further instance data file(s). However, at the
BALAZS: OK
***************
*** 397,416 ****
end of this reference chain there MUST be an instance data file using
the INLINE method.
! If a referenced instance data file is not available the revision
! data, supported features and deviations for the target YANG modules
are unknown.
The URI method is advantageous when the user wants to avoid the
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
minute to document the state of the server.
3.2. Examples
The following example is based on "UC1, Documenting Server
Capabilities". It provides (a shortened) list of supported YANG
! modules and Netconf capabilities for a server. It uses the inline
method to specify the content-schema.
<?xml version="1.0" encoding="UTF-8"?>
--- 397,416 ----
end of this reference chain there MUST be an instance data file using
the INLINE method.
! If a referenced instance data file is not available, the revision
BALAZS: OK
! data, supported features, and deviations for the target YANG modules
BALAZS: OK
are unknown.
The URI method is advantageous when the user wants to avoid the
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
BALAZS: OK
minute to document the state of the server.
3.2. Examples
The following example is based on "UC1, Documenting Server
Capabilities". It provides (a shortened) list of supported YANG
! modules and NETCCONF capabilities for a server. It uses the inline
BALAZS: OK
method to specify the content-schema.
<?xml version="1.0" encoding="UTF-8"?>
***************
*** 624,630 ****
"schema-uri": "file:///acme-netconf-diagnostics-yanglib.json",
"timestamp": "2018-01-25T17:00:38Z",
"description":
! "Netconf statistics",
"content-data": {
"ietf-netconf-monitoring:netconf-state": {
"statistics": {
--- 624,630 ----
"schema-uri": "file:///acme-netconf-diagnostics-yanglib.json",
"timestamp": "2018-01-25T17:00:38Z",
"description":
! "NETCONF statistics",
BALAZS: OK
"content-data": {
"ietf-netconf-monitoring:netconf-state": {
"statistics": {
***************
*** 647,661 ****
4. Data Life cycle
! In UC2 "Preloading default configuration data" the loaded data may be
! changed later e.g. by management operations. In UC6 "Storing
! Diagnostics data" the diagnostics values may change on device every
second.
! YANG instance data is a snap-shot of information at a specific point
! of time. If the data changes afterwards this is not represented in
! the instance data set anymore. The valid values can be retrieved in
! run-time via NETCONF/RESTCONF or received e.g. in Yang-Push
notifications.
Whether the instance data changes and if so, when and how, SHOULD be
--- 647,661 ----
4. Data Life cycle
! In UC2 "Preloading default configuration data", the loaded data may be
BALAZS: OK
! changed later, e.g., by management operations. In UC6 "Storing
BALAZS: OK
! Diagnostics data", the diagnostics values may change on the device every
BALAZS: OK
second.
! YANG instance data is a snapshot of information at a specific point
BALAZS: OK
! of time. If the data changes afterwards, this is not represented in
BALAZS: OK
! the instance data set anymore. The valid values can be retrieved at
BALAZS: OK
! run-time via NETCONF/RESTCONF or received, e.g., in YANG-Push
BALAZS: OK
notifications.
Whether the instance data changes and if so, when and how, SHOULD be
***************
*** 678,688 ****
Instance data sets that are produced as a result of some sort of
specification or design effort SHOULD be available without the need
! for a live server e.g. via download from the vendor's website, or in
! any other way product documentation is distributed.
Other instance data sets may be read from or produced by the YANG
! server itself e.g. UC6 documenting diagnostic data.
6. Backwards Compatibility
--- 678,688 ----
Instance data sets that are produced as a result of some sort of
specification or design effort SHOULD be available without the need
! for a live server, e.g., via download from the vendor's website, or in
BALAZS: OK
! any other way that product documentation is distributed.
BALAZS: OK
Other instance data sets may be read from or produced by the YANG
! server itself, e.g., UC6 documenting diagnostic data.
BALAZS: OK
6. Backwards Compatibility
***************
*** 691,714 ****
dependent on the specific use case and the content-schema.
For instance data that is the result of a design or specification
! activity some changes that may be good to avoid are listed. YANG
uses the concept of managed entities identified by key values; if the
connection between the represented entity and the key value is not
! preserved during an update this may lead to problems.
o If the key value of a list entry that represents the same managed
entity as before is changed, the user may mistakenly identify the
list entry as new.
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-
type-id) the change may not be noticed.
o If the key value of a previously removed list entry is reused for
! a different entity, the change may be mis-interpreted as
reintroducing the previous entity.
! 7. Yang Instance Data Model
7.1. Tree Diagram
--- 691,714 ----
dependent on the specific use case and the content-schema.
For instance data that is the result of a design or specification
! activity, some changes that may be good to avoid are listed. YANG
BALAZS: OK
uses the concept of managed entities identified by key values; if the
connection between the represented entity and the key value is not
! preserved during an update, this may lead to problems.
BALAZS: OK
o If the key value of a list entry that represents the same managed
entity as before is changed, the user may mistakenly identify the
list entry as new.
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-
BALAZS: OK
type-id) the change may not be noticed.
o If the key value of a previously removed list entry is reused for
! a different entity, the change may be misinterpreted as
BALAZS: OK
reintroducing the previous entity.
! 7. YANG Instance Data Model
7.1. Tree Diagram
***************
*** 812,818 ****
sx:structure instance-data-set {
description "A data structure to define a format for a
! YANG instance data set.Consists of meta-data about
the instance data set and the real content-data.";
leaf name {
--- 812,818 ----
sx:structure instance-data-set {
description "A data structure to define a format for a
! YANG instance data sets. Consists of meta-data about
BALAZS: OK
the instance data set and the real content-data.";
leaf name {
***************
*** 851,866 ****
min-elements 1;
ordered-by user;
description
! "Indicates that content defining Yang modules
! are specified inline.
Each value MUST be a YANG Module name including the
revision-date as defined for YANG file names in RFC7950.
! E.g. ietf-yang-library@xxxxxxxxxxxxxxx
The first item is either ietf-yang-library or some other
YANG module that contains a list of YANG modules with
! their name, revision-date, supported-features and
deviations.
As some versions of ietf-yang-library MAY contain
different module-sets for different datastores, if
--- 851,866 ----
min-elements 1;
ordered-by user;
description
! "Indicates that content defining YANG modules
! are specified inline.
BALAZS: OK
Each value MUST be a YANG Module name including the
revision-date as defined for YANG file names in RFC7950.
! E.g., ietf-yang-library@xxxxxxxxxxxxxxx
BALAZS: OK
The first item is either ietf-yang-library or some other
YANG module that contains a list of YANG modules with
! their name, revision-date, supported-features, and
BALAZS: OK
deviations.
As some versions of ietf-yang-library MAY contain
different module-sets for different datastores, if
***************
*** 871,883 ****
datastore.
Subsequent items MAY specify YANG modules augmenting the
! first module with useful data (e.g. a version label).";
}
anydata inline-content-schema {
mandatory true;
description "Instance data corresponding to the YANG modules
specified in the inline-spec nodes defining the set
! of content defining Yang YANG modules for this
instance-data-set.";
}
}
--- 871,883 ----
datastore.
Subsequent items MAY specify YANG modules augmenting the
! first module with useful data (e.g., a version label).";
BALAZS: OK
}
anydata inline-content-schema {
mandatory true;
description "Instance data corresponding to the YANG modules
specified in the inline-spec nodes defining the set
! of content defining YANG modules for this
BALAZS: OK
instance-data-set.";
}
}
***************
*** 888,894 ****
description
"A reference to another YANG instance data file.
This instance data file will use the same set of target
! YANG modules, revisions, supported features and deviations
as the referenced YANG instance data file.";
--- 888,894 ----
description
"A reference to another YANG instance data file.
This instance data file will use the same set of target
! YANG modules, revisions, supported features, and deviations
as the referenced YANG instance data file.";
BALAZS: OK
***************
*** 923,932 ****
leaf datastore {
type ds:datastore-ref;
description "The identity of the datastore with which the
! instance data set is associated e.g. the datastore from
! where the data was read or the datastore where the data
could be loaded or the datastore which is being documented.
! If a single specific datastore can not be specified, the
leaf MUST be absent.
If this leaf is absent, then the datastore to which the
--- 923,932 ----
leaf datastore {
type ds:datastore-ref;
description "The identity of the datastore with which the
! instance data set is associated, e.g., the datastore from
BALAZS: OK
! where the data was read or the datastore from which the data
BALAZS: the second part really should mean "a data store where I can push the data into". So I changed it to
" or the datastore into which the data may be loaded"
could be loaded or the datastore which is being documented.
! If a single specific datastore cannot be specified, the
leaf MUST be absent.
BALAZS: OK
If this leaf is absent, then the datastore to which the
***************
*** 1222,1228 ****
A server has a number of server-capabilities that are defined in YANG
modules and can be retrieved from the server using protocols like
! NETCONF or RESTCONF. server capabilities include
--- 1222,1228 ----
A server has a number of server-capabilities that are defined in YANG
modules and can be retrieved from the server using protocols like
! NETCONF or RESTCONF. Server capabilities include:
BALAZS: OK
***************
*** 1235,1246 ****
o data defined in ietf-yang-library: YANG modules, submodules,
! features, deviations, schema-mounts, datastores supported
([I-D.ietf-netconf-rfc7895bis])
o alarms supported ([I-D.ietf-ccamp-alarm-module])
! o data nodes, subtrees that support or do not support on-change
notifications ([I-D.ietf-netconf-yang-push])
o netconf-capabilities in ietf-netconf-monitoring
--- 1235,1246 ----
o data defined in ietf-yang-library: YANG modules, submodules,
! features, deviations, schema-mounts, and datastores supported
BALAZS: OK
([I-D.ietf-netconf-rfc7895bis])
o alarms supported ([I-D.ietf-ccamp-alarm-module])
! o data nodes and subtrees that support or do not support on-change
BALAZS: OK
notifications ([I-D.ietf-netconf-yang-push])
o netconf-capabilities in ietf-netconf-monitoring
***************
*** 1248,1280 ****
While it is good practice to allow a client to query these
capabilities from the live server, that is often not possible.
! Often when a network node is released an associated NMS (network
management system) is also released with it. The NMS depends on the
! capabilities of the server. During NMS implementation information
about server capabilities is needed. If the information is not
! available early in some off-line document, but only as instance data
from the live network node, the NMS implementation will be delayed,
! because it has to wait for the network node to be ready. Also
assuming that all NMS implementors will have a correctly configured
! network node available to retrieve data from, is a very expensive
proposition. (An NMS may handle dozens of node types.)
Network operators often build their own home-grown NMS systems that
! needs to be integrated with a vendor's network node. The operator
needs to know the network node's server capabilities in order to do
! this. Moreover the network operator's decision to buy a vendor's
product may even be influenced by the network node's OAM feature set
! documented as the Server's capabilities.
Beside NMS implementors, system integrators and many others also need
the same information early. Examples could be model driven testing,
generating documentation, etc.
Most server-capabilities are relatively stable and change only during
! upgrade or due to licensing or addition or removal of HW. They are
! usually defined by a vendor at design time, before the product is
! released. It feasible and advantageous to define/document them early
! e.g. in a YANG instance data File.
It is anticipated that a separate IETF document will define in detail
how and which set of server capabilities should be documented.
--- 1248,1280 ----
While it is good practice to allow a client to query these
capabilities from the live server, that is often not possible.
! Often when a network node is released, an associated NMS (network
BALAZS: OK
management system) is also released with it. The NMS depends on the
! capabilities of the server. During NMS implementation, information
BALAZS: OK
about server capabilities is needed. If the information is not
! available early in some offline document, but only as instance data
BALAZS: OK
from the live network node, the NMS implementation will be delayed,
! because it has to wait until the network node is ready. Also
BALAZS: OK
assuming that all NMS implementors will have a correctly configured
! network nodes from whic data is to be retrieved, is a very expensive
BALAZS: OK
proposition. (An NMS may handle dozens of node types.)
Network operators often build their own home-grown NMS systems that
! need to be integrated with a vendor's network node. The operator
BALAZS: OK
needs to know the network node's server capabilities in order to do
! this. Moreover, the network operator's decision to buy a vendor's
BALAZS: OK
product may even be influenced by the network node's OAM feature set
! documented as the server's capabilities.
BALAZS: OK
Beside NMS implementors, system integrators and many others also need
the same information early. Examples could be model driven testing,
generating documentation, etc.
Most server-capabilities are relatively stable and change only during
! upgrade or due to licensing or the addition or removal of hardware. They
! are usually defined by a vendor at design time, before the product is
! released. It feasible and advantageous to define/document them early,
! e.g., in a YANG instance data File.
BALAZS: OK
It is anticipated that a separate IETF document will define in detail
how and which set of server capabilities should be documented.
***************
*** 1293,1310 ****
C.1.2. Use Case 2: Preloading Data
There are parts of the configuration that must be fully configurable
! by the operator, however for which often a simple default
! configuration will be sufficient.
One example is access control groups/roles and related rules. While
! a sophisticated operator may define dozens of different groups often
a basic (read-only operator, read-write system administrator,
security-administrator) triplet will be enough. Vendors will often
provide such default configuration data to make device configuration
easier for an operator.
! Defining Access control data is a complex task. To help the device
! vendor pre-defines a set of default groups (/nacm:nacm/groups) and
rules for these groups to access specific parts of common models
(/nacm:nacm/rule-list/rule).
--- 1293,1310 ----
C.1.2. Use Case 2: Preloading Data
There are parts of the configuration that must be fully configurable
! by the operator. However, often a simple default configuration will
! be sufficient.
BALAZS: OK
One example is access control groups/roles and related rules. While
! a sophisticated operator may define dozens of different groups, often
a basic (read-only operator, read-write system administrator,
security-administrator) triplet will be enough. Vendors will often
provide such default configuration data to make device configuration
easier for an operator.
BALAZS: OK
! Defining access control data is a complex task. To help, the device
! vendor predefines a set of default groups (/nacm:nacm/groups) and
rules for these groups to access specific parts of common models
(/nacm:nacm/rule-list/rule).
BALAZS: OK
***************
*** 1315,1330 ****
Nearly every server has a factory default configuration. If the
system is really badly misconfigured or if the current configuration
! is to be abandoned the system can be reset to this default.
! In Netconf the <delete-config> operation can already be used to reset
the startup datastore. There are ongoing efforts to introduce a new,
more generic reset-datastore operation for the same purpose
! [I-D.wu-netconf-restconf-factory-restore]
The operator currently has no way to know what the default
! configuration actually contains. YANG instance data can be used to
! document the factory default configuration.
Authors' Addresses
--- 1315,1331 ----
Nearly every server has a factory default configuration. If the
system is really badly misconfigured or if the current configuration
! is to be abandoned the, system can be reset to the default factory
! configuration.
BALAZS: OK
! In NETCONF, the <delete-config> operation can already be used to reset
the startup datastore. There are ongoing efforts to introduce a new,
more generic reset-datastore operation for the same purpose
! [I-D.wu-netconf-restconf-factory-restore].
BALAZS: OK, but the draft was renamed so that's updated too.
The operator currently has no way to know what the default
! configuration actually contains. YANG instance data can also be used
! to document the factory default configuration.
BALAZS: OK
Authors' Addresses
<<attachment: smime.p7s>>
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
