Pagination draft
This commit is contained in:
parent
ab0bc0ea4b
commit
78f5a6983c
15 changed files with 1206 additions and 86 deletions
|
|
@ -50,7 +50,14 @@ YANGSPECS += ietf-restconf-monitoring@2017-01-26.yang
|
|||
YANGSPECS += ietf-yang-library@2019-01-04.yang
|
||||
YANGSPECS += ietf-yang-types@2013-07-15.yang
|
||||
YANGSPECS += ietf-datastores@2018-02-14.yang
|
||||
<<<<<<< HEAD
|
||||
YANGSPECS += ietf-yang-patch@2017-02-22.yang
|
||||
=======
|
||||
YANGSPECS += ietf-netconf-list-pagination@2020-10-30.yang
|
||||
YANGSPECS += ietf-origin@2018-02-14.yang
|
||||
YANGSPECS += ietf-yang-metadata@2016-08-05.yang
|
||||
YANGSPECS += ietf-netconf-with-defaults@2011-06-01.yang
|
||||
>>>>>>> Pagination draft
|
||||
|
||||
all:
|
||||
|
||||
|
|
|
|||
329
yang/mandatory/ietf-netconf-list-pagination@2020-10-30.yang
Normal file
329
yang/mandatory/ietf-netconf-list-pagination@2020-10-30.yang
Normal file
|
|
@ -0,0 +1,329 @@
|
|||
module ietf-netconf-list-pagination {
|
||||
yang-version 1.1;
|
||||
namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-list-pagination";
|
||||
prefix ycoll;
|
||||
|
||||
import ietf-yang-types {
|
||||
prefix yang;
|
||||
reference
|
||||
"RFC 6991: Common YANG Data Types";
|
||||
}
|
||||
import ietf-datastores {
|
||||
prefix ds;
|
||||
reference
|
||||
"RFC 8342: Network Management Datastore Architecture
|
||||
(NMDA)";
|
||||
}
|
||||
import ietf-origin {
|
||||
prefix or;
|
||||
reference
|
||||
"RFC 8342: Network Management Datastore Architecture
|
||||
(NMDA)";
|
||||
}
|
||||
import ietf-netconf {
|
||||
prefix nc;
|
||||
reference
|
||||
"RFC 6241: Network Configuration Protocol (NETCONF)";
|
||||
}
|
||||
import ietf-netconf-with-defaults {
|
||||
prefix ncwd;
|
||||
reference
|
||||
"RFC 6243: With-defaults Capability for NETCONF";
|
||||
}
|
||||
|
||||
organization
|
||||
"IETF NETCONF (Network Configuration) Working Group";
|
||||
contact
|
||||
"WG Web: <http://tools.ietf.org/wg/netconf/>
|
||||
WG List: <mailto:netconf@ietf.org>
|
||||
|
||||
Editor:
|
||||
|
||||
Editor:
|
||||
|
||||
Editor: ";
|
||||
description
|
||||
"This module define a new operation -- <get-collection>
|
||||
to support YANG based pagination.
|
||||
|
||||
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
|
||||
(https://trustee.ietf.org/license-info).
|
||||
|
||||
This version of this YANG module is part of RFC 8526; see
|
||||
the RFC itself for full legal notices.";
|
||||
|
||||
revision 2020-10-30 {
|
||||
description
|
||||
"Initial revision.";
|
||||
reference
|
||||
"RFC XXXX: YANG Based Pagination.";
|
||||
}
|
||||
|
||||
feature origin {
|
||||
description
|
||||
"Indicates that the server supports the 'origin' annotation.";
|
||||
reference
|
||||
"RFC 8342: Network Management Datastore Architecture (NMDA)";
|
||||
}
|
||||
|
||||
feature with-defaults {
|
||||
description
|
||||
"NETCONF :with-defaults capability. If the server advertises
|
||||
the :with-defaults capability for a session, then this
|
||||
feature must also be enabled for that session. Otherwise,
|
||||
this feature must not be enabled.";
|
||||
reference
|
||||
"RFC 6243: With-defaults Capability for NETCONF, Section 4; and
|
||||
RFC 8526: NETCONF Extensions to Support the Network Management
|
||||
Datastore Architecture, Section 3.1.1.2";
|
||||
}
|
||||
|
||||
rpc get-pageable-list {
|
||||
description
|
||||
"Use enhanced filtering features to retrieve data from a
|
||||
specific NMDA datastore. The content returned by get-data
|
||||
must satisfy all filters, i.e., the filter criteria are
|
||||
logically ANDed.
|
||||
|
||||
Any ancestor nodes (including list keys) of nodes selected by
|
||||
the filters are included in the response.
|
||||
|
||||
The 'with-origin' parameter is only valid for an operational
|
||||
datastore. If 'with-origin' is used with an invalid
|
||||
datastore, then the server MUST return an <rpc-error> element
|
||||
with an <error-tag> value of 'invalid-value'.
|
||||
|
||||
The 'with-defaults' parameter only applies to the operational
|
||||
datastore if the NETCONF :with-defaults and
|
||||
:with-operational-defaults capabilities are both advertised.
|
||||
If the 'with-defaults' parameter is present in a request for
|
||||
which it is not supported, then the server MUST return an
|
||||
<rpc-error> element with an <error-tag> value of
|
||||
'invalid-value'.";
|
||||
input {
|
||||
leaf datastore {
|
||||
type ds:datastore-ref;
|
||||
mandatory true;
|
||||
description
|
||||
"Datastore from which to retrieve data.
|
||||
|
||||
If the datastore is not supported by the server, then
|
||||
the server MUST return an <rpc-error> element with an
|
||||
<error-tag> value of 'invalid-value'.";
|
||||
}
|
||||
choice filter-spec {
|
||||
description
|
||||
"The content filter specification for this request.";
|
||||
anydata subtree-filter {
|
||||
description
|
||||
"This parameter identifies the portions of the
|
||||
target datastore to retrieve.";
|
||||
reference
|
||||
"RFC 6241: Network Configuration Protocol (NETCONF),
|
||||
Section 6";
|
||||
}
|
||||
leaf xpath-filter {
|
||||
if-feature "nc:xpath";
|
||||
type yang:xpath1.0;
|
||||
description
|
||||
"This parameter contains an XPath expression identifying
|
||||
the portions of the target datastore to retrieve.
|
||||
|
||||
If the expression returns a node-set, all nodes in the
|
||||
node-set are selected by the filter. Otherwise, if the
|
||||
expression does not return a node-set, then the
|
||||
<get-data> operation fails.
|
||||
|
||||
The expression is evaluated in the following XPath
|
||||
context:
|
||||
|
||||
o The set of namespace declarations are those in
|
||||
scope on the 'xpath-filter' leaf element.
|
||||
|
||||
o The set of variable bindings is empty.
|
||||
|
||||
o The function library is the core function library,
|
||||
and the XPath functions are defined in Section 10
|
||||
of RFC 7950.
|
||||
|
||||
o The context node is the root node of the target
|
||||
datastore.";
|
||||
}
|
||||
}
|
||||
leaf config-filter {
|
||||
type boolean;
|
||||
description
|
||||
"Filter for nodes with the given value for their 'config'
|
||||
property. When this leaf is set to 'true', only 'config
|
||||
true' nodes are selected, and when set to 'false', only
|
||||
'config false' nodes are selected. If this leaf is not
|
||||
present, no nodes are filtered.";
|
||||
}
|
||||
choice origin-filters {
|
||||
when 'derived-from-or-self(datastore, "ds:operational")';
|
||||
if-feature "origin";
|
||||
description
|
||||
"Filters configuration nodes based on the 'origin'
|
||||
annotation. Configuration nodes that do not have an
|
||||
'origin' annotation are treated as if they have the
|
||||
'origin' annotation 'or:unknown'.
|
||||
|
||||
System state nodes are not affected by origin-filters and
|
||||
thus not filtered. Note that system state nodes can be
|
||||
filtered with the 'config-filter' leaf.";
|
||||
leaf-list origin-filter {
|
||||
type or:origin-ref;
|
||||
description
|
||||
"Filter based on the 'origin' annotation. A
|
||||
configuration node matches the filter if its 'origin'
|
||||
annotation is derived from or equal to any of the given
|
||||
filter values.";
|
||||
}
|
||||
leaf-list negated-origin-filter {
|
||||
type or:origin-ref;
|
||||
description
|
||||
"Filter based on the 'origin' annotation. A
|
||||
configuration node matches the filter if its 'origin'
|
||||
annotation is neither derived from nor equal to any of
|
||||
the given filter values.";
|
||||
}
|
||||
}
|
||||
leaf max-depth {
|
||||
type union {
|
||||
type uint16 {
|
||||
range "1..65535";
|
||||
}
|
||||
type enumeration {
|
||||
enum unbounded {
|
||||
description
|
||||
"All descendant nodes are included.";
|
||||
}
|
||||
}
|
||||
}
|
||||
default "unbounded";
|
||||
description
|
||||
"For each node selected by the filters, this parameter
|
||||
selects how many conceptual subtree levels should be
|
||||
returned in the reply. If the depth is 1, the reply
|
||||
includes just the selected nodes but no children. If the
|
||||
depth is 'unbounded', all descendant nodes are included.";
|
||||
}
|
||||
leaf with-origin {
|
||||
when 'derived-from-or-self(../datastore, "ds:operational")';
|
||||
if-feature "origin";
|
||||
type empty;
|
||||
description
|
||||
"If this parameter is present, the server will return
|
||||
the 'origin' annotation for the nodes that have one.";
|
||||
}
|
||||
uses ncwd:with-defaults-parameters {
|
||||
if-feature "with-defaults";
|
||||
}
|
||||
leaf list-target {
|
||||
description
|
||||
"Identifies the list object that is being retrieved.
|
||||
This must be a path expression used to represent
|
||||
a list data node or leaf-list data node. ";
|
||||
mandatory true;
|
||||
type string;
|
||||
}
|
||||
leaf count {
|
||||
type union {
|
||||
type uint32;
|
||||
type string {
|
||||
pattern 'unbounded';
|
||||
}
|
||||
}
|
||||
default "unbounded";
|
||||
description
|
||||
"The maximum number of list entries to return. The
|
||||
value of the 'count' parameter is either an integer
|
||||
greater than or equal to 1, or the string 'unbounded'.
|
||||
The string 'unbounded' is the default value.";
|
||||
}
|
||||
leaf skip {
|
||||
type union {
|
||||
type uint32;
|
||||
type string {
|
||||
pattern 'none';
|
||||
}
|
||||
}
|
||||
default "none";
|
||||
description
|
||||
"The first list item to return.
|
||||
the 'skip' parameter is either an integer greater than
|
||||
or equal to 1, or the string 'unbounded'. The string
|
||||
'unbounded' is the default value.";
|
||||
}
|
||||
leaf direction {
|
||||
type enumeration {
|
||||
enum forward;
|
||||
enum reverse;
|
||||
}
|
||||
default "forward";
|
||||
description
|
||||
"Direction relative to the 'sort' order through list
|
||||
or leaf-list. It can be forward direction or reverse
|
||||
direction.";
|
||||
}
|
||||
leaf sort {
|
||||
type union {
|
||||
type string {
|
||||
length "1..max" {
|
||||
description
|
||||
"The name of a descendent node to sort on. For
|
||||
'Config false' lists and leaf-lists, the node SHOULD
|
||||
have the 'TBD' extension indicating that it has been
|
||||
indexed, enabling efficient sorts.";
|
||||
}
|
||||
}
|
||||
type enumeration {
|
||||
enum default {
|
||||
description
|
||||
"Indicates that the 'default' order is assumed. For
|
||||
'ordered-by user' lists and leaf-lists, the default order
|
||||
is the user-configured order. For 'ordered-by system'
|
||||
lists and leaf-lists, the default order is specified by the
|
||||
system.";
|
||||
}
|
||||
}
|
||||
}
|
||||
default "default";
|
||||
description
|
||||
"Indicates how the entries in a list are to be sorted.";
|
||||
}
|
||||
leaf where {
|
||||
type yang:xpath1.0;
|
||||
description
|
||||
"The boolean filter to select data instances to return from
|
||||
the list or leaf-list target. The Xpath expression MAY be
|
||||
constrained either server-wide, by datastore, by 'config'
|
||||
status, or per list or leaf-list. Details regarding how
|
||||
constraints are communicated are TBD. This parameter
|
||||
is optional; no filtering is applied when it is not
|
||||
specified.";
|
||||
}
|
||||
}
|
||||
output {
|
||||
anyxml pageable-list {
|
||||
description
|
||||
"Return the list entries that were requested and matched
|
||||
the filter criteria (if any). An empty data container
|
||||
indicates that the request did not produce any results.";
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
138
yang/mandatory/ietf-netconf-with-defaults@2011-06-01.yang
Normal file
138
yang/mandatory/ietf-netconf-with-defaults@2011-06-01.yang
Normal file
|
|
@ -0,0 +1,138 @@
|
|||
module ietf-netconf-with-defaults {
|
||||
|
||||
namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults";
|
||||
|
||||
prefix ncwd;
|
||||
|
||||
import ietf-netconf { prefix nc; }
|
||||
|
||||
organization
|
||||
"IETF NETCONF (Network Configuration Protocol) Working Group";
|
||||
|
||||
contact
|
||||
"WG Web: <http://tools.ietf.org/wg/netconf/>
|
||||
|
||||
WG List: <netconf@ietf.org>
|
||||
|
||||
WG Chair: Bert Wijnen
|
||||
<bertietf@bwijnen.net>
|
||||
|
||||
WG Chair: Mehmet Ersue
|
||||
<mehmet.ersue@nsn.com>
|
||||
|
||||
Editor: Andy Bierman
|
||||
<andy.bierman@brocade.com>
|
||||
|
||||
Editor: Balazs Lengyel
|
||||
<balazs.lengyel@ericsson.com>";
|
||||
|
||||
description
|
||||
"This module defines an extension to the NETCONF protocol
|
||||
that allows the NETCONF client to control how default
|
||||
values are handled by the server in particular NETCONF
|
||||
operations.
|
||||
|
||||
Copyright (c) 2011 IETF Trust and the persons identified as
|
||||
the document authors. 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).
|
||||
|
||||
This version of this YANG module is part of RFC 6243; see
|
||||
the RFC itself for full legal notices.";
|
||||
revision 2011-06-01 {
|
||||
description
|
||||
"Initial version.";
|
||||
reference
|
||||
"RFC 6243: With-defaults Capability for NETCONF";
|
||||
}
|
||||
|
||||
typedef with-defaults-mode {
|
||||
description
|
||||
"Possible modes to report default data.";
|
||||
reference
|
||||
"RFC 6243; Section 3.";
|
||||
type enumeration {
|
||||
enum report-all {
|
||||
description
|
||||
"All default data is reported.";
|
||||
reference
|
||||
"RFC 6243; Section 3.1";
|
||||
}
|
||||
enum report-all-tagged {
|
||||
description
|
||||
"All default data is reported.
|
||||
Any nodes considered to be default data
|
||||
will contain a 'default' XML attribute,
|
||||
set to 'true' or '1'.";
|
||||
reference
|
||||
"RFC 6243; Section 3.4";
|
||||
}
|
||||
enum trim {
|
||||
description
|
||||
"Values are not reported if they contain the default.";
|
||||
reference
|
||||
"RFC 6243; Section 3.2";
|
||||
}
|
||||
enum explicit {
|
||||
description
|
||||
"Report values that contain the definition of
|
||||
explicitly set data.";
|
||||
reference
|
||||
"RFC 6243; Section 3.3";
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
grouping with-defaults-parameters {
|
||||
description
|
||||
"Contains the <with-defaults> parameter for control
|
||||
of defaults in NETCONF retrieval operations.";
|
||||
leaf with-defaults {
|
||||
description
|
||||
"The explicit defaults processing mode requested.";
|
||||
reference
|
||||
"RFC 6243; Section 4.5.1";
|
||||
|
||||
type with-defaults-mode;
|
||||
}
|
||||
}
|
||||
|
||||
// extending the get-config operation
|
||||
augment /nc:get-config/nc:input {
|
||||
description
|
||||
"Adds the <with-defaults> parameter to the
|
||||
input of the NETCONF <get-config> operation.";
|
||||
reference
|
||||
"RFC 6243; Section 4.5.1";
|
||||
|
||||
uses with-defaults-parameters;
|
||||
}
|
||||
|
||||
// extending the get operation
|
||||
augment /nc:get/nc:input {
|
||||
description
|
||||
"Adds the <with-defaults> parameter to
|
||||
the input of the NETCONF <get> operation.";
|
||||
reference
|
||||
"RFC 6243; Section 4.5.1";
|
||||
|
||||
uses with-defaults-parameters;
|
||||
}
|
||||
|
||||
// extending the copy-config operation
|
||||
augment /nc:copy-config/nc:input {
|
||||
description
|
||||
"Adds the <with-defaults> parameter to
|
||||
the input of the NETCONF <copy-config> operation.";
|
||||
reference
|
||||
"RFC 6243; Section 4.5.1";
|
||||
|
||||
uses with-defaults-parameters;
|
||||
}
|
||||
|
||||
}
|
||||
147
yang/mandatory/ietf-origin@2018-02-14.yang
Normal file
147
yang/mandatory/ietf-origin@2018-02-14.yang
Normal file
|
|
@ -0,0 +1,147 @@
|
|||
module ietf-origin {
|
||||
yang-version 1.1;
|
||||
namespace "urn:ietf:params:xml:ns:yang:ietf-origin";
|
||||
prefix or;
|
||||
|
||||
import ietf-yang-metadata {
|
||||
prefix md;
|
||||
}
|
||||
|
||||
organization
|
||||
"IETF Network Modeling (NETMOD) Working Group";
|
||||
|
||||
contact
|
||||
"WG Web: <https://datatracker.ietf.org/wg/netmod/>
|
||||
|
||||
WG List: <mailto:netmod@ietf.org>
|
||||
|
||||
Author: Martin Bjorklund
|
||||
<mailto:mbj@tail-f.com>
|
||||
|
||||
Author: Juergen Schoenwaelder
|
||||
<mailto:j.schoenwaelder@jacobs-university.de>
|
||||
|
||||
Author: Phil Shafer
|
||||
<mailto:phil@juniper.net>
|
||||
|
||||
Author: Kent Watsen
|
||||
<mailto:kwatsen@juniper.net>
|
||||
|
||||
Author: Rob Wilton
|
||||
<rwilton@cisco.com>";
|
||||
|
||||
description
|
||||
"This YANG module defines an 'origin' metadata annotation and a
|
||||
set of identities for the origin value.
|
||||
|
||||
Copyright (c) 2018 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
|
||||
(https://trustee.ietf.org/license-info).
|
||||
|
||||
This version of this YANG module is part of RFC 8342
|
||||
(https://www.rfc-editor.org/info/rfc8342); see the RFC itself
|
||||
for full legal notices.";
|
||||
|
||||
revision 2018-02-14 {
|
||||
description
|
||||
"Initial revision.";
|
||||
reference
|
||||
"RFC 8342: Network Management Datastore Architecture (NMDA)";
|
||||
}
|
||||
|
||||
/*
|
||||
* Identities
|
||||
*/
|
||||
|
||||
identity origin {
|
||||
description
|
||||
"Abstract base identity for the origin annotation.";
|
||||
}
|
||||
|
||||
identity intended {
|
||||
base origin;
|
||||
description
|
||||
"Denotes configuration from the intended configuration
|
||||
datastore.";
|
||||
}
|
||||
|
||||
identity dynamic {
|
||||
base origin;
|
||||
description
|
||||
"Denotes configuration from a dynamic configuration
|
||||
datastore.";
|
||||
}
|
||||
|
||||
identity system {
|
||||
base origin;
|
||||
description
|
||||
"Denotes configuration originated by the system itself.
|
||||
|
||||
Examples of system configuration include applied configuration
|
||||
for an always-existing loopback interface, or interface
|
||||
configuration that is auto-created due to the hardware
|
||||
currently present in the device.";
|
||||
}
|
||||
|
||||
identity learned {
|
||||
base origin;
|
||||
description
|
||||
"Denotes configuration learned from protocol interactions with
|
||||
other devices, instead of via either the intended
|
||||
configuration datastore or any dynamic configuration
|
||||
datastore.
|
||||
|
||||
Examples of protocols that provide learned configuration
|
||||
include link-layer negotiations, routing protocols, and
|
||||
DHCP.";
|
||||
}
|
||||
|
||||
identity default {
|
||||
base origin;
|
||||
description
|
||||
"Denotes configuration that does not have a configured or
|
||||
learned value but has a default value in use. Covers both
|
||||
values defined in a 'default' statement and values defined
|
||||
via an explanation in a 'description' statement.";
|
||||
}
|
||||
|
||||
identity unknown {
|
||||
base origin;
|
||||
description
|
||||
"Denotes configuration for which the system cannot identify the
|
||||
origin.";
|
||||
}
|
||||
|
||||
/*
|
||||
* Type definitions
|
||||
*/
|
||||
|
||||
typedef origin-ref {
|
||||
type identityref {
|
||||
base origin;
|
||||
}
|
||||
description
|
||||
"An origin identity reference.";
|
||||
}
|
||||
|
||||
/*
|
||||
* Metadata annotations
|
||||
*/
|
||||
|
||||
md:annotation origin {
|
||||
type origin-ref;
|
||||
description
|
||||
"The 'origin' annotation can be present on any configuration
|
||||
data node in the operational state datastore. It specifies
|
||||
from where the node originated. If not specified for a given
|
||||
configuration data node, then the origin is the same as the
|
||||
origin of its parent node in the data tree. The origin for
|
||||
any top-level configuration data nodes must be specified.";
|
||||
}
|
||||
}
|
||||
84
yang/mandatory/ietf-yang-metadata@2016-08-05.yang
Normal file
84
yang/mandatory/ietf-yang-metadata@2016-08-05.yang
Normal file
|
|
@ -0,0 +1,84 @@
|
|||
module ietf-yang-metadata {
|
||||
|
||||
namespace "urn:ietf:params:xml:ns:yang:ietf-yang-metadata";
|
||||
|
||||
prefix "md";
|
||||
|
||||
organization
|
||||
"IETF NETMOD (NETCONF Data Modeling Language) Working Group";
|
||||
|
||||
contact
|
||||
"WG Web: <https://datatracker.ietf.org/wg/netmod/>
|
||||
|
||||
WG List: <mailto:netmod@ietf.org>
|
||||
|
||||
WG Chair: Lou Berger
|
||||
<mailto:lberger@labn.net>
|
||||
|
||||
WG Chair: Kent Watsen
|
||||
<mailto:kwatsen@juniper.net>
|
||||
|
||||
Editor: Ladislav Lhotka
|
||||
<mailto:lhotka@nic.cz>";
|
||||
|
||||
description
|
||||
"This YANG module defines an 'extension' statement that allows
|
||||
for defining metadata annotations.
|
||||
|
||||
Copyright (c) 2016 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).
|
||||
|
||||
This version of this YANG module is part of RFC 7952
|
||||
(http://www.rfc-editor.org/info/rfc7952); see the RFC itself
|
||||
for full legal notices.";
|
||||
|
||||
revision 2016-08-05 {
|
||||
description
|
||||
"Initial revision.";
|
||||
reference
|
||||
"RFC 7952: Defining and Using Metadata with YANG";
|
||||
}
|
||||
|
||||
extension annotation {
|
||||
argument name;
|
||||
description
|
||||
"This extension allows for defining metadata annotations in
|
||||
YANG modules. The 'md:annotation' statement can appear only
|
||||
at the top level of a YANG module or submodule, i.e., it
|
||||
becomes a new alternative in the ABNF production rule for
|
||||
'body-stmts' (Section 14 in RFC 7950).
|
||||
|
||||
The argument of the 'md:annotation' statement defines the name
|
||||
of the annotation. Syntactically, it is a YANG identifier as
|
||||
defined in Section 6.2 of RFC 7950.
|
||||
|
||||
An annotation defined with this 'extension' statement inherits
|
||||
the namespace and other context from the YANG module in which
|
||||
it is defined.
|
||||
|
||||
The data type of the annotation value is specified in the same
|
||||
way as for a leaf data node using the 'type' statement.
|
||||
|
||||
The semantics of the annotation and other documentation can be
|
||||
specified using the following standard YANG substatements (all
|
||||
are optional): 'description', 'if-feature', 'reference',
|
||||
'status', and 'units'.
|
||||
|
||||
A server announces support for a particular annotation by
|
||||
including the module in which the annotation is defined among
|
||||
the advertised YANG modules, e.g., in a NETCONF <hello>
|
||||
message or in the YANG library (RFC 7950). The annotation can
|
||||
then be attached to any instance of a data node defined in any
|
||||
YANG module that is advertised by the server.
|
||||
|
||||
XML encoding and JSON encoding of annotations are defined in
|
||||
RFC 7952.";
|
||||
}
|
||||
}
|
||||
|
|
@ -47,6 +47,7 @@ YANGSPECS += ietf-interfaces@2018-02-20.yang
|
|||
YANGSPECS += ietf-ip@2014-06-16.yang
|
||||
YANGSPECS += ietf-netconf-monitoring@2010-10-04.yang
|
||||
YANGSPECS += ietf-routing@2018-03-13.yang
|
||||
YANGSPECS += iana-crypt-hash@2014-08-06.yang # collection example-module
|
||||
|
||||
all:
|
||||
|
||||
|
|
|
|||
120
yang/optional/iana-crypt-hash@2014-08-06.yang
Normal file
120
yang/optional/iana-crypt-hash@2014-08-06.yang
Normal file
|
|
@ -0,0 +1,120 @@
|
|||
module iana-crypt-hash {
|
||||
namespace "urn:ietf:params:xml:ns:yang:iana-crypt-hash";
|
||||
prefix ianach;
|
||||
|
||||
organization "IANA";
|
||||
contact
|
||||
" Internet Assigned Numbers Authority
|
||||
|
||||
Postal: ICANN
|
||||
12025 Waterfront Drive, Suite 300
|
||||
Los Angeles, CA 90094-2536
|
||||
United States
|
||||
|
||||
Tel: +1 310 301 5800
|
||||
E-Mail: iana@iana.org>";
|
||||
description
|
||||
"This YANG module defines a type for storing passwords
|
||||
using a hash function and features to indicate which hash
|
||||
functions are supported by an implementation.
|
||||
|
||||
The latest revision of this YANG module can be obtained from
|
||||
the IANA web site.
|
||||
|
||||
Requests for new values should be made to IANA via
|
||||
email (iana@iana.org).
|
||||
|
||||
Copyright (c) 2014 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).
|
||||
|
||||
The initial version of this YANG module is part of RFC 7317;
|
||||
see the RFC itself for full legal notices.";
|
||||
|
||||
revision 2014-08-06 {
|
||||
description
|
||||
"Initial revision.";
|
||||
reference
|
||||
"RFC 7317: A YANG Data Model for System Management";
|
||||
}
|
||||
|
||||
typedef crypt-hash {
|
||||
type string {
|
||||
pattern
|
||||
'$0$.*'
|
||||
+ '|$1$[a-zA-Z0-9./]{1,8}$[a-zA-Z0-9./]{22}'
|
||||
+ '|$5$(rounds=\d+$)?[a-zA-Z0-9./]{1,16}$[a-zA-Z0-9./]{43}'
|
||||
+ '|$6$(rounds=\d+$)?[a-zA-Z0-9./]{1,16}$[a-zA-Z0-9./]{86}';
|
||||
}
|
||||
description
|
||||
"The crypt-hash type is used to store passwords using
|
||||
a hash function. The algorithms for applying the hash
|
||||
function and encoding the result are implemented in
|
||||
various UNIX systems as the function crypt(3).
|
||||
|
||||
A value of this type matches one of the forms:
|
||||
|
||||
$0$<clear text password>
|
||||
$<id>$<salt>$<password hash>
|
||||
$<id>$<parameter>$<salt>$<password hash>
|
||||
|
||||
The '$0$' prefix signals that the value is clear text. When
|
||||
such a value is received by the server, a hash value is
|
||||
calculated, and the string '$<id>$<salt>$' or
|
||||
$<id>$<parameter>$<salt>$ is prepended to the result. This
|
||||
value is stored in the configuration data store.
|
||||
If a value starting with '$<id>$', where <id> is not '0', is
|
||||
received, the server knows that the value already represents a
|
||||
hashed value and stores it 'as is' in the data store.
|
||||
|
||||
When a server needs to verify a password given by a user, it
|
||||
finds the stored password hash string for that user, extracts
|
||||
the salt, and calculates the hash with the salt and given
|
||||
password as input. If the calculated hash value is the same
|
||||
as the stored value, the password given by the client is
|
||||
accepted.
|
||||
|
||||
This type defines the following hash functions:
|
||||
|
||||
id | hash function | feature
|
||||
---+---------------+-------------------
|
||||
1 | MD5 | crypt-hash-md5
|
||||
5 | SHA-256 | crypt-hash-sha-256
|
||||
6 | SHA-512 | crypt-hash-sha-512
|
||||
|
||||
The server indicates support for the different hash functions
|
||||
by advertising the corresponding feature.";
|
||||
reference
|
||||
"IEEE Std 1003.1-2008 - crypt() function
|
||||
RFC 1321: The MD5 Message-Digest Algorithm
|
||||
FIPS.180-4.2012: Secure Hash Standard (SHS)";
|
||||
}
|
||||
|
||||
feature crypt-hash-md5 {
|
||||
description
|
||||
"Indicates that the device supports the MD5
|
||||
hash function in 'crypt-hash' values.";
|
||||
reference "RFC 1321: The MD5 Message-Digest Algorithm";
|
||||
}
|
||||
|
||||
feature crypt-hash-sha-256 {
|
||||
description
|
||||
"Indicates that the device supports the SHA-256
|
||||
hash function in 'crypt-hash' values.";
|
||||
reference "FIPS.180-4.2012: Secure Hash Standard (SHS)";
|
||||
}
|
||||
|
||||
feature crypt-hash-sha-512 {
|
||||
description
|
||||
"Indicates that the device supports the SHA-512
|
||||
hash function in 'crypt-hash' values.";
|
||||
reference "FIPS.180-4.2012: Secure Hash Standard (SHS)";
|
||||
}
|
||||
|
||||
}
|
||||
Loading…
Add table
Add a link
Reference in a new issue