What are Module Tags?
- Module tags are strings that are used to select a set of YANG modules.
- They allow administrators to simplify access to YANG-based content by mapping module names to module tags.
- This work is being standardized in the NETMOD WG in the IETF as YANG Module Tags.
How Does netconfd-pro Support Module Tags?
- The server allows module tags to be configured statically with CLI or configuration file parameters.
(Dynamic configuration via a YANG module is pending a stable IETF draft). - The set of module name to module tag mappings can be retrieved with an RPC operation.
- A "module tag filter" can be specified for the <get> and <get-config> operations
- A "module tag rule" can be configured in NACM access control rules
- The server does not enforce the strict syntax for module tags found in the IETF YANG module
Configuring Module Tags
The --with-modtags parameter is used to enable or disable the module tags feature:
with-modtags true
The YANG definition for the with-modtags parameter:
leaf with-modtags {
description
"If set to 'true', then the module tags feature will be
enabled. Otherwise, this feature will be disabled.
If disabled, the module-tagmap parameter will be ignored
and the ietf-module-tags module will not be loaded.";
type boolean;
default true;
}The --module-tagmap parameter is used to configure a module name to module tag mapping.
The following example configured 3 module-tags:
- netconf (contains ietf-netconf-monitoring)
- restconf (contains ietf-restconf-monitoring)
- test (contains test, test1, and test2)
module-tagmap ietf-netconf-monitoring@netconf module-tagmap ietf-restconf-monitoring@restconf module-tagmap test@test module-tagmap test1@test module-tagmap test2@test
The YANG definition for the module-tagmap parameter:
leaf-list module-tagmap {
description
"Specifies a module tag mapping for use in module tags registry.
The format is <modname>@<tag-string>.
Examples:
ietf-system@ietf:system-management
openconfig-system@vendor:openconfig:system-management
example-system@vendor:example.com:system-management
";
type string;
}Retrieving the Module Tag Mappings
The <get-module-tags> operation provides the list of module tag mappings configured on the server.
This operation is defined in the module yumaworks-system.
Request: <rpc message-id="2" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <get-module-tags xmlns="http://yumaworks.com/ns/yumaworks-system"/> </rpc> Response: <rpc-reply message-id="2" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <module-tag xmlns="http://yumaworks.com/ns/yumaworks-system"> <tag>netconf</tag> <module>ietf-netconf-monitoring</module> </module-tag> <module-tag xmlns="http://yumaworks.com/ns/yumaworks-system"> <tag>restconf</tag> <module>ietf-restconf-monitoring</module> </module-tag> <module-tag xmlns="http://yumaworks.com/ns/yumaworks-system"> <tag>test</tag> <module>test</module> <module>test1</module> <module>test2</module> </module-tag> </rpc-reply>
Retrieving YANG Content Filtered by Module Tags
- A --module-tag parameter has been added to the <get> and <get-config> operations.
- This parameter allows YANG data to be retrieved only if it matches the YANG module(s) that are mapped to the specified module tag.
- It is not an error to provide an unknown module tag. The server will skip unknown module tags.
In this example, the "restconf" module tag is used as a filter:
Request: <rpc message-id="4" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <get> <module-tag xmlns="http://yumaworks.com/ns/yumaworks-system">restconf</module-tag> </get> </rpc> Response: <rpc-reply message-id="4" xmlns:ncx="http://netconfcentral.org/ns/yuma-ncx" ncx:last-modified="2018-05-25T00:21:39Z" ncx:etag="3843" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <data> <restconf-state xmlns="urn:ietf:params:xml:ns:yang:ietf-restconf-monitoring"> <capabilities> <capability>urn:ietf:params:restconf:capability:depth:1.0</capability> <capability>urn:ietf:params:restconf:capability:with-defaults:1.0</capability> <capability>urn:ietf:params:restconf:capability:defaults:1.0?basic-mode=explicit</capability> <capability>urn:ietf:params:restconf:capability:fields:1.0</capability> <capability>urn:ietf:params:restconf:capability:replay:1.0</capability> <capability>urn:ietf:params:restconf:capability:filter:1.0</capability> <capability>urn:ietf:params:restconf:capability:yang-patch:1.0</capability> </capabilities> <streams> <stream> <name>RESTCONF</name> <description>default RESTCONF event stream</description> <replay-support>true</replay-support> <replay-log-creation-time>2018-05-25T00:21:39Z</replay-log-creation-time> <access> <encoding>xml</encoding> <location>http://localhost/restconf/stream</location> </access> </stream> </streams> </restconf-state> </data> </rpc-reply>
The YANG definition for the module-tag parameter:
leaf-list module-tag {
type string {
length "1 .. 1023";
}
description
"Include only data nodes that match the module-tag.
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.
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.";
}Configuring NACM Access Control Rules with Module Tags
- The module-tag parameter can be used within the NACM "rule" list
- The "module-tags" case is added to the "rule-type" choice
- The module tags select all content from the mapped modules, and can apply to all types of NACM rules
In this example, a rule is configured to allow the "test" group all access to the module tag "test":
This will allow all access to the modules named "test", "test1", and "test2".
<nacm xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-acm"> <groups> <group> <name>admin</name> <user-name>admin</user-name> </group> <group> <name>test</name> <user-name>andy</user-name> <user-name>diag</user-name> </group> </groups> <rule-list> <name>test-write-ok</name> <group>test</group> <rule> <name>r1</name> <module-name>*</module-name> <access-operations>*</access-operations> <action>permit</action> <comment>allow full access to test modules</comment> <module-tag xmlns="http://yumaworks.com/ns/yumaworks-system">test</module-tag> </rule> </rule-list> </nacm>