Re: [Netconf] Request for new groupings in ietf-yang-library

[Martin Bjorklund <[e-mail]>]

Hi,

"Joe Clarke" <[e-mail]> wrote:
> Hello, netconf.  Kent informed me that there is some bis work going on
> relative to the ietf-yang-library.  As part of the work with the
> yang-catalog model, the YANG Catalog team found that while we’d like
> to use the groupings in the ietf-yang-library, not all of the leafs
> are conducive to the case where we don’t have a server (e.g.,
> conformance-type).
> 
> To that end, we would like it if the groupings in ietf-yang-library
> could be broken out in terms of model leafs and implementation leafs.
> Below is a proposed scheme to create new top-level groupings
> separating model data from implementation data.  Thoughts?

I think this makes sense.  I suggest we follow your proposal, but
change the name "common-leafs" to "module-identification-leafs".


/martin

> 
> Joe
> 
> grouping common-leafs {
>    leaf name {
>      type yang:yang-identifier;
>        description
>          "The YANG module or submodule name.";
>    }
>    leaf revision {
>      type union {
>        type revision-identifier;
>        type string { length 0; }
>      }
>      description
>        "The YANG module or submodule revision date.
>         A zero-length string is used if no revision statement
>         is present in the YANG module or submodule.";
>    }
>    description
>      "The YANG module or submodule revision date.
>       A zero-length string is used if no revision statement
>       is present in the YANG module or submodule.";
>  }
> 
> grouping schema-leaf {
>    leaf schema {
>       type inet:uri;
>       description
>         "Contains a URL that represents the YANG schema
>          resource for this module or submodule.
>          This leaf will only be present if there is a URL
>          available for retrieval of the schema for this entry.";
>     }
>     description
>       "These are a subset of leafs from the yang-library (RFC 7895) that
>       provide some
>        extractable fields for catalog modules.  The module-list grouping
>        cannot be
>        used from yang-library as modules themselves cannot have conformance
>        without
>        a server.";
>  }
> 
> grouping imlementation-leafs {
>    leaf-list feature {
>      type yang:yang-identifier;
>      description
>       "List of YANG feature names from this module that are
>        supported by the server, regardless of whether they are
>        defined in the module or any included submodule.";
>    }
>    list deviation {
>      key "name revision";
>      description
>        "List of YANG deviation module names and revisions
>         used by this server to modify the conformance of
>         the module associated with this entry.  Note that
>         the same module can be used for deviations for
>         multiple modules, so the same entry MAY appear
>         within multiple 'module' entries.
>         The deviation module MUST be present in the 'module'
>         list, with the same name and revision values.
>         The 'conformance-type' value will be 'implement' for
>         the deviation module.";
>      uses common-leafs;
>    }
>    leaf conformance-type {
>      type enumeration {
>        enum implement {
>          description
>            "Indicates that the server implements one or more
>             protocol-accessible objects defined in the YANG module
>             identified in this entry.  This includes deviation
>             statements defined in the module.
>             For YANG version 1.1 modules, there is at most one
>             module entry with conformance type 'implement' for a
>             particular module name, since YANG 1.1 requires that,
>             at most, one revision of a module is implemented.
>             For YANG version 1 modules, there SHOULD NOT be more
>             than one module entry for a particular module name.";
>        }
>        enum import {
>          description
>            "Indicates that the server imports reusable definitions
>             from the specified revision of the module but does
>             not implement any protocol-accessible objects from
>             this revision.
>             Multiple module entries for the same module name MAY
>             exist.  This can occur if multiple modules import the
>             same module but specify different revision dates in
>             the import statements.";
>        }
>      }
>      mandatory true;
>      description
>       "Indicates the type of conformance the server is claiming
>        for the YANG module identified by this entry.";
>    }
>    description
>      "This is a set of leafs extracted from the yang-library that are
>       specific to server implementations.";
>  }
> 
> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf