Subject: [netmod] AD review: draft-ietf-netmod-revised-datastores-08

From: Benoit Claise <[email-masked]>
Date: Wed, 20 Dec 2017 17:40:30 +0100

Dear all,

In order not to be the bottleneck in the process and assuming that the 
document will be in "publication requested" pretty soon, here is my AD 
review of draft-ietf-netmod-revised-datastores-08

-

        5.3.2. Missing Resources

    Configuration in <intended> can refer to resources that are not
    available or otherwise not physically present.  In these situations,
    these parts of <intended> are not applied.  The data appears in
    <intended> but does not appear in <operational>.

I understand what you want to say.
Let me take an example. I have a router with a Line Card configured and 
working well. if I remove the LC, the configuration should still be in 
the <running> and <intended> but not in <operational>.
However, based on figure below, the notion of "inactive" nodes might be 
misleading. Indeed, people might read that the LC is inactive, so the LC 
configuration should not be in <intended>

      +-------------+                 +-----------+
      | <candidate> |                 | <startup> |
      |  (ct, rw)   |<---+       +--->| (ct, rw)  |
      +-------------+    |       |    +-----------+
             |           |       |           |
             |         +-----------+         |
             +-------->| <running> |<--------+
                       | (ct, rw)  |
                       +-----------+
                             |
                             |        // configuration transformations,
                             |        // e.g., removal of "inactive"
                             |        // nodes, expansion of templates
                             v
                       +------------+
                       | <intended> | // subject to validation
                       | (ct, ro)   |
                       +------------+

I understand that "inactive nodes" has a different meaning.

Proposal:
OLD: removal of "inactive" nodes
NEW: removal of the nodes marked as "inactive"

- In the C.1 example,

    <system
        xmlns="urn:example:system"
        xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">

      <hostname or:origin="or:dynamic">bar</hostname>

      <interface or:origin="or:intended">
        <name>eth0</name>
        <auto-negotiation>
          <enabled or:origin="or:default">true</enabled>
          <speed>1000</speed>
        </auto-negotiation>
        <speed>100</speed>
        <address>
          <ip>2001:db8::10</ip>
          <prefix-length>64</prefix-length>
        </address>
        <address or:origin="or:dynamic">
          <ip>2001:db8::1:100</ip>
          <prefix-length>64</prefix-length>
        </address>
      </interface>

I guess it "or:dynamic" should be replaced by "or:learned"

Justification:

      identity learned {
        base origin;
        description
          "Denotes configuration learned from protocol interactions with
           other devices, instead of via either the intended
           configuration datastore or any dynamic configuration
           datastore.

           Examples of protocols that provide learned configuration
           include link-layer negotiations, routing protocols,_and DHCP._";

_Editorial:_

- number the figures

- section 8.2
    This document registers two YANG modules in the YANG Module Names
    registry [RFC6020 <https://tools.ietf.org/html/rfc6020>].  Following the format in [RFC6020 <https://tools.ietf.org/html/rfc6020>], the the
    following registrations are requested:

duplicated "the the"
  
Regards, Benoit (OPS AD)

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 20 Dec 2017 22:25:19 +0100 (CET)

Hi,

Thanks for this review!

Benoit Claise <[email-masked]> wrote:
> Let me take an example. I have a router with a Line Card configured
> and working well. if I remove the LC, the configuration should still
> be in the <running> and <intended> but not in <operational>.
> However, based on figure below, the notion of "inactive" nodes might
> be misleading. Indeed, people might read that the LC is inactive, so
> the LC configuration should not be in <intended>
> 

Ok, I will make this change.

> I guess it "or:dynamic" should be replaced by "or:learned"

Yes, I'll fix this.

>           include link-layer negotiations, routing protocols,_and DHCP._";

Ok.

>    registry [RFC6020 <https://tools.ietf.org/html/rfc6020>].  Following
>    the format in [RFC6020 <https://tools.ietf.org/html/rfc6020>], the the

Fixed.

Chairs, should I post a new version with these fixes?

/martin

---

From: Vladimir Vassilev <[email-masked]>
Date: Wed, 20 Dec 2017 22:44:32 +0100

Hello,

>     <intended> but does not appear in <operational>.

I have some concerns with this section.

Systems implementing this are expected to remove config true; nodes 
while figuring the necessary changes to ensure the remaining set of 
config true; nodes in operational validates against the operational 
datastore model. The implementation of this is not a trivial task at 
all. In order to remove configuration nodes considered inactive on the 
fly one needs to remove all references to those nodes in mandatory 
leafrefs in the best case and a potentially long and complex dependency 
chain of YANG constrain-statements (Xpath etc.) have to be resolved in a 
worse case. It is difficult to automate this. It requires significant 
effort to track and remove/fix all those dependencies just to come up 
with valid configuration that represents the configuration without the 
"inactive" nodes which in many usecases is completely unjustified 
implementation effort.

In addition in many cases it is not desirable to remove config true; 
nodes that depended on a removed resource. For example:

1. A configuration instance of a filter with mandatory interface-ref 
ingress and egress ports has to be removed from the operational 
datastore if the egress port is removed as a physical resource. This in 
effect removes the config false; statistics that might be still of 
interest counting the matched  traffic while the filter does not have 
physical egress port to send the packets.

2. Alarm that is configured with mandatory reference to the missing 
resource containing a counter of the elapsed time since the resource 
went missing etc.

I do not find any text in the draft addressing the concerns above. I do 
not propose a change yet but I hope to hear what others think about that.

Vladimir

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Lou Berger <[email-masked]>
Date: Wed, 20 Dec 2017 16:56:24 -0500

> Chairs, should I post a new version with these fixes?
Please, but only once you have addressed/closed Vladimir's comment.

Thanks,
Lou

---

From: Robert Wilton <[email-masked]>
Date: Thu, 21 Dec 2017 10:34:30 +0000

Hi Vladimir,

First point of clarification is that this is not about running/intended 
at all.  The contents of running/intended do not change in anyway 
depending on whether hardware is present or absent.

The section is only concerned with how the configuration is applied in 
operational, and basically says that you cannot apply configuration for 
resources that are missing (which seems reasonable).  E.g. I cannot 
configure an IP address on a physical interface that isn't there.  Or if 
the physical interface gets removed then the configuration associated 
with that interface is also removed from operational.

Operational isn't validated and data model constraints are allowed to be 
broken (ideally transiently).  But I agree that there could be 
configuration that is referencing those missing resources, and depending 
on implementation then that configuration may need to become not applied 
as well.  Or perhaps the failure is reported in a different way (e.g. 
IGP neighbor is down).

I also agree that this is non trivial, but the systems that I am 
familiar with have always had to deal with this issue.  At the data 
model level I don't think that this is any more complex than the 
existing 'when' statement processing that has exactly the same issues if 
a "when" statement becomes invalid during a config change and requires 
the associated configuration to be deleted (which again can recursively 
require configuration to be removed).

Alternative solutions are:
  - mandate that nobody physically removes a linecard if there is still 
configuration referencing it, but it is hard to enforce this in software :-)
  - freeze the config from any further changes if a linecard is removed 
that makes the config invalid, but this doesn't seem like a robust 
solution ...

I think that the existing solution is the best approach.

A couple of further comments inline below as well ...

On 20/12/2017 21:44, Vladimir Vassilev wrote:
>> In order not to be the bottleneck in the process and assuming that 
>> the document will be in "publication requested" pretty soon, here is 
>> my AD review of draft-ietf-netmod-revised-datastores-08
>>
>> -
>>
>>
>>         5.3.2. Missing Resources
>>
> leafrefs in the best case and a potentially long and complex 
> dependency chain of YANG constrain-statements (Xpath etc.) have to be 
> resolved in a worse case. It is difficult to automate this. It 
> requires significant effort to track and remove/fix all those 
> dependencies just to come up with valid configuration that represents 
> the configuration without the "inactive" nodes which in many usecases 
> is completely unjustified implementation effort.
>
> datastore if the egress port is removed as a physical resource. This 
> in effect removes the config false; statistics that might be still of 
This isn't necessarily true.  The architecture does not require that the 
filter object is removed because operational is allowed to violate the 
constraints.  Ultimately I think that the behaviour here will depend on 
implementation.

> resource containing a counter of the elapsed time since the resource 
Again, the draft does not require that the alarm becomes not applied.  
This also depends on the implementation.

Thanks,
Rob

>
> I do not find any text in the draft addressing the concerns above. I 
> do not propose a change yet but I hope to hear what others think about 
> that.
>
> Vladimir
>
>>     registry [RFC6020 <https://tools.ietf.org/html/rfc6020>].  
>> Following the format in [RFC6020 
>> <https://tools.ietf.org/html/rfc6020>], the the

---

From: Vladimir Vassilev <[email-masked]>
Date: Thu, 21 Dec 2017 14:03:45 +0100

On 12/21/2017 11:34 AM, Robert Wilton wrote:

> Hi Vladimir,
>
> First point of clarification is that this is not about 
> running/intended at all.  The contents of running/intended do not 
> change in anyway depending on whether hardware is present or absent.
>
> operational, and basically says that you cannot apply configuration 
> for resources that are missing (which seems reasonable).  E.g. I 
> cannot configure an IP address on a physical interface that isn't 
> there.  Or if the physical interface gets removed then the 
> configuration associated with that interface is also removed from 
> operational.
>
> Operational isn't validated and data model constraints are allowed to 
> be broken (ideally transiently).
I want to focus on this. IMO giving up schema validitiy for any 
datastore is unacceptable price. Pre-NMDA devices had full model support 
in operational data (all YANG constrains part of the model without 
discrimination were enforced). If this is about to change it will 
compromise interoperability and a significant portion of the client 
implementation workload that can be automated will need to be coded in 
hand and tested. Unresolved leafrefs, undefined behaviour of different 
implementations removing different configuration nodes in violation of 
YANG semantic constraints (which I do not think can be so clearly 
separated from the syntactic constraints when one considers types like 
leafref, instance-identifier etc.) and the corresponding side effects 
based on the server implementators own creativity is eventually going to 
create more problems.

1. IMO the only acceptable solution is to have YANG valid operational 
datastore at all times. operational like any other datastore MUST be 
valid YANG data tree and it has to be a system implementation task to 
consider all complications resulting from the removal of the resources 
leading to any data transformations. If this is difficult or impossible 
other mechanisms to flag missing resources should be used (e.g. 
/interfaces/interface/oper-status=not-present) This sounds like a useful 
contract providing the value of a standard the alternative does not.

2. Even with the change in 1. I do not see the removal of intended 
configuration nodes from operational as a solution worth implementing on 
our servers. I do not see a real world plug-and-play scenario that can 
be automatically solved without specific additions to the models e.g. 
/interfaces/interface/oper-status=not-present is oversimplified solution 
but it needs to be extended exactly as much as the solution provided by 
the removal of config true; nodes without the sacrifice of YANG validity 
of operational.

3. Solutions like /interfaces/interface/admin-state stop working. With 
the interface removed you can no longer figure if the if-mib has or does 
not have the interface enabled so an operator has to use SNMP or wait 
for a replacement line card to be connected to figure this bit of 
information. My interpretation of the MAY as requirement level in sec. 
5.3. The Operational State Datastore (<operational>) is that 
plug-and-play solutions can be implemented without this limited approach 
that has the same problem as the pre-NMDA only now we have to have 
/interfaces-state to keep config false; data relevant to hardware that 
is configured but not present:

    configuration data nodes supported in a configuration datastore
    MAY be omitted from <operational> if a server is not able to
    accurately report them.

I realize this discussion comes late. I have stated my objections to 
this particular part of the NMDA draft earlier.

Vladimir

>   But I agree that there could be configuration that is referencing 
> those missing resources, and depending on implementation then that 
> configuration may need to become not applied as well.  Or perhaps the 
> failure is reported in a different way (e.g. IGP neighbor is down).
>
> existing 'when' statement processing that has exactly the same issues 
> if a "when" statement becomes invalid during a config change and 
> requires the associated configuration to be deleted (which again can 
> recursively require configuration to be removed).
>
>> all. In order to remove configuration nodes considered inactive on 
>> the fly one needs to remove all references to those nodes in 
>> mandatory leafrefs in the best case and a potentially long and 
>> complex dependency chain of YANG constrain-statements (Xpath etc.) 
>> have to be resolved in a worse case. It is difficult to automate 
>> this. It requires significant effort to track and remove/fix all 
>> those dependencies just to come up with valid configuration that 
>> represents the configuration without the "inactive" nodes which in 
>> many usecases is completely unjustified implementation effort.
>>
> This isn't necessarily true.  The architecture does not require that 
> the filter object is removed because operational is allowed to violate 
> the constraints.  Ultimately I think that the behaviour here will 
> depend on implementation.
>
>>
>> do not propose a change yet but I hope to hear what others think 
>> about that.
>>
>> Vladimir
>>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 21 Dec 2017 14:20:30 +0100

On Thu, Dec 21, 2017 at 02:03:45PM +0100, Vladimir Vassilev wrote:
> > broken (ideally transiently).
> I want to focus on this. IMO giving up schema validitiy for any datastore is
> unacceptable price. Pre-NMDA devices had full model support in operational
> data (all YANG constrains part of the model without discrimination were
> enforced).

There was a long debate about the value of returning the true
operational state. What do you do if the operational state is invalid?
A server can reject configuration changes if they lead to invalid
state, a server can not reject reality.

> If this is about to change it will compromise interoperability
> and a significant portion of the client implementation workload that can be
> automated will need to be coded in hand and tested. Unresolved leafrefs,
> undefined behaviour of different implementations removing different
> configuration nodes in violation of YANG semantic constraints (which I do
> not think can be so clearly separated from the syntactic constraints when
> one considers types like leafref, instance-identifier etc.) and the
> corresponding side effects based on the server implementators own creativity
> is eventually going to create more problems.
> 
> datastore at all times. operational like any other datastore MUST be valid
> YANG data tree and it has to be a system implementation task to consider all
> complications resulting from the removal of the resources leading to any
> data transformations. If this is difficult or impossible other mechanisms to
> flag missing resources should be used (e.g.

As said above, it is impossible to report valid operational state if
the operational state is not valid according to the models.

> configuration nodes from operational as a solution worth implementing on our
> servers. I do not see a real world plug-and-play scenario that can be
> automatically solved without specific additions to the models e.g.
> /interfaces/interface/oper-status=not-present is oversimplified solution but
> it needs to be extended exactly as much as the solution provided by the
> removal of config true; nodes without the sacrifice of YANG validity of
> operational.

Your thinking is likely wrong. <operational> reports the operational
state. It may have little in common with <intended>. Trying to derive
operational from intended is likely a not well working approach.

> 3. Solutions like /interfaces/interface/admin-state stop working. With the
> interface removed you can no longer figure if the if-mib has or does not
> have the interface enabled so an operator has to use SNMP or wait for a
> replacement line card to be connected to figure this bit of information.

At least on my boxes, if I remove a line card, the interface also
disappears in SNMP tables. Stuff that is operationally not present is
simply operationally not present.

> My
> interpretation of the MAY as requirement level in sec. 5.3. The Operational
> State Datastore (<operational>) is that plug-and-play solutions can be
> implemented without this limited approach that has the same problem as the
> pre-NMDA only now we have to have /interfaces-state to keep config false;
> data relevant to hardware that is configured but not present:
> 
> I realize this discussion comes late. I have stated my objections to this
> particular part of the NMDA draft earlier.

I believe there is a conceptual misunderstanding. I think there never
was a requirement that a server reports the state of hardware that is
not present.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Robert Wilton <[email-masked]>
Date: Thu, 21 Dec 2017 14:53:52 +0000

On 21/12/2017 13:03, Vladimir Vassilev wrote:
>> The section is only concerned with how the configuration is applied 
>> in operational, and basically says that you cannot apply 
>> configuration for resources that are missing (which seems 
>> reasonable).  E.g. I cannot configure an IP address on a physical 
>> interface that isn't there.  Or if the physical interface gets 
>> removed then the configuration associated with that interface is also 
>> removed from operational.
>>
> datastore is unacceptable price. Pre-NMDA devices had full model 
> support in operational data (all YANG constrains part of the model 
> without discrimination were enforced). If this is about to change it 
> will compromise interoperability and a significant portion of the 
> client implementation workload that can be automated will need to be 
> coded in hand and tested.
I don't agree with this.  A client can easily see if configuration has 
been applied by looking at the corresponding data node in the 
operational datastore.  If <operational> is fully implemented then this 
applies to any data node in the configuration.

> Unresolved leafrefs, undefined behaviour of different implementations 
> removing different configuration nodes in violation of YANG semantic 
> constraints (which I do not think can be so clearly separated from the 
> syntactic constraints when one considers types like leafref, 
> instance-identifier etc.) and the corresponding side effects based on 
> the server implementators own creativity is eventually going to create 
> more problems.
I believe that returning the truth is more important that returning 
false information (or no information at all) to satisfy constraints in a 
schema model.

> leading to any data transformations. If this is difficult or 
> impossible other mechanisms to flag missing resources should be used 
> (e.g. /interfaces/interface/oper-status=not-present) This sounds like 
> a useful contract providing the value of a standard the alternative 
> does not.
I think that forcing operational to always be consistent quickly falls 
down as a solution:
  - In the case of a device with multiple linecards you cannot force 
that they are always lockstep in sync with each other.
  - In a case of device with multiple concurrent daemon processes, you 
cannot force that they always all have a consistent view of the 
operational state.
  - When configuration is changing the system may go through transient 
states where the operational state is invalid.
  - The system might run of memory, or daemons crash, or fail, or become 
corrupted, all leaving the system in an invalid operational state.
- You can't stop someone from physical removing an piece of hardware, 
which could immediately make the applied configuration and operational 
state inconsistent (or inaccurate).

If you don't allow invalid states to be reported then you merely prevent 
the client from querying any operational state from the device whilst it 
is an inconsistent state.  I.e. the making the device harder to manage, 
and less maintainable.

The "other mechanism" that you describe above sounds like it requires an 
adhoc solution to this problem for every schema node. The <operational> 
datastore solves this problem in a generic way.  A client can always see 
what configuration is currently applied in the system.

> configuration nodes from operational as a solution worth implementing 
> on our servers. I do not see a real world plug-and-play scenario that 
> can be automatically solved without specific additions to the models 
> e.g. /interfaces/interface/oper-status=not-present is oversimplified 
> solution but it needs to be extended exactly as much as the solution 
> provided by the removal of config true; nodes without the sacrifice of 
> YANG validity of operational.
There is somewhat of an implementation choice in this.

The server is obliged to return what is "in use" in operational, but it 
is up to the server vendor to decide what "in use" actually means for a 
particular item of configuration (e.g. for a configured value that might 
be distributed to multiple internal daemons).

> the interface removed you can no longer figure if the if-mib has or 
> does not have the interface enabled so an operator has to use SNMP or 
> wait for a replacement line card to be connected to figure this bit of 
> plug-and-play solutions can be implemented without this limited 
> approach that has the same problem as the pre-NMDA only now we have to 
> have /interfaces-state to keep config false; data relevant to hardware 
> that is configured but not present:
Admin-status is the intended configuration, clients can always query 
<running> or <intended> to see the desired state of the system.  They 
can also query <operational> and see that the interface doesn't 
currently exist in the system.  The rest of the properties associated 
with the interface sort of seem a bit irrelevant at that point.

/interfaces-state is deprecated and going away.  Its direct equivalent 
is /interfaces in <operational>.  I'm not sure that the semantics 
between the two has necessarily changed very much, except that the NDMA 
architecture now describes a formal mechanism for hardware removal, 
whereas previously it was left entirely to the vendors to each do their 
own thing.

For some of our systems, the applied configuration for a physical 
interface is managed on the linecard hosting that interface.  If that 
linecard is pulled out then all of that applied configuration really has 
gone.  In other cases, a user might remove the optics module for an 
interface, in which case the interface still exists but the interface is 
reported as being operationally down.

> this particular part of the NMDA draft earlier.
Yes, this discussion does seem very late.

Did you raise your comments during either of the WG LCs?  I thought that 
I had been pretty diligent tracking and replying to all issues that had 
been raised during the WG LC.

Thanks,
Rob

>>  - mandate that nobody physically removes a linecard if there is 
>> still configuration referencing it, but it is hard to enforce this in 
>> software :-)
>>  - freeze the config from any further changes if a linecard is 
>> removed that makes the config invalid, but this doesn't seem like a 
>> robust solution ...
>>
>>>> the document will be in "publication requested" pretty soon, here 
>>>> is my AD review of draft-ietf-netmod-revised-datastores-08
>>>>
>>>> -
>>>>
>>>>
>>>>         5.3.2. Missing Resources
>>>>
>>> in effect removes the config false; statistics that might be still 
>>> of interest counting the matched traffic while the filter does not 
>>> have physical egress port to send the packets.
>> the filter object is removed because operational is allowed to 
>> violate the constraints.  Ultimately I think that the behaviour here 
>> will depend on implementation.
>>
>>>
>> Again, the draft does not require that the alarm becomes not 
>> applied.  This also depends on the implementation.
>>
>> Thanks,
>> Rob
>>
>>
>>>
>>>> and working well. if I remove the LC, the configuration should 
>>>> still be in the <running> and <intended> but not in <operational>.
>>>> However, based on figure below, the notion of "inactive" nodes 
>>>> might be misleading. Indeed, people might read that the LC is 
>>>> inactive, so the LC configuration should not be in <intended>
> .

---

From: Vladimir Vassilev <[email-masked]>
Date: Thu, 21 Dec 2017 19:52:54 +0100

> state, a server can not reject reality.
IMO if the model can represent reality then data conforming to the model 
can. If not a better model is needed not a hack that breaks the 
datastore conformance to the YANG model. I do not see how 
/interfaces/interface/oper-status=not-present was not representing the 
reality of a system with removed line card that is configured and ready 
to resume operation as soon as the line card is reconnected.
> operational from intended is likely a not well working approach.
The proposal for this solution ("derive operational from intended" e.g. 
merge /interfaces-state in /interfaces) comes from the revised 
datastores draft not me.

By definition config true; data represents intent. Reusing the model of 
a config true; data to represent state absent of intent (e.g. 
/interfaces/interface with origin="or:system") is a hack. The hack works 
fine without compromising the conformance of operational to the YANG 
model as long as certain conditions are met. I am pointing out that one 
of the conditions is to keep all of the intended configuration data 
present in 'operational' and handle missing resources with conventional 
means e.g. /interfaces/interface/oper-status=not-present instead of 
adding the straw that breaks the camel's back.

> was a requirement that a server reports the state of hardware that is
"Data relevant to hardware that is configured but not present" is 
different from "state of hardware that is not present". For example 
information indicating when the line card became unavailable, what was 
the reason, or other information like how many packets that had this 
interface as egress destination are being dropped as a result of the 
removal.

Vladimir

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 21 Dec 2017 23:27:42 +0100

On Thu, Dec 21, 2017 at 07:52:54PM +0100, Vladimir Vassilev wrote:
> can. If not a better model is needed not a hack that breaks the datastore
> conformance to the YANG model. I do not see how
> reality of a system with removed line card that is configured and ready to
> resume operation as soon as the line card is reconnected.

I assume this is all system and implementation specific. If your
system knows about interfaces that are not present (i.e., there is
operational state about them), you can report these interfaces.  But
'is configured' is confusing here. I am not sure a line card that does
not exist should be considered configured. But yes, this may be system
specific. Anyway, draft-ietf-netmod-rfc7223bis-01.txt still has
oper-status 'not-present' - so this seems to be a mood point.

> merge /interfaces-state in /interfaces) comes from the revised datastores
> draft not me.
>
> By definition config true; data represents intent. Reusing the model of a
> config true; data to represent state absent of intent (e.g.
> fine without compromising the conformance of operational to the YANG model
> as long as certain conditions are met. I am pointing out that one of the
> conditions is to keep all of the intended configuration data present in
> 'operational' and handle missing resources with conventional means e.g.
> /interfaces/interface/oper-status=not-present instead of adding the straw
> that breaks the camel's back.

I fail to see why you believe all objects that appear in intended
configuration needs to exist in applied configuration. In fact,
operators told us very clearly that they care about the distinction
between intended and applied config.
 
> "Data relevant to hardware that is configured but not present" is different
> from "state of hardware that is not present". For example information
> indicating when the line card became unavailable, what was the reason, or
> other information like how many packets that had this interface as egress
> destination are being dropped as a result of the removal.

I think that systems handle non-existing interfaces differently. It
seems that ietf-interfaces is flexible enough to accomodate the
differnet styles.

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 21 Dec 2017 14:49:59 -0800

Hi,

It should be clear somehow that server requirements to provide config=false
data
that is valid according to the YANG definitions is not affected by NMDA.
That is not being taken away.  The ability to validate operational values
of configuration data has never been provided, and therefore is not being
taken away either.

A constraint on config=true nodes only applies to configuration datastores.
These are the only constraints that should be ignored in <operational>.
Constraints on config=false nodes still apply in <operational>.

Andy

On Thu, Dec 21, 2017 at 2:27 PM, Juergen Schoenwaelder <
[email-masked]> wrote:

> running/intended
> datastore is
> to
> valid
> model
> this
> different