module ietf-module-tag-ops {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-module-tag-ops";
prefix mto;
import ietf-module-tags { prefix tags; }
import ietf-netconf { prefix nc; }
import ietf-netconf-acm { prefix nacm; }
import ietf-netconf-nmda { prefix ncds; }
organization
"IETF NETCONF (Network Configuration) Working Group";
contact
"WG Web:
WG List:
Author: Andy Bierman
";
description
"This module defines enhancements to existing NETCONF
operations for using module tags to represent
YANG datastore content.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.
Copyright (c) 2019 IETF Trust and the persons identified
as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).";
// RFC Ed.: update the date below with the date of RFC publication
// and remove this note.
revision 2019-03-10 {
description
"Initial revision.";
reference
"draft-bierman-netconf-module-tag-ops-00";
}
grouping module-tag {
description
"Contains a reusable module-tag filter parameter";
leaf-list module-tag {
type tags:tag;
description
"Include only data nodes that match the module-tag
value. A data node is matched to a module tag in the
following manner:
1) The module name associated with the data node
is determined according to the protocol and
message encoding.
2) The module name is associated with the specified
module-tag if a 'tag' entry exists within a
/module-tags/module list entry with the same
value as this entry, and a 'masked-tag' entry
does not exist within the same /module-tags/module
list entry.
3) Each child data node is tested in recursive fashion.
If the module name changes from the parent node, then
this procedure is repeated. Once a module name
does not match, then no further descendant nodes
are included.
Multiple module-tag parameters are combined as a
logical OR expression. Matching any tag value will
cause the data node to be included.
It is not an error to include an unknown module-tag
value. Such tag values will simply be treated as a 'false'
match result, when evaluating the filter.
If any module-tag parameters are provided at all,
and there are no matches found, then no data will be
returned in the response.
The output of all module-tag parameters are
combined with other retrieval filters in a logical
AND expression.
";
}
}
augment /ncds:get-data/ncds:input {
description
"Return data only if it matches according
to the rules specified in the module-tag parameter.";
uses module-tag {
description
"The module-tag values are applied starting at the
top-level YANG data node within the target datastore.";
reference
"RFC 8526: NETCONF Extensions to Support the
Network Management Datastore Architecture; Section 3.1.1";
}
}
augment /nacm:nacm/nacm:rule-list/nacm:rule/nacm:rule-type {
description
"Match datastore content, protocol operations, or
notification events only if the associated module name
matches according to the rules specified in the module-tag
parameter.
If this rule type is used then the associated module-name
parameter needs to be omitted or set to the default value.
Otherwise it will interact with the module-tag parameter
and the specified module-name will only apply if it is
also included in the module-tag parameters provided.";
case module-tags {
uses module-tag {
description
"The module-tag values are applied to the conceptual
document according to the NACM rules, starting at the
top-level YANG data node. This is different in each
access control enforcement procedure phase:
- Incoming RPC Message Validation
The module name of the association protocol operation
is used to match a module-tag parameter.
- Data Node Access Validation
The module name associated with each data node within
the target datastore, or within non-NMDA operational
state (in an implementation-specific manner).
- Outgoing Authorization:
The module name of the association notification event
is used to match a module-tag parameter.
";
reference
"RFC 8341: Network Configuration Access Control Model;
Sections 3.2.4, 3.4.4, 3.5.5, 3.4.6";
}
}
}
augment /nc:get-config/nc:input {
status deprecated;
description
"Return configuration data only if it matches according
to the rules specified in the module-tag parameter.";
uses module-tag {
status deprecated;
description
"The module-tag values are applied starting at the
top-level YANG data node within the target datastore.";
reference
"RFC 6241: Network Configuration Protocol; Section 7.1";
}
}
augment /nc:get/nc:input {
status deprecated;
description
"Return data only if it matches according
to the rules specified in the module-tag parameter.";
uses module-tag {
status deprecated;
description
"The module-tag values are applied starting at the
top-level YANG data node within the datastore
for configuration and the top-level YANG data nodes
for all operational state data nodes.";
reference
"RFC 6241: Network Configuration Protocol; Section 7.7";
}
}
}