experiments/clixon
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

* Optional yangs for testing have been removed from the Clixon repo

Browse source 
* These were included for testing
  * If you want to run the Clixon test suite you need to point `YANGMODELS`, see test/README.md
  * The following configure options have been removed:
    * `configure --with-opt-yang-installdir=DIR`
    * `configure   --enable-optyangs`
  * You may need to specify standard YANGs using configure option `--with-yang-standard-dir=DIR`
* Updated yang ietf models with fetures for tet
* Added option `CLICON_YANG_AUGMENT_ACCEPT_BROKEN` to accept broken yangmodels.
  * This is a debug option for CI testcases where standard YANG models are broken
This commit is contained in:
Olof hagsand 2021-11-27 17:54:56 +01:00
parent bc1f80b28e
commit 339b744835
28 changed files with 191 additions and 183 deletions
Download patch file Download diff file Expand all files Collapse all files

7
yang/README.md
View file

@ -1,12 +1,11 @@
# Yang files
There are three classes of Yang files
There are two classes of Yang files
* Clixon yang files.
* Mandatory: "Standard" yang files necessary for clixon lib/client/backend to run
* Optional: "Standard" yang files for examples and tests
The first two (clixon and mandatory) are always installed. If you want
to change where the are installed, configure with: `--with-yang-installdir=DIR`
Both are always installed. If you want to change where the are
installed, configure with: `--with-yang-installdir=DIR`
The third (optional) is only installed if configure flag
`--enable-optyang` is set. Further, the optional yang files are

1
yang/clixon/Makefile.in
View file

@ -38,7 +38,6 @@ bindir = @bindir@
includedir = @includedir@
datarootdir = @datarootdir@
# See also OPT_YANG_INSTALLDIR for the standard yang files
YANG_INSTALLDIR = @YANG_INSTALLDIR@
YANGSPECS = clixon-config@2021-07-11.yang # 5.3

19
yang/clixon/clixon-config@2021-11-11.yang
View file

@ -47,6 +47,7 @@ module clixon-config {
description
"Added option:
CLICON_PLUGIN_CALLBACK_CHECK
CLICON_YANG_AUGMENT_ACCEPT_BROKEN
Modified options:
CLICON_CLI_GENMODEL_TYPE: added OC_COMPRESS enum
CLICON_YANG_DIR: recursive search
@ -936,7 +937,8 @@ module clixon-config {
type boolean;
default false;
description
"If enabled, make a check of resources before and after each plugin callback code
"Debug option.
If enabled, make a check of resources before and after each plugin callback code
to check if the plugin violated resources.
This is primarily intended for development and debugging but may also be enabled
in a running system.
@ -950,6 +952,21 @@ module clixon-config {
as well as the CLIgen callbacks.
See https://clixon-docs.readthedocs.io/en/latest/backend.html#plugin-callback-guidelines";
}
leaf CLICON_YANG_AUGMENT_ACCEPT_BROKEN {
type boolean;
default false;
description
"Debug option. If enabled, accept broken augments on the form:
augment <target> { ... }
where <target> is an XPath which MUST be an existing node but for many
yangmodels do not.
There are several cases why this may be the case:
- syntax errors,
- features that need to be enabled
- wrong XPaths, etc
This option should be enabled only for passing some testcases it should
normally never be enabled in system YANGs that are used in a system.";
}
leaf CLICON_NAMESPACE_NETCONF_DEFAULT {
type boolean;
default false;

2
yang/mandatory/Makefile.in
View file

@ -42,7 +42,7 @@ datarootdir = @datarootdir@
# See also YANG_INSTALLDIR for the clixon-specific yang files
YANG_INSTALLDIR = @YANG_INSTALLDIR@
YANGSPECS += ietf-inet-types@2020-07-06.yang
YANGSPECS += ietf-inet-types@2021-02-22.yang
YANGSPECS += ietf-netconf@2011-06-01.yang
YANGSPECS += ietf-netconf-acm@2018-02-14.yang
YANGSPECS += ietf-restconf@2017-01-26.yang

82
yang/mandatory/ietf-inet-types@2020-07-06.yang → yang/mandatory/ietf-inet-types@2021-02-22.yang
View file

@ -23,7 +23,7 @@ module ietf-inet-types {
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.
Copyright (c) 2020 IETF Trust and the persons identified as
Copyright (c) 2021 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
@ -35,23 +35,26 @@ module ietf-inet-types {
This version of this YANG module is part of RFC XXXX;
see the RFC itself for full legal notices.";
revision 2020-07-06 {
revision 2021-02-22 {
description
"This revision adds the following new data types:
- ip-address-and-prefix
- ipv4-address-and-prefix
- ipv6-address-and-prefix
- email-address";
- inet:ip-address-and-prefix
- inet:ipv4-address-and-prefix
- inet:ipv6-address-and-prefix
- inet:host-name
- inet:email-address
The inet:host union was changed to use inet:host-name instead
of inet:domain-name.";
reference
"RFC XXXX: Common YANG Data Types";
}
revision 2013-07-15 {
description
"This revision adds the following new data types:
- ip-address-no-zone
- ipv4-address-no-zone
- ipv6-address-no-zone";
- inet:ip-address-no-zone
- inet:ipv4-address-no-zone
- inet:ipv6-address-no-zone";
reference
"RFC 6991: Common YANG Data Types";
}
@ -94,7 +97,6 @@ module ietf-inet-types {
RFC 2460: Internet Protocol, Version 6 (IPv6) Specification
RFC 4001: Textual Conventions for Internet Network Addresses";
}
typedef dscp {
type uint8 {
range "0..63";
@ -143,7 +145,6 @@ module ietf-inet-types {
Note that the port number value zero is reserved by IANA. In
situations where the value zero does not make sense, it can
be excluded by subtyping the port-number type.
In the value set and its semantics, this type is equivalent
to the InetPortNumber textual convention of the SMIv2.";
reference
@ -323,6 +324,7 @@ module ietf-inet-types {
A prefix length value of n corresponds to an IP address
mask that has n contiguous 1-bits from the most
significant bit (MSB) and all other bits set to 0.
The canonical format of an IPv4 prefix has all bits of
the IPv4 address set to zero that are not part of the
IPv4 prefix.
@ -450,10 +452,9 @@ module ietf-inet-types {
for current practice in domain name use, and some possible
future expansion. Note that Internet host names have a
stricter syntax (described in RFC 952) than the DNS
recommendations in RFCs 1034 and 1123, and that systems
that want to store host names in schema node instances
using the domain-name type are recommended to adhere to
this stricter standard to ensure interoperability.
recommendations in RFCs 1034 and 1123. Schema nodes
representing host names should use the host-name type
instead of the domain-type.
The encoding of DNS names in the DNS protocol is limited
to 255 characters. Since the encoding consists of labels
@ -486,21 +487,39 @@ module ietf-inet-types {
(IDNA): Definitions and Document Framework";
}
typedef host-name {
type domain-name {
pattern '[a-zA-Z0-9\-\.]+';
length "2..max";
}
description
"The host-name type represents (fully qualified) host names.
Host names must be at least two characters long (see RFC 952)
and they are restricted to labels consisting of letters, digits
and hyphens separated by dots (see RFC1123 and RFC 952).";
reference
"RFC 952: DoD Internet Host Table Specification
RFC 1123: Requirements for Internet Hosts: Application and Support";
}
typedef host {
type union {
type inet:ip-address;
type inet:domain-name;
type inet:host-name;
}
description
"The host type represents either an IP address or a DNS
domain name.";
"The host type represents either an IP address or a (fully
qualified) host name.";
}
/*
* DISCUSS:
* - Lada suggested to replace the inet:domain-name usage in
* the union with a new host-name definition that follows
* the NR-LDH definition in RFC 5890.
* - It was discussed to define int-domain-name and int-host-name
* that use U-labels instead of A-labels and to add int-host-name
* to the inet:host union, perhaps all gated by an inet:idna-aware
* feature.
* - It is not clear how inet:idna-aware affects inet:email-address
* and inet:uri - do we also need int-uri and int-email-address?
*/
typedef uri {
@ -560,15 +579,6 @@ module ietf-inet-types {
/*
* DISCUSS:
* - It was suggested to add email types following RFC 5322
* email-address (addr-spec, per Section 3.4.1)
* named-email-address (name-addr, per Section 3.4)
* - This sounds useful but the devil is in the details,
* in particular name-addr is a quite complex construct;
* perhaps addr-spec is sufficient, this is also the
* format allowed in mailto: URIs (mailto: seems to use
* only a subset of addr-spec which may be good enough
* here as well).
* - Need to define a pattern that has a meaningful trade-off
* between precision and complexity (there are very tight
* pattern that are very long and complex). The current
@ -576,14 +586,4 @@ module ietf-inet-types {
* domain-literal, obs-domain.
*/
/*
* DISCUSS:
* - There was a request to add types for URI fields (scheme,
* authority, path, query, fragment) but it is not clear how
* commonly useful these types are, the WG was pretty silent
* about this proposal. On the technical side, it is unclear
* whether data is represented with percent escapes resolved
* or not. (Mahesh's proposal does not spell this out, the
* pattern does not allow the % character, which may be wrong.)
*/
}