Re: [core] YANG Packages for CoMI

[Andy Bierman <[e-mail]>]

On Mon, Jul 27, 2015 at 3:25 AM, Alexander Pelov <[e-mail]> wrote:

>  Hi Andy!
>
> Thanks for the draft! Seems a good start to get the things moving in the
> direction of having a good, structured introspection mechanism for module
> discovery!
>
> I'm not completely sure that it will be a static document. You still need
> to think of the possibility of a firmware upgrade, in which case you have
> to consider the clients which have obtained your previous package
> descriptions.
>
>
Each package has a name and a revision-date.
The expected use for CoMI would be a new
package revision for each firmware release.



> Why don't you want it to be a YANG module? I would suppose that for a
> structured numbering scheme (such as CoOL) we could have a nice fixed entry
> point for such introspection resource, e.g. moduleID = 1. Alternatively, I
> would think that it should be discoverable through .well-known/core
>
>
Not sure what you mean.
This is static data used to identify a set of YANG modules.
Do you mean why not have the contents of a package be YANG objects
to read from the server?  This would be even more data than the
current YANG module library.

The point of a package list is to avoid listing all the modules, features,
and revision dates.  There is a YANG Package Identifier in sec. 4

  urn:ietf:params:xml:ns:yang:pkg?name=example-sensor314&rev=2015-07-01


This would be the entire response needed to discover the entire YANG
implementation by the server. The size remains the same no matter how many
modules and features are added over time.





> A point to make is that we can have alias mappings through this
> introspection mechanism. Defining such an introspection mechanism for the
> aliases was actually one of the work I was considering for CoOL.
>
>
RESTCONF and NETCONF provide the ability for the client to retrieve
the schema, and get all the meta-data, for every module.
IMO this should be done by a centralized server in CoMI.

But I agree the package data could include alias mappings.
This might be a way to convert YANG Hash to COOL for example,
to optimize frequently used identifiers..





> Best,
> Alexander
>

Andy


>
> Le 27/07/2015 08:29, Andy Bierman a écrit :
>
>
>
> On Sun, Jul 26, 2015 at 11:26 PM, peter van der Stok <
> <[e-mail]>[e-mail]> wrote:
>
>> HI Andy,
>>
>> Is the proposal to make YANG packages compulsory over yang-library in
>> Comi servers and clients?
>>
>>
>  No, it would be optional.
> Another solution approach would be to make the module-set-id values
> global instead of per-server. That might be less work perhaps.
>
>
>  Peter
>>
>
>  Andy
>
>
>>
>> Andy Bierman schreef op 2015-07-26 19:44:
>>
>>> Hi,
>>>
>>> Michel raised some issues with the YANG library draft
>>> http://datatracker.ietf.org/doc/draft-ietf-netconf-yang-library/
>>>
>>> Maybe CoMI needs its own optimized module library.
>>> I am concerned that data sizes of the YANG library will be
>>> too big in some really constrained environments.
>>>
>>> I wrote a draft that defines a way to specify the contents of the
>>> YANG library in a single static document, called a YANG package.
>>> http://datatracker.ietf.org/doc/draft-bierman-netmod-yang-package/
>>>
>>> If there was a "shorthand" resource that listed YANG packages, instead
>>> of YANG modules, then the CoMI client that supported YANG packages
>>> could read that instead of the module library.
>>>
>>> The YANG package message response can identify a single package
>>> (e.g. match the firmware) so the size of the response will remain very
>>> small, and not depend on the entire list of modules, features,
>>> and deviations. The data savings could 1000X for 100 modules.
>>>
>>> The client needs to retrieve the library first-time and anytime it
>>> changes.
>>> The module-set-id values are per-server, not global. This could be a
>>> significant bottleneck when a CoMI client starts or restarts, and
>>> manages lots of servers.
>>>
>>> Andy
>>>
>>>
>>> _______________________________________________
>>> core mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/core
>>>
>>
>
>
> _______________________________________________
> core mailing [e-mail]://www.ietf.org/mailman/listinfo/core
>
>
>