Re: [netmod] initial comments on draft-rwilton-netmod-yang-packages

[Andy Bierman <[e-mail]>]

Hi,

I can see some utility in a module-set artifact.
Every tool has a different way of specifying a set of [module, revision,
features, deviations].
The module-set has these parameters (plus other metadata)

    rc:yang-data module-set {
      container module-set {
          uses yanglib:module-set-parameters;
       }
    }


The application purpose of the module-set is not relevant here.
It could be the library subset needed for L2VPN, it could be the entire
module list
for a specific vendor/model/version. It could be the module-set needed
to reproduce a bug.


Andy



On Thu, Jan 31, 2019 at 9:24 AM Robert Wilton <[e-mail]> wrote:

>
> On 30/01/2019 20:51, Andy Bierman wrote:
>
>
>
> On Wed, Jan 30, 2019 at 10:04 AM Robert Wilton <[e-mail]> wrote:
>
>>
>> On 30/01/2019 17:31, Andy Bierman wrote:
>>
>>
>>
>> On Wed, Jan 30, 2019 at 8:02 AM Robert Wilton <[e-mail]> wrote:
>>
>>>
>>> On 30/01/2019 15:16, Andy Bierman wrote:
>>>
>>>
>>>
>>> On Wed, Jan 30, 2019 at 4:19 AM Robert Wilton <[e-mail]> wrote:
>>>
>>>> Hi Andy,
>>>>
>>>> Thanks for the comments.
>>>> On 30/01/2019 01:22, Andy Bierman wrote:
>>>>
>>>> Hi,
>>>>
>>>> I originally brought up this issue in July 2015
>>>> https://datatracker.ietf.org/doc/draft-bierman-netmod-yang-package/
>>>>
>>>> Yes.
>>>>
>>>> The solution I propose is different in the sense that it uses YANG
>>>> instance data to define YANG packages rather than new YANG keywords.   I
>>>> believe that this should make it a lower cost solution to define and
>>>> implement.
>>>>
>>>>
>>>>
>>> I think yangvalidator.org has a better solution that does not change
>>> YANG conformance.
>>>
>>> Do you mean that we can just use zip files with the list of modules?
>>>
>>
>> I don't care about the solution details yet. They are 2nd order problems.
>>
>> Conformance means "what modules are required to be implemented together".
>> It is not clear that this problem can be solved.  The augment-stmt
>> defines implicit
>> multi-module conformance.  I am not convinced that the extra work of
>> defining package conformance
>> is worth it.
>>
>> So, I'm not proposing backing any sort of package conformance into the
>> language at all.  A package is just metadata that defines that a set of
>> modules, at particular revisions/versions, work together and can represent
>> part of a YANG schema.
>>
>> This is equivalent to
>>  - how a zip file of YANG modules provided to yangvalidator would work.
>>  - getting the contents of YANG library from a server (but a YANG
>> packages soln can also work offline)
>>  - fetching the modules from YANG catalog (if they have been labelled
>> appropriately), although I'm not convinced that this universally works
>> today.
>>
>
> This sort of metadata could be provided by module tags.
> A vendor or SDO could define module-tags that represent packages.
>
> Yes, this is a different way to assigning membership, although I'm not
> convinced that it is better.
>
> I think that such a scheme could work without versioning, but I'm not sure
> that it will work so well once package versioning is considered, because to
> handle versioning the tags don't just need to represent which package they
> belong to, they also should identify which version of that package.
>
> E.g. [e-mail] might be tagged with:
> "ietf-base-pkg@0.0.1" <ietf-base-pkg@0.0.1>, "ietf-base-pkg@0.0.2"
> <ietf-base-pkg@0.0.2>, "ietf-base-pkg@1.0.0" <ietf-base-pkg@1.0.0>,
> ietf-base-pkg@1.1.0", ...
>
> If packages change quite frequently then you might find that a module
> needs 50+ tags to identify which particular packages it belongs to.
>
> Any without knowing the package version, I don't see that there would be
> enough information to build a schema since you wouldn't know which versions
> of YANG modules to use.
>
>
>
>
>
>
>> But in terms of the usability of YANG, I don't think that doing
>> conformance only at the module level is really sufficient.  Clients need to
>> be coding against sets of modules at particular versions that are known to
>> work together, and known that multiple server vendors will implement.
>>
>> A pick and mix appropriate to module revisions doesn't seem to help
>> anyone.
>>
>>
>>
> I get all the different components and variables one might have for a
> package.
> I am not as convinced (as in 2015) that standard packages could be simple
> and widely deployed..
> Now it seems vendors implement an ad-hoc subset + additions to everything.
> It doesn't help to define a new package variant to match the vendor
> implementation.
> The YANG library can do that already.
>
> YANG library is only on the box at the moment, and it just gives a flat
> list of modules.
> I would like it to also be available off the box and have more structure.
>
> E.g. I would like IETF to define an L2VPN package that contains the basic
> set of YANG modules that a device that supports L2VPN services would be
> expected to implement at a minimum.
>
> Then, rather that checking the output of YANG library to see that it has
> all the necessary modules to implement an L2VPN service, I could instead
> check whether the package implemented by the device imports the L2VPN
> package.  And if it does import that package, I can then also see which
> version of that package it implements (rather than checking every module
> version).
>
>
> You seem more optimistic than me that the industry is actually ready,
> willing, and able
> to implement standard YANG packages.
>
> If we want YANG to be properly successful then I see that it has go
> there.  But nobody can do this today until there is a way that such
> packages can be defined, and versioned, and we start defining what these
> standard packages look like.
>
>
>
>
>
>
>> The issue of what modules does vendor A implement is not a conformance
>> problem.
>> It is just more metadata and YANG Catalog is focused on providing that
>> data.
>>
>> Does YANG catalog indicate the set of IETF modules that I would need to
>> implement L2VPN services on a device?
>>
>>
> This seems like a separate problem, but actually it can help by searching
> a lot of known modules.
> In order to know what vendor A, B, and C have in common, you need to get
> the catalog info for each vendor.
>
> Module tags can also solve this problem.
>
> But when there are multiple vendors with multiple devices, with multiple
> versions of software available then this looks like a hard problem to solve.
>
> I would like someone (or a program) to be able to look at a package
> definition file, and determine if it implements what is required, and what
> software version is needed, and whether they are deviations that matter.
>
> When my client then connects to that device, I would like the client to be
> able to check that it implements that modules that I expect it to.  I would
> strongly prefer if this could be done by returning a small amount of data,
> rather than a list of 1000 modules/sub-modules for every server that I
> connect to.
>
> Module tags won't tell the client that it implements all the required
> modules that implement the L2VPN service, it will just indicate that
> implements some modules which can be used to implement an L2VPN service.
>
>
>
>
>> Module tags could be used to do this (another packaging solution), but
>> this would cause a proliferation of tags when it comes to versioning, since
>> I don't think that you can cleanly bake semver into module tags.
>>
>>
>>
>> I don't really see how this helps.
>>>
>>> Consider:
>>> - server vendor A, implements some subset of the OpenConfig YANG
>>> modules, each at a particular version, along with some deviations and
>>> vendor augmentations.
>>> - server vendor B, implements the same subset of the OpenConfig YANG
>>> modules, but at different versions, along with some deviations and vendor
>>> augmentations.
>>> - server vendor C, implements a slightly different set of the OpenConfig
>>> YANG modules, but at different versions, along with some deviations and
>>> vendor augmentations.
>>>
>>> As a client, how do I know what module versions to code against, when I
>>> want to work with devices provided by all three vendors?
>>>
>>
>>
>> The vendors publish their implementation details on yangcatalog and you
>> get the info
>> and see what modules are in common.
>>
>> There are only market requirements determining what group of modules has
>> to exist
>> in an implementation.  It is not clear to me that formalizing these
>> requirements
>> is something the industry will do effectively.  Module tags already
>> provide a way
>> to conceptually group modules together.
>>
>> Seems like every vendor has openconfig, foo-openconfig, and
>> foo-openconfig-deviations
>> so that there are no agreed upon subsets. Even if openconfig had properly
>> documented
>> subsets, would your client even be able to code to it (ignoring add-ons
>> and deviations).
>>
>> I think that answer will converge on yes, I don't know how long it will
>> take.  It would probably be better if at the time that protocol
>> specifications are written, that the authors of the specifications also
>> write the YANG modules to manage them at the same time.
>>
>>
>> I might be wrong, but I think that the OC solution is use git tags, so
>>> they tag sets of modules that are expected to work together and also to
>>> provide a linear release history of their sets of modules.  So, if everyone
>>> implements the module versions associated with a git tag then it should
>>> convert a two dimensional problem of module revisions into a linear
>>> problem.  The YANG packages draft is aiming to provide a solution to this
>>> problem that doesn't require the use of git, or sending zip files of
>>> modules around.
>>>
>>
>> At the moment, it seems that everyone is doing this in different ways:
>>>  - Yumawork customers/servers use zip files of modules for conformance.
>>>
>>
>> Not sure what this means.
>> Actually the server libraries can be loaded and unloaded.
>> Module can be standalone libraries or grouped as bundles.
>> But this seems like an implementation detail, unrelated to conformance.
>>
>>
>>  - OpenConfig client/server implementations use git tags, or git
>>> refpoints.
>>>  - Cisco customers use the contents of directories on github YangModels.
>>>
>>> Finally, this draft doesn't change YANG conformance, it just expresses
>>> it in what is intended to be a simpler way.
>>>
>>
>> It adds another conformance system to maintain.
>> The language only recognizes module to module interfaces, not package to
>> package.
>>
>> I propose that at the language level conformance is at the module level
>> (modulo import-by-version).
>>
>>
>> That adds more complexity. It doesn't take away any complexity.
>>
>> It is meant to be a simpler way of packaging up, and trying to control
>> and manage the complexity that already exists today.
>>
>> E.g. I could give a YANG compiler the name, version, and location of a
>> package and tell it to build the entire schema associated with that
>> package.
>>
>
> This is a tool implementation detail, not a conformance issue.
> It would be nice to have a standard format for the YANG library for a tool
> to use.
> You seem to be proposing an artifact containing ietf-yang-library
> information.
> That seems OK to me, but it should not have anything to do with
> conformance.
> It is just a standard way to express a module-set in a yang-data artifact.
>
> Yes, what I am proposing is close to a file containing ietf-yang-library
> information, but I want it to be hierarchical/recursive, where as the
> schema defined by YANG library bis is flat, and I want the data to also
> optionally be made available in YANG library.
>
> What I am proposing here doesn't change conformance of the YANG language
> in any way, not does it replace YANG library.
>
> Thanks,
> Rob
>
>
>
>
>
>> In a somewhat similar way, when I write code, my build file specifies
>> which libraries I depend on, and their versions, but I can leave it to the
>> build tool to determine what those libraries themselves depend on and
>> recursively pull in all the dependencies.
>>
>>
>>
>> If there was a standard to load and unload modular functionality at
>> boot-time or run-time,
>> then I could see why there is a need to have a standard to define YANG
>> packages.
>>
>> I agree that this is another example of where they could be useful.
>>
>> Thanks,
>> Rob
>>
>>
>>
> Andy
>
>
>>
>>
>>> Thanks,
>>> Rob
>>>
>>>
>>>
>> Andy
>>
>>
>>>
>>>
>>> Andy
>>>
>>>
>>>>
>>>> I don't think the WG ever agreed on the problem that needs to be solved,
>>>> and that is still the case.
>>>>
>>>> That wasn't quite my impression.  I also think that folks were busy
>>>> focusing on other WG activity and didn't necessarily have the time to
>>>> concentrate on this.
>>>>
>>>> My draft was aiming on solving two broad problems:
>>>>
>>>>    The main goals of YANG package definitions include, but are not
>>>>    restricted to:
>>>>
>>>>    o  To act as a simplified YANG conformance mechanism.  Rather than
>>>>       conformance being performed against a set of individual YANG
>>>>       module revisions, conformance could also be more simply stated in
>>>>       terms of YANG packages, with a set modifications (e.g. additional
>>>>       modules, deviations, or features).
>>>>
>>>>    o  To allow YANG datastore schema to be specified in a more concise
>>>>       way rather than having to list all modules and revisions.  YANG
>>>>       package definitions can be defined in documents that can be
>>>>       referenced by a URL rather than requiring explicit lists of
>>>>       modules to be shared between client and server.  Hence, a YANG
>>>>       package must contain sufficient information to allow a client or
>>>>       server to precisely construct the schema associated with the
>>>>       package.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> In reality each server has 1 package -- its entire library.
>>>>
>>>> This doesn't apply to all servers.  For a long time, as a vendor, we
>>>> have had separate packages that can be independently installed, and which
>>>> extend the management model to cover the new functionality.  E.g. BNG
>>>> functionality could be in a separate, independently installable, package on
>>>> top of the base router functionality.
>>>>
>>>> For a Linux server, the manageability interface will depend on what
>>>> applications have been installed.
>>>>
>>>>
>>>> The SEMVER work shows
>>>> that vendors are treating platforms as independent release trains, and
>>>> not really
>>>> developing loadable packages.
>>>>
>>>> This depends on the vendor.  The YANG versioning work is trying to find
>>>> a solution that works across the industry.  I believe that the versioning
>>>> requirements are different for standards developed modules, vs industry
>>>> developed modules, vs vendor modules.
>>>>
>>>>
>>>>
>>>> I think YANG 1.2 improvements for conformance (e.g., YANG-redirects,
>>>> SEMVER import)
>>>> and  the YANG Catalog can solve the module compatibility issues. It is
>>>> more of a documentation
>>>> problem than a standards problem.
>>>>
>>>> Having a standard YANG module that can be used to define packages is
>>>> something this is useful and should be standardized.  I believe that this
>>>> is better than each vendor coming up with their own solution for this
>>>> problem.
>>>>
>>>> Thanks,
>>>> Rob
>>>>
>>>>
>>>>
>>>>
>>>> Andy
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Jan 29, 2019 at 4:55 PM Sterne, Jason (Nokia - CA/Ottawa) <
>>>> [e-mail]> wrote:
>>>>
>>>>> Thanks Rob. Please see inline.
>>>>>
>>>>> Jason
>>>>>
>>>>>
>>>>>
>>>>> *From:* Robert Wilton <[e-mail]>
>>>>> *Sent:* Thursday, January 24, 2019 1:16 PM
>>>>> *To:* Sterne, Jason (Nokia - CA/Ottawa) <[e-mail]>;
>>>>> [e-mail]
>>>>> *Subject:* Re: initial comments on draft-rwilton-netmod-yang-packages
>>>>>
>>>>>
>>>>>
>>>>> Hi Jason,
>>>>>
>>>>> Thanks for the review and comments.
>>>>>
>>>>> I've put some responses inline ...
>>>>>
>>>>> On 24/01/2019 14:56, Sterne, Jason (Nokia - CA/Ottawa) wrote:
>>>>>
>>>>> Hi guys,
>>>>>
>>>>>
>>>>>
>>>>> I've gotten most of the way through the draft and have some initial
>>>>> comments. I haven't digested the section 10 open issues yet or the examples.
>>>>>
>>>>>
>>>>>
>>>>> Section 5 mentions the following:
>>>>>
>>>>>    YANG library is augmented to allow servers to report the packages
>>>>>
>>>>>    that they implement and to associate those packages back to
>>>>>
>>>>>    particular datastore schema.
>>>>>
>>>>>
>>>>>
>>>>> Does the combination of this draft and rfc7895bis somehow allow the
>>>>> same package to be advertised in 2 different datastores, but with different
>>>>> deviations in each datastore? I'm thinking of a case, for example, where a
>>>>> package is fully supported in the running but the package minus a few
>>>>> modules (or parts of modules) is supported in the operational datastore.
>>>>> There seems to be a 1:1 relationship between package and rfc7895bis schema.
>>>>>
>>>>> So, the intention is no, not directly.
>>>>>
>>>>> My aim here is that <running> would implement package "foo", and
>>>>> <operational> would implement package "modified-foo".  Package
>>>>> "modified-foo" would import package "foo" and also specify the set of
>>>>> modules that contain the deviations "foo".
>>>>>
>>>>> I didn't want a server to be able to see that I implement package
>>>>> "foo", but then I have all these deviations that change its behavior.
>>>>> Instead, it is really implementing a different package that is based on
>>>>> "foo".
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> The packages draft doesn't include any specific leaf-list for
>>>>> deviations. Section 7.2 mentions that deviations could be expressed by
>>>>> including modules that happen to contain deviations. That seems a bit
>>>>> inconsistent with rfc7895bis that has a specific leaf-list of deviations
>>>>> (and NETCONF hello that specifically explicitly labels deviation modules).
>>>>>
>>>>> I'm conflicted on this one.  I don't really like the deviation list in
>>>>> YANG library because I regard it as a duplicate source of information, and
>>>>> then there is a question of which source of data do you trust.  E.g. do you
>>>>> process a deviation in a module that is not listed in the deviations module
>>>>> list?
>>>>>
>>>>> *[>>JTS: ] Good point. I suppose this issue applies today already.
>>>>> i.e. what if one of the modules advertised in the <hello> is a module of
>>>>> deviations (without having been referenced by another module as a deviation
>>>>> module).*
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Section 5.1 says the package must be referentially complete. I can see
>>>>> the advantages of that although wondering if that might limit flexibility
>>>>> of partitioning modules into packages. I could imagine use cases for
>>>>> dividing a large set of modules into a few packages that might rev
>>>>> independently but can still all work together (especially if they rev in a
>>>>> bc manner). But maybe that just starts to introduce too much complexity?
>>>>>
>>>>> Yes, having partial packages may be useful.  Perhaps just adding a
>>>>> leaf to indicate whether a package is referentially complete could be the
>>>>> answer here.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I didn't understand this part of section 5.1. Can you maybe illustrate
>>>>> with an example?
>>>>>
>>>>>       The version/revision of a module listed in the package module
>>>>> list
>>>>>
>>>>>       supercedes any version/revision of the module listed in a
>>>>> imported
>>>>>
>>>>>       package module list.  This allows a package to resolve any
>>>>>
>>>>>       conflicting implemented module versions/revisions in imported
>>>>>
>>>>>       packages.
>>>>>
>>>>> Probably best to see example B.3. in the appendix because it exactly
>>>>> illustrates this point.
>>>>>
>>>>> Basically:
>>>>> 1) Packages must explicitly list all versions of all modules they
>>>>> define/import.
>>>>> 2) If two imported packages define different versions of modules, then
>>>>> the package that is importing them needs a way to define which version to
>>>>> use.
>>>>> 3) A package needs a way to override the version of module specified
>>>>> in an imported package.
>>>>>
>>>>> *[>>JTS: ] Thx. That example does help. I suppose the designer of the
>>>>> package needs to carefully check that the version they select can be
>>>>> successfully used by all the modules in the package. *
>>>>>
>>>>> *I think there is a minor typo in example B.3.  The example-3-pkg is
>>>>> importing "* *example-import-1" but I believe you meant "* *example-import-1-pkg"
>>>>> (and some for import-2).*
>>>>>
>>>>>
>>>>>
>>>>> It might be a good idea to add a parent-version to the package module
>>>>> (to allow tracking lineage of packages).
>>>>>
>>>>> Agreed, or maybe allowing a revision history like modules.  Not sure
>>>>> which is better here.  Packages could get a lot of updates, and a long
>>>>> revision history would not be helpful at all.
>>>>>
>>>>> *[>>JTS: ] I think a minimum of just specifying the direct parent is
>>>>> enough to build the full tree of lineage. We don't need a long history of N
>>>>> revisions.*
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I like the use of groupings. That allows a manager to use this as a
>>>>> building block to compose a model that has a list of packages.
>>>>>
>>>>> OK.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Having a global list of mandatory features (vs having the mandatory
>>>>> feature a per-module list) means inventing the new <module-name>:<feature>
>>>>> format. Should we instead somehow put the mandatory features against each
>>>>> module of the package?
>>>>>
>>>>> Perhaps.  My thinking here was to have the list of features high up
>>>>> and very easy to find/parse.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> The location leaf is a uri but then the description says it must be a
>>>>> url (where the model can be retrieved). I do like that the namespace is
>>>>> separate from the location, but maybe we should make location a url type?
>>>>>
>>>>> Yes, I was thinking that is should be a URL.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Do we need a namespace for package names in the model?
>>>>>
>>>>> I had them in an earlier version, but I took them out, because I
>>>>> wasn't sure that they are really useful/required.
>>>>>
>>>>> Defining a format to make package names themselves globally unique
>>>>> might be sufficient.
>>>>>
>>>>> *[>>JTS: ] I'm OK with that. It is similar to how we're finding that
>>>>> it is useful that YANG module names are globally unique (i.e. by naming
>>>>> with ietf-xxxx or companyabc-xxx).*
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> In 7.3 we only reference module-sets and not modules. So the grouping
>>>>> of modules into sets and packages must be the same?
>>>>>
>>>>> Not necessarily.
>>>>>
>>>>> I am trying to reuse the module-set definitions as much as possible
>>>>> (to avoid duplication).  One issue here is that module-sets are combined
>>>>> then all the modules must not overlap, which doesn't make the mapping to
>>>>> module-sets quite so clean.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> A schema can only have a single package. I think that works but it
>>>>> means a server would advertise multiple schemas if it wants to support
>>>>> multiple packages. I'm not sure if there are some downsides to that (it
>>>>> just surprised me).
>>>>>
>>>>> My aim here was:
>>>>>  - multiple packages are advertised in yang-library/packages
>>>>>  - datastores only report that they "implement" one [top level]
>>>>> package version.  [The package itself might import other packages.]
>>>>>
>>>>> If we do package selection, then for a given YANG client session, and
>>>>> the version of YANG library available/reported by that session, it would
>>>>> appear as if the server only implements one top level package for a
>>>>> datastore.  Different clients choosing different versions would see
>>>>> slightly different output depending on which package version they had
>>>>> selected to use.
>>>>>
>>>>> Thanks again for the review and the comments!
>>>>>
>>>>> Rob
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Jason
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *From:* netmod <[e-mail]> <[e-mail]> *On
>>>>> Behalf Of *Robert Wilton
>>>>> *Sent:* Thursday, December 20, 2018 12:45 PM
>>>>> *To:* [e-mail]
>>>>> *Subject:* [netmod] YANG Packages
>>>>>
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> I've written up an ID for a potential solution for YANG packages using
>>>>> instance data:
>>>>>
>>>>> Abstract
>>>>>
>>>>>
>>>>>
>>>>>    This document defines YANG packages, an organizational structure
>>>>>
>>>>>    holding a set of related YANG modules, that can be used to simplify
>>>>>
>>>>>    the conformance and sharing of YANG schema.  It describes how YANG
>>>>>
>>>>>    instance data documents are used to define YANG packages, and how the
>>>>>
>>>>>    YANG library information published by a server can be augmented with
>>>>>
>>>>>    additional packaging related information.
>>>>>
>>>>> https://datatracker.ietf.org/doc/draft-rwilton-netmod-yang-packages/
>>>>>
>>>>> Potentially this work may be of use as part of the YANG versioning
>>>>> design team work.  In addition, if the WG likes this approach of defining
>>>>> YANG packages, then it might also be useful to bind a schema to a YANG
>>>>> instance data document.
>>>>>
>>>>> Some questions for members of the WG:
>>>>>
>>>>> 1) Do members of the WG agree that YANG packages is something that
>>>>> needs to be solved?
>>>>>
>>>>> 2) Is the approach in this draft of defining these as instance data
>>>>> documents a good starting point?
>>>>>
>>>>> 3) This approach augments YANG library-bis, reusing module-sets, but
>>>>> not replacing the way that modules are reported in YANG library-bis.  Is
>>>>> this the right approach?  This approach tries to allow module-sets to be
>>>>> reused for both schema and packages, but the YANG library-bis rules for
>>>>> combining module-sets (i.e. no conflicts) may make this harder to really
>>>>> reuse the module-sets for both purposes.
>>>>>
>>>>> Of course, any other comments or feedback is welcome and appreciated.
>>>>>
>>>>> Thanks,
>>>>> Rob
>>>>>
>>>>> _______________________________________________
>>>>> netmod mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>
>>>>