Hello,
Similarly to Andy's idea we are thinking about declaring data
nodes static-data. This means that
they can not be changed via the management interface e.g.
CLI/Netconf/Restconf
that they are changed very infrequently ( at upgrade)
On Wed, Sep 28, 2016 at 7:52 AM, Dale R. Worley wrote:
> Andy Bierman writes:
> > Back before there was YANG 1.0 I proposed the concept of constants in
> YANG
> > but this was seen as too complicated. This is the exact use-case I had
> in
> > mind.
> >
Andy Bierman writes:
> Back before there was YANG 1.0 I proposed the concept of constants in YANG
> but this was seen as too complicated. This is the exact use-case I had in
> mind.
> The YANG module would #define the constants (maybe with a default or no
> value)
> and they
On Tue, Sep 27, 2016 at 4:58 PM, Alex Campbell
wrote:
> > Dale R. Worley writes:
> >> Ladislav Lhotka writes:
> >>> typedef Compression-Method {
> >>> ...
> >>> }
> >>>
> >>> list node {
> >>> config true;
> >>> key name;
>
> Dale R. Worley writes:
>> Ladislav Lhotka writes:
>>> typedef Compression-Method {
>>> ...
>>> }
>>>
>>> list node {
>>> config true;
>>> key name;
>>>
>>> string name;
>>>
>>> leaf-list supported-compression-methods {
>>> type
Ladislav Lhotka writes:
>> typedef Compression-Method {
>> ...
>> }
>>
>> list node {
>> config true;
>> key name;
>>
>> string name;
>>
>> leaf-list supported-compression-methods {
>> type Compression-Method;
>> config false;
>> }
>>
>> Compression-Method
"Dale R. Worley" writes:
> Balazs Lengyel writes:
>> Problem: how do you restrict values for (3) - file-compression so that
>> it is one of the nodes-supported-compression-types. The natural solution
>> would be to use a must expression or a
On Sun, Sep 4, 2016 at 3:49 PM, Alex Campbell
wrote:
> What prevents features from being units of conformance?
>
They are in a sense.
The "base module" is everything without any features.
Then each feature can be added somewhat independently to the base module.
So
What prevents features from being units of conformance?
From: netmod on behalf of Juergen Schoenwaelder
Sent: Friday, 2 September 2016 5:06 a.m.
To: Andy Bierman
Cc: netmod@ietf.org
Subject:
On Thu, Sep 01, 2016 at 09:41:04AM -0700, Andy Bierman wrote:
> Hi,
>
> We keep having discussions about YANG conformance related issues.
> The only unit of conformance is the YANG module, so it is possible to
> think the way to solve the conformance/discovery problem is to put every
> definition
Hi,
We keep having discussions about YANG conformance related issues.
The only unit of conformance is the YANG module, so it is possible to
think the way to solve the conformance/discovery problem is to put every
definition
in its own module. This is operationally absurd of course, so someday
One alternative for getting rid of unsupported "identity"-s is to use
"if-feature" as sub-statement which is now supported in YANG 1.1. This
would be an elegant solution for the example with the 3 compression
methods. However for standard models one will either have to live with
the many
Hello,
The proposed iana-entity.yang seems to take the same approach: one file
defining 28 identities.
And I share all your concerns about iana-if-type.
Balazs
On 2016-08-31 14:16, Vladimir Vassilev wrote:
On 08/31/2016 12:38 PM, Ladislav Lhotka wrote:
On 31 Aug 2016, at 11:10, Vladimir
On 08/31/2016 01:10 PM, Balazs Lengyel wrote:
Hello,
The problem is not just about identities. It can be a value range.
If your example was about value range then a deviation would be a
solution. Then we have the same case for modularization. YANG files
defining deviations loaded when the
Hello,
The problem is not just about identities. It can be a value range.
Sometimes we have a generic module like iana-interface type that list a
lot of identities, and I don't want to have one YAM file per identity,
to allow a fine control. Also sadly it is not possible to have a
deviation
> On 31 Aug 2016, at 11:10, Vladimir Vassilev wrote:
>
> If you design your models using identityref and define the identities in
> separate modules e.g. compression-zip.yang, compression-gzip.yang, etc. you
> can just chose not to load the particular YANG models
If you design your models using identityref and define the identities in
separate modules e.g. compression-zip.yang, compression-gzip.yang, etc.
you can just chose not to load the particular YANG models containing the
identities not supported when your device starts.
If you absolutely can not
Balazs Lengyel wrote:
> Hello Jan,
>
> This may be the best solution we have, but nacm rules may be changed,
> and then device limits might be edited by the operator, and then we
> have a problem.
>
> The good solution would be to indicate that this is read-only
Hello Jan,
This may be the best solution we have, but nacm rules may be changed,
and then device limits might be edited by the operator, and then we have
a problem.
The good solution would be to indicate that this is read-only static
data, and allow must, leafref towards it. However I don't
Balazs Lengyel writes:
> Problem: how do you restrict values for (3) - file-compression so that
> it is one of the nodes-supported-compression-types. The natural solution
> would be to use a must expression or a leaf-ref, but as
> nodes-supported-compression-types
Balazs,
> We have the following design pattern.
>
> 1) An enumeration or a set of identities are defined that define a set of
> options generally supported by Ericsson products. (e.g. supported
> compression algorithms)
> 2) The specific node sets in run-time a leaf-list indicating the set of
21 matches
Mail list logo