Re: [netmod] Schema-mount question: Augmentation to the Mounted Module

[Xufeng Liu]

Hi Martin,

> -Original Message-
> From: Martin Bjorklund [mailto:m...@tail-f.com]
> Sent: Wednesday, June 14, 2017 1:07 PM
> To: lho...@nic.cz
> Cc: lber...@labn.net; xufeng.liu.i...@gmail.com; draft-ietf-netmod-schema-
> mo...@ietf.org; netmod@ietf.org
> Subject: Re: [netmod] Schema-mount question: Augmentation to the Mounted
> Module
> 
> Ladislav Lhotka  wrote:
> >
> > > On 14 Jun 2017, at 13:43, Lou Berger  wrote:
> > >
> > > Hi,
> > >
> > > (speaking as contributor...)
> > >
> > >
> > > On 6/14/2017 7:17 AM, Ladislav Lhotka wrote:
> > >> Hi Xufeng,
> > >>
> > >> please see my answers inline.
> > >>
> > >> Xufeng Liu  writes:
> > >>
> > >>> Hi Lada,
> > >>>
> > >>>
> > >>>
> > >>> We have got two questions on how to specify the module entries in
> > >>> a
> > >>> schema:
> > >>>
> > >>>
> > >>>
> > >>> 1. Are augmentations of parent modules inherited when augmented
> > >>> module is listed in schema-mounts schema?
> > >>>
> > >>> For example, ietf-ospf module augments ietf-routing. When we
> > >>> include ietf-routing to the schema entry, is ietf-ospf automatically
> included?
> > >> No, you also have to include "ietf-ospf" in the "module" list
> > >> inside the corresponding "schema" entry, exactly as you do in the
> > >> top level YANG library, otherwise ietf-ospf won't be mounted.
> > >
> > > I agree.  The draft should have text that makes this explicit.
> >
> > Why? It should be sufficiently clear that modules that are not listed
> > in "schema" are not present in the mounted schema. An augment is just
> > a special mechanism of contributing schema nodes.
> 
> Yes I agree.  But let's see if we can clarify the text.  Xufeng, what in
the current
> text led you to believe that a module in the parent schema would be
> automatically present in the mounted schema?
> 
[Xufeng] Thanks for looking at this. The confusion is because of the lack of
text, I would say. The term "mount" has an analogy to the Unix file system
"mount", where what we only specify the parent directory and child file
system (the connecting relationship at the connection point). Also, similar
is the command for the Unix soft/hard links, where we don't need to check if
there are other links under the child. 

> > >>> 2.  When we have ietf-yang-library mounted under a parent (LNE),
does
> > >>> ietf-yang-library have to contain exactly the same list of Yang
> > >>> modules as the list contained in the "schema" entry under
> > >>> "schema-mount"?
> > >> I am not sure I understand but do you mean an LNE mounted schema
> > >> defined via the "use-schema" case that also includes
> > >> ietf-yang-library? This is a corner case we probably haven't
> > >> thought about but it IMO doesn't make any sense to do so because
> > >> the applicable YANG library that counts is inside the "schema"
> > >> entry. Martin, should we address this anomaly?
> > >
> > > I think this is a very real scenario for LNE.  Consider a 'host'
> > > system
> > > that allows read only views of the LNE and wants the benefit of
> > > "use-schema".  In this case, library under the mount point is still
> > > needed for client access within the mounted LNE.
> >
> > In this case it would IMO be much better if the server inside the LNE
> > provide YANG library data separately for its clients. The client of
> > the host system needn't see it because it is just redundant.
> >
> > >
> > >
> > > It seems to me that in this case the mounted library module data
> > > must exactly match what is listed in the corresponding "schema"
> > > entry under "schema-mount" in order to ensure deterministic client
> views/behavior.
> > > Again, I think this should be made explicit in the draft.
> >
> > Another option is to ban ietf-yang-library in schemas mounted via
> > "use-schema".
> 
> This won't help.  The question is still the same - if you use
"use-schema", and
> one of the mounted modules is "ietf-yang-library", does the contents of
the
> yang library in both places have to be the same?
> 
> Anyway, I think the answer is that from the current specification, it
follows that
> the contents *will* be the same.
> 
> 
> /martin
> 
> 
> 
> > I still think it is wrong to tout "inline" and "use-schema" as the
> > same "schema mount" concept. If we clearly separated the two concepts,
> > "inline" would become an absolute no-brainer requiring just a single
> > YANG extension statement, and "use-schema" would also be easier to
> > explain with no confusing exceptions and qualifications. It's just
> > simple divide-and-conquer in terms of the spec, with no limitations
> > compared to the current options.
> >
> > Lada
> >
> > >
> > >> BTW, I think that normally LNE schema is supposed to be mounted
> > >> using the "inline" case, and then of course ietf-yang-library is
> > >> required but there is no "schema" entry under "schema-mounts" to
> > >> worry about.
> > > Both inline and non-inline LNE usage is expected in real systems...

[netmod] XPath questions about revised datastores

[Andy Bierman]

Hi,

I don't know if getting rid of /foo-state is such a great idea,
especially wrt/ counters and other objects that are not
related to intended config vs. applied config.

Q1) how does a client know the difference between an auto-generated
foo-state.yang and a real foo-state.yang?  Seem like a YANG extension
is needed to flag an auto-generated foo-state.yang

Q2) How does XPath reference an operational node if the /foo-state
subtree has been moved to the /foo config subtree?

module foo {

 container foo {
  leaf stat-collect-type {
 type enumeration {
   enum stat-set1;
   enum stat-set2;
 }
   }
  }

 container foo-state {
  config false;
  leaf stat-collect-type {
 type enumeration {
   enum stat-set1;
   enum stat-set2;
 }
   }
   container stat-set1 {
  when "../stat-collect-type = 'stat-set1'";
  ...
   }
   container stat-set2 {
  when "../stat-collect-type = 'stat-set2'";
  ...
   }
 }
}

In this example, there is a request stat collect type /foo/stat-collect-type
and there is an operational value (what the server/device is capable
of collecting -- e.g. client requests stat-set2 knowing the server
will change it to stat-set1 if set2 not supported)

So if /foo-state is folded into /foo (because that is the intent -- to get
rid of this extra stat-collect-type leaf), then how do the when-stmts
get applied to the operational value instead of the configured value?
The same issue applies if the when-stmts are within an augment-stmt

WANT:

 augment /foo-state {
when "stat-collect-type = 'stat-set1'";
container stat-set1 {
   ...
}
 }

RD Provides:

  augment /foo {
when "stat-collect-type = 'stat-set1'";
container stat-set1 {
   config false;
   ...
}
 }

There is no way to use when-stmt to reference the operational value.
This is a rather common usage of the when-stmt, so it should not
be removed if RD is used.



Andy
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Schema-mount question: Augmentation to the Mounted Module

[Martin Bjorklund]

Ladislav Lhotka  wrote:
> 
> > On 14 Jun 2017, at 13:43, Lou Berger  wrote:
> > 
> > Hi,
> > 
> > (speaking as contributor...)
> > 
> > 
> > On 6/14/2017 7:17 AM, Ladislav Lhotka wrote:
> >> Hi Xufeng,
> >> 
> >> please see my answers inline.
> >> 
> >> Xufeng Liu  writes:
> >> 
> >>> Hi Lada,
> >>> 
> >>> 
> >>> 
> >>> We have got two questions on how to specify the module entries in a
> >>> schema:
> >>> 
> >>> 
> >>> 
> >>> 1. Are augmentations of parent modules inherited when augmented module
> >>> is listed in schema-mounts schema?
> >>> 
> >>> For example, ietf-ospf module augments ietf-routing. When we include
> >>> ietf-routing to the schema entry, is ietf-ospf automatically included?
> >> No, you also have to include "ietf-ospf" in the "module" list inside
> >> the
> >> corresponding "schema" entry, exactly as you do in the top level YANG
> >> library, otherwise ietf-ospf won't be mounted.
> > 
> > I agree.  The draft should have text that makes this explicit.
> 
> Why? It should be sufficiently clear that modules that are not listed
> in "schema" are not present in the mounted schema. An augment is just
> a special mechanism of contributing schema nodes.

Yes I agree.  But let's see if we can clarify the text.  Xufeng, what
in the current text led you to believe that a module in the parent
schema would be automatically present in the mounted schema?

> >>> 2.When we have ietf-yang-library mounted under a parent (LNE), 
> >>> does
> >>> ietf-yang-library have to contain exactly the same list of Yang
> >>> modules as
> >>> the list contained in the "schema" entry under "schema-mount"?
> >> I am not sure I understand but do you mean an LNE mounted schema
> >> defined via
> >> the "use-schema" case that also includes ietf-yang-library? This is a
> >> corner case we probably haven't thought about but it IMO doesn't make
> >> any sense to do so because the applicable YANG library that counts is
> >> inside the "schema" entry. Martin, should we address this anomaly?
> > 
> > I think this is a very real scenario for LNE.  Consider a 'host'
> > system
> > that allows read only views of the LNE and wants the benefit of
> > "use-schema".  In this case, library under the mount point is still
> > needed for client access within the mounted LNE.
> 
> In this case it would IMO be much better if the server inside the LNE
> provide YANG library data separately for its clients. The client of
> the host system needn't see it because it is just redundant.
> 
> >  
> > 
> > It seems to me that in this case the mounted library module data must
> > exactly match what is listed in the corresponding "schema" entry under
> > "schema-mount" in order to ensure deterministic client views/behavior.
> > Again, I think this should be made explicit in the draft.
> 
> Another option is to ban ietf-yang-library in schemas mounted via
> "use-schema".

This won't help.  The question is still the same - if you use
"use-schema", and one of the mounted modules is "ietf-yang-library",
does the contents of the yang library in both places have to be the
same?

Anyway, I think the answer is that from the current specification, it
follows that the contents *will* be the same.


/martin



> I still think it is wrong to tout "inline" and
> "use-schema" as the same "schema mount" concept. If we clearly
> separated the two concepts, "inline" would become an absolute
> no-brainer requiring just a single YANG extension statement, and
> "use-schema" would also be easier to explain with no confusing
> exceptions and qualifications. It's just simple divide-and-conquer in
> terms of the spec, with no limitations compared to the current
> options.
> 
> Lada
> 
> > 
> >> BTW, I think that normally LNE schema is supposed to be mounted using
> >> the
> >> "inline" case, and then of course ietf-yang-library is required but
> >> there is no "schema" entry under "schema-mounts" to worry about.
> > Both inline and non-inline LNE usage is expected in real systems...
> > 
> > Lou
> >> Lada
> >> 
> >>> For example, ietf-ospf module augments ietf-routing. When we mount
> >>> ietf-routing ietf-yang-library to LNE, should we list ietf-ospf in the
> >>> mount
> >>> module list? And also in ietf-yang-library?
> >>> 
> >>> 
> >>> 
> >>> It would be great if these can be clarified.
> >>> 
> >>> 
> >>> 
> >>> Thanks,
> >>> 
> >>> - Xufeng
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
> 
> 
> 
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Clarification Question on draft-dsdt-nmda-guidelines-01

[Robert Wilton]

On 14/06/2017 16:23, Mahesh Jethanandani wrote:

On Jun 14, 2017, at 8:10 AM, Robert Wilton  wrote:

Hi Xufeng,


On 14/06/2017 14:01, Xufeng Liu wrote:

Hi Juergen,

Thanks for the confirmation.
As for the distinction between applied configuration and operational, I think 
that it has been determined to be useful in some use cases. We can create a 
separate leaf in such a case.

Yes, I think that this is exactly the right approach.

In the general case, a single leaf for applied configuration and the 
operational value is normally sufficient.

But in some cases (e.g. where a value could be configured and/or negotiated via 
protocol) then it sometimes useful to both see the input into the protocol 
negotiation and also the resultant output value.

Here, there is a choice to be made to decide whether the extra config false 
leaf represents the input value into the negotiation, or the output value.  I 
think that the decision probably depends on the protocol semantics, but all 
things being equal, there is a benefit if the configured value and actual 
operational value end up being represented by the same leaf/path (since this in 
the case in the mainline case where extra config false leaves are not required).

Another way to look at it is whether the input value is truly different from 
the output value. For example, if the input value is auto-negotiation, a 
boolean, but the output value is a speed of 10/100/1000/1, a uint32, then a 
separate leaf makes sense.

Yes, agreed.

For cases like these (e.g. Ethernet auto-negotiation) a good approach 
seem to be to model the leaf "enabling auto" as a separate leaf from the 
explicitly configured/operational value.


Thanks,
Rob





Thanks,
Rob



Regards,
- Xufeng


-Original Message-
From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de]
Sent: Tuesday, June 13, 2017 4:10 PM
To: Xufeng Liu 
Cc: draft-dsdt-nmda-guideli...@ietf.org; netmod@ietf.org
Subject: Re: Clarification Question on draft-dsdt-nmda-guidelines-01

Hi,

the typical -state tree consists of config false nodes and hence it represents
operational state. This is not a transitioning period question, this is how 
-state
trees were designed. Note also that the applied configuration is part of the
operational state in NMDA - for config true objects, there is no difference
between the applied configuration value and the operationally used value - they
are the same.

/js

On Tue, Jun 13, 2017 at 07:53:32PM +, Xufeng Liu wrote:

During discussing the adoption of this guidelines, a question came up w.r.t. the

semantics of the non-NMDA "-state" module during the transitioning period:

What kind of state do the leaves in the "-state" module represent? The applied

configuration or the actually used operational data?

Since only of the two types can be represented, what is the guideline to model

the other type?

Thanks,
- Xufeng

--
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

.


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Mahesh Jethanandani
mjethanand...@gmail.com



.



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Clarification Question on draft-dsdt-nmda-guidelines-01

[Robert Wilton]

Hi Xufeng,


On 14/06/2017 14:01, Xufeng Liu wrote:

Hi Juergen,

Thanks for the confirmation.
As for the distinction between applied configuration and operational, I think 
that it has been determined to be useful in some use cases. We can create a 
separate leaf in such a case.

Yes, I think that this is exactly the right approach.

In the general case, a single leaf for applied configuration and the 
operational value is normally sufficient.


But in some cases (e.g. where a value could be configured and/or 
negotiated via protocol) then it sometimes useful to both see the input 
into the protocol negotiation and also the resultant output value.


Here, there is a choice to be made to decide whether the extra config 
false leaf represents the input value into the negotiation, or the 
output value.  I think that the decision probably depends on the 
protocol semantics, but all things being equal, there is a benefit if 
the configured value and actual operational value end up being 
represented by the same leaf/path (since this in the case in the 
mainline case where extra config false leaves are not required).


Thanks,
Rob




Regards,
- Xufeng


-Original Message-
From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de]
Sent: Tuesday, June 13, 2017 4:10 PM
To: Xufeng Liu 
Cc: draft-dsdt-nmda-guideli...@ietf.org; netmod@ietf.org
Subject: Re: Clarification Question on draft-dsdt-nmda-guidelines-01

Hi,

the typical -state tree consists of config false nodes and hence it represents
operational state. This is not a transitioning period question, this is how 
-state
trees were designed. Note also that the applied configuration is part of the
operational state in NMDA - for config true objects, there is no difference
between the applied configuration value and the operationally used value - they
are the same.

/js

On Tue, Jun 13, 2017 at 07:53:32PM +, Xufeng Liu wrote:

During discussing the adoption of this guidelines, a question came up w.r.t. the

semantics of the non-NMDA "-state" module during the transitioning period:

What kind of state do the leaves in the "-state" module represent? The applied

configuration or the actually used operational data?

Since only of the two types can be represented, what is the guideline to model

the other type?

Thanks,
- Xufeng

--
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

.



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Question on intefaces-state model

[Vladimir Vassilev]

Hello,

On 06/14/2017 01:18 PM, Bogaert, Bart (Nokia - BE/Antwerp) wrote:

That's why these counters are optional in the model: if there is nothing to
return we should indeed not return 0...

-Original Message-
From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de]
Sent: 14 June 2017 11:40
To: Robert Wilton 
Cc: Vladimir Vassilev ; Andy Bierman
; Bogaert, Bart (Nokia - BE/Antwerp)
; netmod@ietf.org
Subject: Re: [netmod] Question on intefaces-state model

On Wed, Jun 14, 2017 at 10:15:22AM +0100, Robert Wilton wrote:

Returning zero values here is not useful, in fact it is misleading. I
think that if a server doesn't have a value to return for a particular
node it is much better to return nothing than to return a false value.

+1.

It took us years to kill this attitude in SNMP land. Saying a counter is
zero and never changes is largely misleading if you actually have no such
counter. It is easy to waste hours of expensive engineering time by given
people fake counters.

/js



I agree that the statistics counter leafs as defined in ietf-interfaces 
are optional except the discontinuity-time ("mandatory true;") leaf. You 
were right it makes the entire /interfaces-state/interface/statistics 
container mandatory even if none of the optional counters are implemented.


The context of the example was the statement by Andy who seemed to 
differ on the counters being optional. I was not sure what he ment and 
added an example of device not implementing some of the counters without 
breaking conformity with ietf-interfaces:


On 06/13/2017 11:15 AM, Vladimir Vassilev wrote:
On 06/12/2017 08:31 PM, Andy Bierman wrote: an  must 
contain an instance of the mandatory leaf.
The mandatory-stmt is very confusing for config=false nodes. 
Mandatory=true means

Mandatory=false does not mean optional-to-implement although it sure
looks that way for config=false nodes.  Only if-feature can make a 
node optional to implement.
If we take serial interface with hardware that only has in-octets and 
out-octets counters I would expect to only find these two in 
/interfaces-state/interface/statistics +  discontinuity-time. Do you 
say the rest of the counters must be present (e.g. allways 0) for 
proper implementation of ietf-interfaces? 


That said you probably also agree that a model with optional leafs is 
equivalent to an employment contract where the monthly salary is 
optional. State data models should avoid the entropy of allowing 
implementations to either implement or not leafs without this being 
formal conformance deviation (this being especially valid for basic 
counters part of the base ietf model like ietf-interfaces). That causes 
greater waste of not only engineering time but runtime traffic as well. 
Management applications have to be designed to poll the leafs and make 
conditional decisions for each instance and handle missing leafs to 
conform to the model.


For example an option to do automated validation of all point to point 
links in a topology (by checking counters at source and destination 
ports - out-unicast-pkts=in-unicast-pkts ... etc.). All the devices 
implement the required capability - ietf-interfaces but some do not 
return out-unicast-pkts, out-broadcast-pkts, out-multicast-pkts since 
the hardware only provides them with out-total-pkts and in-total-pkts 
(not part of ietf-interfaces model).



With that example in mind I have another relevant question:

Is there consensus that this is valid YANG 1.1 and with a mandatory 
counters defined like that the stated conformance actually brings some 
guarantees the required counter will be implemented:


...

yang-version 1.1;

...

   augment "/if:interfaces-state/if:interface/if:statistics" {
leaf in-total-pkts {
  mandatory true;
  type yang:counter64;
}
leaf out-total-pkts {
  mandatory true;
  type yang:counter64;
}

}

...

pyang does not like that ("cannot augment with mandatory node 
in-total-pkts") and I think it should be valid to add mandatory true 
counter leafs to /interfaces-state/interface/statistics


Vladimir

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Schema-mount question: Augmentation to the Mounted Module

[Lou Berger]

Hi Lada,


On 6/14/2017 9:22 AM, Ladislav Lhotka wrote:
>> On 14 Jun 2017, at 13:43, Lou Berger  wrote:
>>
>> Hi,
>>
>> (speaking as contributor...)
>>
>>
>> On 6/14/2017 7:17 AM, Ladislav Lhotka wrote:
>>> Hi Xufeng,
>>>
>>> please see my answers inline.
>>>
>>> Xufeng Liu  writes:
>>>
 Hi Lada,



 We have got two questions on how to specify the module entries in a schema:



 1. Are augmentations of parent modules inherited when augmented module
 is listed in schema-mounts schema?

 For example, ietf-ospf module augments ietf-routing. When we include
 ietf-routing to the schema entry, is ietf-ospf automatically included?
>>> No, you also have to include "ietf-ospf" in the "module" list inside the
>>> corresponding "schema" entry, exactly as you do in the top level YANG
>>> library, otherwise ietf-ospf won't be mounted.
>> I agree.  The draft should have text that makes this explicit.
> Why? It should be sufficiently clear that modules that are not listed in 
> "schema" are not present in the mounted schema. An augment is just a special 
> mechanism of contributing schema nodes. 

Because it it ambiguous  to one (very clueful) reader, it won't be clear
to others (who may or may not be clueful)...

>

 2. When we have ietf-yang-library mounted under a parent (LNE), does
 ietf-yang-library have to contain exactly the same list of Yang modules as
 the list contained in the "schema" entry under "schema-mount"?
>>> I am not sure I understand but do you mean an LNE mounted schema defined via
>>> the "use-schema" case that also includes ietf-yang-library? This is a
>>> corner case we probably haven't thought about but it IMO doesn't make
>>> any sense to do so because the applicable YANG library that counts is
>>> inside the "schema" entry. Martin, should we address this anomaly?
>> I think this is a very real scenario for LNE.  Consider a 'host' system
>> that allows read only views of the LNE and wants the benefit of
>> "use-schema".  In this case, library under the mount point is still
>> needed for client access within the mounted LNE.
> In this case it would IMO be much better if the server inside the LNE provide 
> YANG library data separately for its clients. The client of the host system 
> needn't see it because it is just redundant.

huh?  The intent was for the same information to be available from both
in this use case.  All that is needed is a one or two sentences to cover
this case.  Do you want me to propose text?  (Yes, we could do this in
the LNE document, but these seems like a generic, not model-specific topic.)

>>  
>>
>> It seems to me that in this case the mounted library module data must
>> exactly match what is listed in the corresponding "schema" entry under
>> "schema-mount" in order to ensure deterministic client views/behavior. 
>> Again, I think this should be made explicit in the draft.
> Another option is to ban ietf-yang-library in schemas mounted via 
> "use-schema". I still think it is wrong to tout "inline" and "use-schema" as 
> the same "schema mount" concept. If we clearly separated the two concepts, 
> "inline" would become an absolute no-brainer requiring just a single YANG 
> extension statement, and "use-schema" would also be easier to explain with no 
> confusing exceptions and qualifications. It's just simple divide-and-conquer 
> in terms of the spec, with no limitations compared to the current options.

I don't see how this helps.  The scenario being discussed doesn't have
anything to do with inline case.  This is the case of the LNE which can
support the exposure of the same information (data) via multiple YANG
servers.  One (the hosts) that sees all information and the other that
sees information from the (jailed) mount point.

Lou
>
> Lada
>
>>> BTW, I think that normally LNE schema is supposed to be mounted using the
>>> "inline" case, and then of course ietf-yang-library is required but
>>> there is no "schema" entry under "schema-mounts" to worry about.
>> Both inline and non-inline LNE usage is expected in real systems...
>>
>> Lou
>>> Lada
>>>
 For example, ietf-ospf module augments ietf-routing. When we mount
 ietf-routing ietf-yang-library to LNE, should we list ietf-ospf in the 
 mount
 module list? And also in ietf-yang-library?



 It would be great if these can be clarified.



 Thanks,

 - Xufeng
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
>
>
>
>
>
>

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Question on intefaces-state model

[Igor Bryskin]

I apologize for the email below - replied to the wrong one, please, disregard.

Igor

From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Igor Bryskin
Sent: Wednesday, June 14, 2017 9:13 AM
To: lho...@nic.cz; alex.campb...@aviatnet.com
Cc: netmod@ietf.org
Subject: Re: [netmod] Question on intefaces-state model

Hi Franchesco,

To your point 1:
I was describing a very common use case when a client owns/ controls OTN TTPs, 
while the multi domain network provides connectivity betweeb access links 
across the network. In this cae network only deals with transit segments 
(neither head nor tail)
To your point 2
There is only one thing aboutb OTN transit segments that is  OTN specific  - 
bandwidth.
Because the configuration  of a transit OTN segment needs to include the exact 
ODUk container (to match the container on the opposite side of the incoming 
access/interdomain link) - said ODUk container is expected to be encoded as a 
generic label subobject that follows  the network side access/interdomain link 
subobject  - this alone tells the network controller everything it needs to 
know about the required bandwidth.
In short, for this use case you dont need OTN augmentation
to support client -network interface  - base /generic  TE tunnel model works 
just fine,

I do agree that every use case that requires provisioning by network OTN  TTPs 
does require the OTN augmentation.

Igor
From:Ladislav Lhotka
To:Alex Campbell,
Cc:netmod@ietf.org,
Date:2017-06-14 04:28:51
Subject:Re: [netmod] Question on intefaces-state model


> On 14 Jun 2017, at 00:35, Alex Campbell  wrote:
>
>
> Presumably a device is free to not implement an optional config=false node if 
> that node would never be returned in a response anyway - as this will make no 
> externally visible difference.

That's my view, too. However, this reasoning works if the parent container is 
being retrieved but it is not very clear what is supposed to happen if the 
client asks explicly for that optional parameter. This looks like a gap in the 
architecture - most of the time, YANG pretends to be something like a schema 
language in that it describes constraints on a valid data tree but conformance 
issues like what parameters a server needs to implement are something different.

>
> However, if the model states or implies that the node is present under 
> certain conditions (for example, the node is always present for Ethernet 
> ports), and the device can meet those conditions (i.e. it has an Ethernet 
> port), then the device must implement the node or it does not conform to the 
> model.

Right, this could be written in a description, but I've been assuming it is not 
the case.

Lada

>
>
>
> Alex
>
> From: netmod  on behalf of Andy Bierman 
> 
> Sent: Wednesday, 14 June 2017 7:30 a.m.
> To: Ladislav Lhotka
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Question on intefaces-state model
>
>
> On Tue, Jun 13, 2017 at 11:52 AM, Ladislav Lhotka  wrote:
> Andy Bierman  writes:
>
> > On Mon, Jun 12, 2017 at 10:21 AM, Juergen Schoenwaelder <
> > j.schoenwael...@jacobs-university.de> wrote:
> >
> >> On Fri, Jun 09, 2017 at 10:55:20AM +, Bogaert, Bart (Nokia -
> >> BE/Antwerp) wrote:
> >> >
> >> > We have a question regarding the statistics container as defined in the
> >> > interfaces-state model.  This container defines one mandatory leaf
> >> > (discontinuity-time) while all other leafs are optional.  What is the
> >> > rationale behind this leaf being mandatory and not an optional field?
> >> >
> >> > It does not make a lot of sense to return a discontinuity-time value and
> >> no
> >> > counters if none of the counters are relevant for a specific interface.
> >> >
> >> > Another alternative could be to add, via a deviation, a when clause to
> >> the
> >> > container indicating for which ifType(s) the container is (or is not)
> >> > present. But that would lead to not supporting the IETF interfaces model
> >> to
> >> > the full extent.
> >> >
> >>
> >> The discontinuity-time is relevant for _any_ counter associated with
> >> an interface, regardless whether the counter is defined in the
> >> interfaces model or elsewhere. I have a hard time to imagine an
> >> interface that has zero counters.
> >>
> >>
> > The mandatory-stmt is very confusing for config=false nodes. Mandatory=true
> > means
> > an  must contain an instance of the mandatory leaf.
>
> I don't think it is that confusing. RFC 7950 defines what a valid data
> tree means and "mandatory" are among the constraints.
>
> I agree though that in terms of a management protocol it means different
> things for config true and false data, but this is true also for default
> values and maybe other YANG concepts as well.
>
> >
> > Mandatory=false does not mean optional-to-implement although it sure
> > looks that way for config=false nodes.  Only if-feature can make a node
> > optional to 

Re: [netmod] Schema-mount question: Augmentation to the Mounted Module

[Ladislav Lhotka]

> On 14 Jun 2017, at 13:43, Lou Berger  wrote:
> 
> Hi,
> 
> (speaking as contributor...)
> 
> 
> On 6/14/2017 7:17 AM, Ladislav Lhotka wrote:
>> Hi Xufeng,
>> 
>> please see my answers inline.
>> 
>> Xufeng Liu  writes:
>> 
>>> Hi Lada,
>>> 
>>> 
>>> 
>>> We have got two questions on how to specify the module entries in a schema:
>>> 
>>> 
>>> 
>>> 1.  Are augmentations of parent modules inherited when augmented module
>>> is listed in schema-mounts schema?
>>> 
>>> For example, ietf-ospf module augments ietf-routing. When we include
>>> ietf-routing to the schema entry, is ietf-ospf automatically included?
>> No, you also have to include "ietf-ospf" in the "module" list inside the
>> corresponding "schema" entry, exactly as you do in the top level YANG
>> library, otherwise ietf-ospf won't be mounted.
> 
> I agree.  The draft should have text that makes this explicit.

Why? It should be sufficiently clear that modules that are not listed in 
"schema" are not present in the mounted schema. An augment is just a special 
mechanism of contributing schema nodes. 

> 
>>> 
>>> 
>>> 2.  When we have ietf-yang-library mounted under a parent (LNE), does
>>> ietf-yang-library have to contain exactly the same list of Yang modules as
>>> the list contained in the "schema" entry under "schema-mount"?
>> I am not sure I understand but do you mean an LNE mounted schema defined via
>> the "use-schema" case that also includes ietf-yang-library? This is a
>> corner case we probably haven't thought about but it IMO doesn't make
>> any sense to do so because the applicable YANG library that counts is
>> inside the "schema" entry. Martin, should we address this anomaly?
> 
> I think this is a very real scenario for LNE.  Consider a 'host' system
> that allows read only views of the LNE and wants the benefit of
> "use-schema".  In this case, library under the mount point is still
> needed for client access within the mounted LNE.

In this case it would IMO be much better if the server inside the LNE provide 
YANG library data separately for its clients. The client of the host system 
needn't see it because it is just redundant.

>  
> 
> It seems to me that in this case the mounted library module data must
> exactly match what is listed in the corresponding "schema" entry under
> "schema-mount" in order to ensure deterministic client views/behavior. 
> Again, I think this should be made explicit in the draft.

Another option is to ban ietf-yang-library in schemas mounted via "use-schema". 
I still think it is wrong to tout "inline" and "use-schema" as the same "schema 
mount" concept. If we clearly separated the two concepts, "inline" would become 
an absolute no-brainer requiring just a single YANG extension statement, and 
"use-schema" would also be easier to explain with no confusing exceptions and 
qualifications. It's just simple divide-and-conquer in terms of the spec, with 
no limitations compared to the current options.

Lada

> 
>> BTW, I think that normally LNE schema is supposed to be mounted using the
>> "inline" case, and then of course ietf-yang-library is required but
>> there is no "schema" entry under "schema-mounts" to worry about.
> Both inline and non-inline LNE usage is expected in real systems...
> 
> Lou
>> Lada
>> 
>>> For example, ietf-ospf module augments ietf-routing. When we mount
>>> ietf-routing ietf-yang-library to LNE, should we list ietf-ospf in the mount
>>> module list? And also in ietf-yang-library?
>>> 
>>> 
>>> 
>>> It would be great if these can be clarified.
>>> 
>>> 
>>> 
>>> Thanks,
>>> 
>>> - Xufeng

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67





___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Question on intefaces-state model

[Igor Bryskin]

Hi Franchesco,

To your point 1:
I was describing a very common use case when a client owns/ controls OTN TTPs, 
while the multi domain network provides connectivity betweeb access links 
across the network. In this cae network only deals with transit segments 
(neither head nor tail)
To your point 2
There is only one thing aboutb OTN transit segments that is  OTN specific  - 
bandwidth.
Because the configuration  of a transit OTN segment needs to include the exact 
ODUk container (to match the container on the opposite side of the incoming 
access/interdomain link) - said ODUk container is expected to be encoded as a 
generic label subobject that follows  the network side access/interdomain link 
subobject  - this alone tells the network controller everything it needs to 
know about the required bandwidth.
In short, for this use case you dont need OTN augmentation
to support client -network interface  - base /generic  TE tunnel model works 
just fine,

I do agree that every use case that requires provisioning by network OTN  TTPs 
does require the OTN augmentation.

Igor

From:Ladislav Lhotka
To:Alex Campbell,
Cc:netmod@ietf.org,
Date:2017-06-14 04:28:51
Subject:Re: [netmod] Question on intefaces-state model


> On 14 Jun 2017, at 00:35, Alex Campbell  wrote:
>
>
> Presumably a device is free to not implement an optional config=false node if 
> that node would never be returned in a response anyway - as this will make no 
> externally visible difference.

That's my view, too. However, this reasoning works if the parent container is 
being retrieved but it is not very clear what is supposed to happen if the 
client asks explicly for that optional parameter. This looks like a gap in the 
architecture – most of the time, YANG pretends to be something like a schema 
language in that it describes constraints on a valid data tree but conformance 
issues like what parameters a server needs to implement are something different.

>
> However, if the model states or implies that the node is present under 
> certain conditions (for example, the node is always present for Ethernet 
> ports), and the device can meet those conditions (i.e. it has an Ethernet 
> port), then the device must implement the node or it does not conform to the 
> model.

Right, this could be written in a description, but I've been assuming it is not 
the case.

Lada

>
>
>
> Alex
>
> From: netmod  on behalf of Andy Bierman 
> 
> Sent: Wednesday, 14 June 2017 7:30 a.m.
> To: Ladislav Lhotka
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Question on intefaces-state model
>
>
> On Tue, Jun 13, 2017 at 11:52 AM, Ladislav Lhotka  wrote:
> Andy Bierman  writes:
>
> > On Mon, Jun 12, 2017 at 10:21 AM, Juergen Schoenwaelder <
> > j.schoenwael...@jacobs-university.de> wrote:
> >
> >> On Fri, Jun 09, 2017 at 10:55:20AM +, Bogaert, Bart (Nokia -
> >> BE/Antwerp) wrote:
> >> >
> >> > We have a question regarding the statistics container as defined in the
> >> > interfaces-state model.  This container defines one mandatory leaf
> >> > (discontinuity-time) while all other leafs are optional.  What is the
> >> > rationale behind this leaf being mandatory and not an optional field?
> >> >
> >> > It does not make a lot of sense to return a discontinuity-time value and
> >> no
> >> > counters if none of the counters are relevant for a specific interface.
> >> >
> >> > Another alternative could be to add, via a deviation, a when clause to
> >> the
> >> > container indicating for which ifType(s) the container is (or is not)
> >> > present. But that would lead to not supporting the IETF interfaces model
> >> to
> >> > the full extent.
> >> >
> >>
> >> The discontinuity-time is relevant for _any_ counter associated with
> >> an interface, regardless whether the counter is defined in the
> >> interfaces model or elsewhere. I have a hard time to imagine an
> >> interface that has zero counters.
> >>
> >>
> > The mandatory-stmt is very confusing for config=false nodes. Mandatory=true
> > means
> > an  must contain an instance of the mandatory leaf.
>
> I don't think it is that confusing. RFC 7950 defines what a valid data
> tree means and "mandatory" are among the constraints.
>
> I agree though that in terms of a management protocol it means different
> things for config true and false data, but this is true also for default
> values and maybe other YANG concepts as well.
>
> >
> > Mandatory=false does not mean optional-to-implement although it sure
> > looks that way for config=false nodes.  Only if-feature can make a node
> > optional to implement.
>
> I don't think this interpretation is supported by any text in the YANG
> spec. State data nodes that are optional needn't be implemented.
>
>
> RFC 7950, sec 5.6  (Conformance) does not support your interpretation.
> It defines basic behavior, optional (via features), and deviations as the 
> only 

Re: [netmod] Clarification Question on draft-dsdt-nmda-guidelines-01

[Xufeng Liu]

Hi Juergen,

Thanks for the confirmation.
As for the distinction between applied configuration and operational, I think 
that it has been determined to be useful in some use cases. We can create a 
separate leaf in such a case.

Regards,
- Xufeng

> -Original Message-
> From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de]
> Sent: Tuesday, June 13, 2017 4:10 PM
> To: Xufeng Liu 
> Cc: draft-dsdt-nmda-guideli...@ietf.org; netmod@ietf.org
> Subject: Re: Clarification Question on draft-dsdt-nmda-guidelines-01
> 
> Hi,
> 
> the typical -state tree consists of config false nodes and hence it represents
> operational state. This is not a transitioning period question, this is how 
> -state
> trees were designed. Note also that the applied configuration is part of the
> operational state in NMDA - for config true objects, there is no difference
> between the applied configuration value and the operationally used value - 
> they
> are the same.
> 
> /js
> 
> On Tue, Jun 13, 2017 at 07:53:32PM +, Xufeng Liu wrote:
> > During discussing the adoption of this guidelines, a question came up 
> > w.r.t. the
> semantics of the non-NMDA "-state" module during the transitioning period:
> >
> > What kind of state do the leaves in the "-state" module represent? The 
> > applied
> configuration or the actually used operational data?
> > Since only of the two types can be represented, what is the guideline to 
> > model
> the other type?
> >
> > Thanks,
> > - Xufeng
> 
> --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Schema-mount question: Augmentation to the Mounted Module

[Lou Berger]

Hi,

(speaking as contributor...)


On 6/14/2017 7:17 AM, Ladislav Lhotka wrote:
> Hi Xufeng,
>
> please see my answers inline.
>
> Xufeng Liu  writes:
>
>> Hi Lada,
>>
>>  
>>
>> We have got two questions on how to specify the module entries in a schema:
>>
>>  
>>
>> 1.   Are augmentations of parent modules inherited when augmented module
>> is listed in schema-mounts schema?
>>
>> For example, ietf-ospf module augments ietf-routing. When we include
>> ietf-routing to the schema entry, is ietf-ospf automatically included?
> No, you also have to include "ietf-ospf" in the "module" list inside the
> corresponding "schema" entry, exactly as you do in the top level YANG
> library, otherwise ietf-ospf won't be mounted.

I agree.  The draft should have text that makes this explicit.

>>  
>>
>> 2.   When we have ietf-yang-library mounted under a parent (LNE), does
>> ietf-yang-library have to contain exactly the same list of Yang modules as
>> the list contained in the "schema" entry under "schema-mount"?
> I am not sure I understand but do you mean an LNE mounted schema defined via
> the "use-schema" case that also includes ietf-yang-library? This is a
> corner case we probably haven't thought about but it IMO doesn't make
> any sense to do so because the applicable YANG library that counts is
> inside the "schema" entry. Martin, should we address this anomaly?

I think this is a very real scenario for LNE.  Consider a 'host' system
that allows read only views of the LNE and wants the benefit of
"use-schema".  In this case, library under the mount point is still
needed for client access within the mounted LNE. 

It seems to me that in this case the mounted library module data must
exactly match what is listed in the corresponding "schema" entry under
"schema-mount" in order to ensure deterministic client views/behavior. 
Again, I think this should be made explicit in the draft.

> BTW, I think that normally LNE schema is supposed to be mounted using the
> "inline" case, and then of course ietf-yang-library is required but
> there is no "schema" entry under "schema-mounts" to worry about.
Both inline and non-inline LNE usage is expected in real systems...

Lou
> Lada
>
>> For example, ietf-ospf module augments ietf-routing. When we mount
>> ietf-routing ietf-yang-library to LNE, should we list ietf-ospf in the mount
>> module list? And also in ietf-yang-library?
>>
>>  
>>
>> It would be great if these can be clarified.
>>
>>  
>>
>> Thanks,
>>
>> - Xufeng
>>
>>  
>>

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Question on intefaces-state model

[Bogaert, Bart (Nokia - BE/Antwerp)]

That's why these counters are optional in the model: if there is nothing to
return we should indeed not return 0...

-Original Message-
From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de] 
Sent: 14 June 2017 11:40
To: Robert Wilton 
Cc: Vladimir Vassilev ; Andy Bierman
; Bogaert, Bart (Nokia - BE/Antwerp)
; netmod@ietf.org
Subject: Re: [netmod] Question on intefaces-state model

On Wed, Jun 14, 2017 at 10:15:22AM +0100, Robert Wilton wrote:
> 
> Returning zero values here is not useful, in fact it is misleading. I 
> think that if a server doesn't have a value to return for a particular 
> node it is much better to return nothing than to return a false value.

+1.

It took us years to kill this attitude in SNMP land. Saying a counter is
zero and never changes is largely misleading if you actually have no such
counter. It is easy to waste hours of expensive engineering time by given
people fake counters.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Schema-mount question: Augmentation to the Mounted Module

[Ladislav Lhotka]

Hi Xufeng,

please see my answers inline.

Xufeng Liu  writes:

> Hi Lada,
>
>  
>
> We have got two questions on how to specify the module entries in a schema:
>
>  
>
> 1.Are augmentations of parent modules inherited when augmented module
> is listed in schema-mounts schema?
>
> For example, ietf-ospf module augments ietf-routing. When we include
> ietf-routing to the schema entry, is ietf-ospf automatically included?

No, you also have to include "ietf-ospf" in the "module" list inside the
corresponding "schema" entry, exactly as you do in the top level YANG
library, otherwise ietf-ospf won't be mounted.

>
>  
>
> 2.When we have ietf-yang-library mounted under a parent (LNE), does
> ietf-yang-library have to contain exactly the same list of Yang modules as
> the list contained in the "schema" entry under "schema-mount"?

I am not sure I understand but do you mean an LNE mounted schema defined via
the "use-schema" case that also includes ietf-yang-library? This is a
corner case we probably haven't thought about but it IMO doesn't make
any sense to do so because the applicable YANG library that counts is
inside the "schema" entry. Martin, should we address this anomaly?

BTW, I think that normally LNE schema is supposed to be mounted using the
"inline" case, and then of course ietf-yang-library is required but
there is no "schema" entry under "schema-mounts" to worry about.

Lada

>
> For example, ietf-ospf module augments ietf-routing. When we mount
> ietf-routing ietf-yang-library to LNE, should we list ietf-ospf in the mount
> module list? And also in ietf-yang-library?
>
>  
>
> It would be great if these can be clarified.
>
>  
>
> Thanks,
>
> - Xufeng
>
>  
>

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Question on intefaces-state model

[Robert Wilton]

On 14/06/2017 10:46, Ladislav Lhotka wrote:

On 14 Jun 2017, at 11:21, Robert Wilton  wrote:



On 14/06/2017 09:28, Ladislav Lhotka wrote:

On 14 Jun 2017, at 00:35, Alex Campbell  wrote:


Presumably a device is free to not implement an optional config=false node if 
that node would never be returned in a response anyway - as this will make no 
externally visible difference.

That's my view, too. However, this reasoning works if the parent container is 
being retrieved but it is not very clear what is supposed to happen if the 
client asks explicly for that optional parameter. This looks like a gap in the 
architecture – most of the time, YANG pretends to be something like a schema 
language in that it describes constraints on a valid data tree but conformance 
issues like what parameters a server needs to implement are something different.

It would surely do the same thing as if a client requested any node in a YANG 
data tree that doesn't exist.

So you are saying that one server can return the parameter but another may report 
"404 Not Found", correct?

Yes.




RESTCONF has special semantics if a GET request is for a specific leaf rather than a 
parent container, but I just regard this as a mistake in the specification (i.e. the 
"restconf default handling" thread on the NETCONF alias).

Defaults are another can of worms. If we have an optional config false 
parameter with a default defined in YANG and the server doesn't implement the 
parameter (and hence doesn't send it), can the client assume that the server 
actually has the default value?
Not in any way that is reliable.  I.e. sometimes the client may make 
this assumption and just be wrong!


One of the key themes running through the NMDA work has been to try and 
get more integrity and consistence between the data that is being returned.


So, in the NMDA world, I think that there are really only two 
"with-default" options that are robust and most useful:


(1) For the candidate/running/status datastores, where the content of 
the datastore is controlled by the client, then the explicit mode is the 
sane default choice.  I.e. generally you should get out exactly what you 
put in.


(2) For the operational state datastore, the report-all mode is the sane 
choice, because this is the only one that allows a client to detect that 
a server is choosing to return no value rather than the default value.


I do appreciate that the other with-defaults options can be used to 
either minimize the amount of data being transferred (potentially at the 
expense of data accuracy), or provide a consolidated view of the 
configuration (e.g. to avoid the client constructing the same combined 
view itself).  But I think that the client should have to opt in if they 
want to see these, and the normal behaviour should be to favour 
correctness and explicitness.


Hence, I wish there had been more consistency with the normal choice of 
default mode in the standard rather that leaving it up to the server 
implementation to decide, thus requiring that clients have to cope with 
a mismash of default handling flavours.


Rob



Lada




However, if the model states or implies that the node is present under certain 
conditions (for example, the node is always present for Ethernet ports), and 
the device can meet those conditions (i.e. it has an Ethernet port), then the 
device must implement the node or it does not conform to the model.

Right, this could be written in a description, but I've been assuming it is not 
the case.

Lada

Rob



Alex

From: netmod  on behalf of Andy Bierman 

Sent: Wednesday, 14 June 2017 7:30 a.m.
To: Ladislav Lhotka
Cc: netmod@ietf.org
Subject: Re: [netmod] Question on intefaces-state model


On Tue, Jun 13, 2017 at 11:52 AM, Ladislav Lhotka  wrote:
Andy Bierman  writes:


On Mon, Jun 12, 2017 at 10:21 AM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:


On Fri, Jun 09, 2017 at 10:55:20AM +, Bogaert, Bart (Nokia -
BE/Antwerp) wrote:

We have a question regarding the statistics container as defined in the
interfaces-state model.  This container defines one mandatory leaf
(discontinuity-time) while all other leafs are optional.  What is the
rationale behind this leaf being mandatory and not an optional field?

It does not make a lot of sense to return a discontinuity-time value and

no

counters if none of the counters are relevant for a specific interface.

Another alternative could be to add, via a deviation, a when clause to

the

container indicating for which ifType(s) the container is (or is not)
present. But that would lead to not supporting the IETF interfaces model

to

the full extent.


The discontinuity-time is relevant for _any_ counter associated with
an interface, regardless whether the counter is defined in the
interfaces model or elsewhere. I have a hard time to imagine 

Re: [netmod] Question on intefaces-state model

[Ladislav Lhotka]

> On 14 Jun 2017, at 11:21, Robert Wilton  wrote:
> 
> 
> 
> On 14/06/2017 09:28, Ladislav Lhotka wrote:
>>> On 14 Jun 2017, at 00:35, Alex Campbell  wrote:
>>> 
>>> 
>>> Presumably a device is free to not implement an optional config=false node 
>>> if that node would never be returned in a response anyway - as this will 
>>> make no externally visible difference.
>> That's my view, too. However, this reasoning works if the parent container 
>> is being retrieved but it is not very clear what is supposed to happen if 
>> the client asks explicly for that optional parameter. This looks like a gap 
>> in the architecture – most of the time, YANG pretends to be something like a 
>> schema language in that it describes constraints on a valid data tree but 
>> conformance issues like what parameters a server needs to implement are 
>> something different.
> It would surely do the same thing as if a client requested any node in a YANG 
> data tree that doesn't exist.

So you are saying that one server can return the parameter but another may 
report "404 Not Found", correct?

> 
> RESTCONF has special semantics if a GET request is for a specific leaf rather 
> than a parent container, but I just regard this as a mistake in the 
> specification (i.e. the "restconf default handling" thread on the NETCONF 
> alias).

Defaults are another can of worms. If we have an optional config false 
parameter with a default defined in YANG and the server doesn't implement the 
parameter (and hence doesn't send it), can the client assume that the server 
actually has the default value?

Lada

> 
> 
>> 
>>> However, if the model states or implies that the node is present under 
>>> certain conditions (for example, the node is always present for Ethernet 
>>> ports), and the device can meet those conditions (i.e. it has an Ethernet 
>>> port), then the device must implement the node or it does not conform to 
>>> the model.
>> Right, this could be written in a description, but I've been assuming it is 
>> not the case.
>> 
>> Lada
> Rob
> 
>> 
>>> 
>>> 
>>> Alex
>>> 
>>> From: netmod  on behalf of Andy Bierman 
>>> 
>>> Sent: Wednesday, 14 June 2017 7:30 a.m.
>>> To: Ladislav Lhotka
>>> Cc: netmod@ietf.org
>>> Subject: Re: [netmod] Question on intefaces-state model
>>> 
>>> 
>>> On Tue, Jun 13, 2017 at 11:52 AM, Ladislav Lhotka  wrote:
>>> Andy Bierman  writes:
>>> 
 On Mon, Jun 12, 2017 at 10:21 AM, Juergen Schoenwaelder <
 j.schoenwael...@jacobs-university.de> wrote:
 
> On Fri, Jun 09, 2017 at 10:55:20AM +, Bogaert, Bart (Nokia -
> BE/Antwerp) wrote:
>> We have a question regarding the statistics container as defined in the
>> interfaces-state model.  This container defines one mandatory leaf
>> (discontinuity-time) while all other leafs are optional.  What is the
>> rationale behind this leaf being mandatory and not an optional field?
>> 
>> It does not make a lot of sense to return a discontinuity-time value and
> no
>> counters if none of the counters are relevant for a specific interface.
>> 
>> Another alternative could be to add, via a deviation, a when clause to
> the
>> container indicating for which ifType(s) the container is (or is not)
>> present. But that would lead to not supporting the IETF interfaces model
> to
>> the full extent.
>> 
> The discontinuity-time is relevant for _any_ counter associated with
> an interface, regardless whether the counter is defined in the
> interfaces model or elsewhere. I have a hard time to imagine an
> interface that has zero counters.
> 
> 
 The mandatory-stmt is very confusing for config=false nodes. Mandatory=true
 means
 an  must contain an instance of the mandatory leaf.
>>> I don't think it is that confusing. RFC 7950 defines what a valid data
>>> tree means and "mandatory" are among the constraints.
>>> 
>>> I agree though that in terms of a management protocol it means different
>>> things for config true and false data, but this is true also for default
>>> values and maybe other YANG concepts as well.
>>> 
 Mandatory=false does not mean optional-to-implement although it sure
 looks that way for config=false nodes.  Only if-feature can make a node
 optional to implement.
>>> I don't think this interpretation is supported by any text in the YANG
>>> spec. State data nodes that are optional needn't be implemented.
>>> 
>>> 
>>> RFC 7950, sec 5.6  (Conformance) does not support your interpretation.
>>> It defines basic behavior, optional (via features), and deviations as the 
>>> only mechanisms affecting conformance.
>>> 
>>> 
>>> Lada
>>> 
>>> 
>>> Andy
>>>  
 
  /js
 
 
 Andy
 
 --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 

Re: [netmod] Question on intefaces-state model

[Juergen Schoenwaelder]

On Wed, Jun 14, 2017 at 10:15:22AM +0100, Robert Wilton wrote:
> 
> Returning zero values here is not useful, in fact it is misleading. I think
> that if a server doesn't have a value to return for a particular node it is
> much better to return nothing than to return a false value.

+1.

It took us years to kill this attitude in SNMP land. Saying a counter
is zero and never changes is largely misleading if you actually have
no such counter. It is easy to waste hours of expensive engineering
time by given people fake counters.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Question on intefaces-state model

[Robert Wilton]

On 14/06/2017 09:28, Ladislav Lhotka wrote:

On 14 Jun 2017, at 00:35, Alex Campbell  wrote:


Presumably a device is free to not implement an optional config=false node if 
that node would never be returned in a response anyway - as this will make no 
externally visible difference.

That's my view, too. However, this reasoning works if the parent container is 
being retrieved but it is not very clear what is supposed to happen if the 
client asks explicly for that optional parameter. This looks like a gap in the 
architecture – most of the time, YANG pretends to be something like a schema 
language in that it describes constraints on a valid data tree but conformance 
issues like what parameters a server needs to implement are something different.
It would surely do the same thing as if a client requested any node in a 
YANG data tree that doesn't exist.


RESTCONF has special semantics if a GET request is for a specific leaf 
rather than a parent container, but I just regard this as a mistake in 
the specification (i.e. the "restconf default handling" thread on the 
NETCONF alias).






However, if the model states or implies that the node is present under certain 
conditions (for example, the node is always present for Ethernet ports), and 
the device can meet those conditions (i.e. it has an Ethernet port), then the 
device must implement the node or it does not conform to the model.

Right, this could be written in a description, but I've been assuming it is not 
the case.

Lada

Rob






Alex

From: netmod  on behalf of Andy Bierman 

Sent: Wednesday, 14 June 2017 7:30 a.m.
To: Ladislav Lhotka
Cc: netmod@ietf.org
Subject: Re: [netmod] Question on intefaces-state model


On Tue, Jun 13, 2017 at 11:52 AM, Ladislav Lhotka  wrote:
Andy Bierman  writes:


On Mon, Jun 12, 2017 at 10:21 AM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:


On Fri, Jun 09, 2017 at 10:55:20AM +, Bogaert, Bart (Nokia -
BE/Antwerp) wrote:

We have a question regarding the statistics container as defined in the
interfaces-state model.  This container defines one mandatory leaf
(discontinuity-time) while all other leafs are optional.  What is the
rationale behind this leaf being mandatory and not an optional field?

It does not make a lot of sense to return a discontinuity-time value and

no

counters if none of the counters are relevant for a specific interface.

Another alternative could be to add, via a deviation, a when clause to

the

container indicating for which ifType(s) the container is (or is not)
present. But that would lead to not supporting the IETF interfaces model

to

the full extent.


The discontinuity-time is relevant for _any_ counter associated with
an interface, regardless whether the counter is defined in the
interfaces model or elsewhere. I have a hard time to imagine an
interface that has zero counters.



The mandatory-stmt is very confusing for config=false nodes. Mandatory=true
means
an  must contain an instance of the mandatory leaf.

I don't think it is that confusing. RFC 7950 defines what a valid data
tree means and "mandatory" are among the constraints.

I agree though that in terms of a management protocol it means different
things for config true and false data, but this is true also for default
values and maybe other YANG concepts as well.


Mandatory=false does not mean optional-to-implement although it sure
looks that way for config=false nodes.  Only if-feature can make a node
optional to implement.

I don't think this interpretation is supported by any text in the YANG
spec. State data nodes that are optional needn't be implemented.


RFC 7950, sec 5.6  (Conformance) does not support your interpretation.
It defines basic behavior, optional (via features), and deviations as the only 
mechanisms affecting conformance.


Lada


Andy
  


  /js


Andy

--

Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67



--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67





___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Question on intefaces-state model

[Robert Wilton]

On 13/06/2017 10:15, Vladimir Vassilev wrote:

On 06/12/2017 08:31 PM, Andy Bierman wrote:




On Mon, Jun 12, 2017 at 10:21 AM, Juergen Schoenwaelder 
> wrote:


On Fri, Jun 09, 2017 at 10:55:20AM +, Bogaert, Bart (Nokia -
BE/Antwerp) wrote:
>
> We have a question regarding the statistics container as defined
in the
> interfaces-state model.  This container defines one mandatory leaf
> (discontinuity-time) while all other leafs are optional.  What
is the
> rationale behind this leaf being mandatory and not an optional
field?
>
> It does not make a lot of sense to return a discontinuity-time
value and no
> counters if none of the counters are relevant for a specific
interface.
>
> Another alternative could be to add, via a deviation, a when
clause to the
> container indicating for which ifType(s) the container is (or is
not)
> present. But that would lead to not supporting the IETF
interfaces model to
> the full extent.
>

The alternative which we use is to not have 
/interfaces-state/interface/statistics container for the interfaces 
without counters. The container is mandatory=false.



The discontinuity-time is relevant for _any_ counter associated with
an interface, regardless whether the counter is defined in the
interfaces model or elsewhere. I have a hard time to imagine an
interface that has zero counters.

+1



There are some though. Optical amplifiers and similar equipment that 
does not have counters - the status data is only signal levels.
For me the question is here is whether the objects being modelled by 
optical amplifiers are actually interfaces or something else, and I 
think that they are probably something else.


I appreciate that this may not be the universal view, but I think of an 
interface as something that forwards traffic at layer 2 or above.  I.e. 
it is something that is potentially meaningful to have a IP address on, 
assign a routing protocol to, have frame or packet statistics, etc.


I would rather IETF defines a separate list of objects (e.g. Cisco's IOS 
XR would call them 'controllers') for L1 forwarding objects, given that 
most of the configuration and properties of these L1 forwarding 
constructs is generally quite different from 'regular' interfaces.





The mandatory-stmt is very confusing for config=false nodes. 
Mandatory=true means

an  must contain an instance of the mandatory leaf.

Mandatory=false does not mean optional-to-implement although it sure
looks that way for config=false nodes.  Only if-feature can make a 
node optional to implement.
If we take serial interface with hardware that only has in-octets and 
out-octets counters I would expect to only find these two in 
/interfaces-state/interface/statistics +  discontinuity-time. Do you 
say the rest of the counters must be present (e.g. allways 0) for 
proper implementation of ietf-interfaces?


Returning zero values here is not useful, in fact it is misleading. I 
think that if a server doesn't have a value to return for a particular 
node it is much better to return nothing than to return a false value.


As an aside, I think that this is also why default values for config 
false leaves aren't helpful because they can cause ambiguity as to 
whether a server has no value to return, or is instead returning the 
default value.


Rob





Vladimir




/js


Andy

--
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | 
Germany

Fax:   +49 421 200 3103 >

___
netmod mailing list
netmod@ietf.org 
https://www.ietf.org/mailman/listinfo/netmod





___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
.



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Question on intefaces-state model

[Ladislav Lhotka]

> On 14 Jun 2017, at 00:35, Alex Campbell  wrote:
> 
> 
> Presumably a device is free to not implement an optional config=false node if 
> that node would never be returned in a response anyway - as this will make no 
> externally visible difference.

That's my view, too. However, this reasoning works if the parent container is 
being retrieved but it is not very clear what is supposed to happen if the 
client asks explicly for that optional parameter. This looks like a gap in the 
architecture – most of the time, YANG pretends to be something like a schema 
language in that it describes constraints on a valid data tree but conformance 
issues like what parameters a server needs to implement are something different.

> 
> However, if the model states or implies that the node is present under 
> certain conditions (for example, the node is always present for Ethernet 
> ports), and the device can meet those conditions (i.e. it has an Ethernet 
> port), then the device must implement the node or it does not conform to the 
> model.

Right, this could be written in a description, but I've been assuming it is not 
the case.

Lada

> 
> 
> 
> Alex
> 
> From: netmod  on behalf of Andy Bierman 
> 
> Sent: Wednesday, 14 June 2017 7:30 a.m.
> To: Ladislav Lhotka
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Question on intefaces-state model
> 
> 
> On Tue, Jun 13, 2017 at 11:52 AM, Ladislav Lhotka  wrote:
> Andy Bierman  writes:
> 
> > On Mon, Jun 12, 2017 at 10:21 AM, Juergen Schoenwaelder <
> > j.schoenwael...@jacobs-university.de> wrote:
> >
> >> On Fri, Jun 09, 2017 at 10:55:20AM +, Bogaert, Bart (Nokia -
> >> BE/Antwerp) wrote:
> >> >
> >> > We have a question regarding the statistics container as defined in the
> >> > interfaces-state model.  This container defines one mandatory leaf
> >> > (discontinuity-time) while all other leafs are optional.  What is the
> >> > rationale behind this leaf being mandatory and not an optional field?
> >> >
> >> > It does not make a lot of sense to return a discontinuity-time value and
> >> no
> >> > counters if none of the counters are relevant for a specific interface.
> >> >
> >> > Another alternative could be to add, via a deviation, a when clause to
> >> the
> >> > container indicating for which ifType(s) the container is (or is not)
> >> > present. But that would lead to not supporting the IETF interfaces model
> >> to
> >> > the full extent.
> >> >
> >>
> >> The discontinuity-time is relevant for _any_ counter associated with
> >> an interface, regardless whether the counter is defined in the
> >> interfaces model or elsewhere. I have a hard time to imagine an
> >> interface that has zero counters.
> >>
> >>
> > The mandatory-stmt is very confusing for config=false nodes. Mandatory=true
> > means
> > an  must contain an instance of the mandatory leaf.
> 
> I don't think it is that confusing. RFC 7950 defines what a valid data
> tree means and "mandatory" are among the constraints.
> 
> I agree though that in terms of a management protocol it means different
> things for config true and false data, but this is true also for default
> values and maybe other YANG concepts as well.
> 
> >
> > Mandatory=false does not mean optional-to-implement although it sure
> > looks that way for config=false nodes.  Only if-feature can make a node
> > optional to implement.
> 
> I don't think this interpretation is supported by any text in the YANG
> spec. State data nodes that are optional needn't be implemented.
> 
> 
> RFC 7950, sec 5.6  (Conformance) does not support your interpretation.
> It defines basic behavior, optional (via features), and deviations as the 
> only mechanisms affecting conformance.
> 
> 
> Lada
> 
> >
> 
> 
> Andy
>  
> >
> >
> >  /js
> >
> >
> > Andy
> >
> > --
> >> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> >> Fax:   +49 421 200 3103 
> >>
> >> ___
> >> netmod mailing list
> >> netmod@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netmod
> >>
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
> 

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67





___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod