Subject: [netmod] Comments on NMDA-04

From: Balazs Lengyel <[email-masked]>
Date: Thu, 14 Sep 2017 16:04:14 +0200

Hello,

Reading the draft-ietf-netmod-revised-datastores-04 some comments:

General) The system often adds data to the <running> or <intended> 
datastore already not just to <operational>: e.g.

UC1: I have a server configured in running. I need to bind it to an 
ip-address. The ip-address might be the local loopback address, however 
if that is only added to the <operational>, validation will fail 
indicating that the server is bound to a non-existent address. How to 
handle this?

UC2: I have a set of capabilities set by the system e.g. 
supported-reporting-intervals. I need to configure a job that MUST use 
one of these intervals. If the supported-reporting-intervals are only 
added to <operational> I can not validate the selected-interval in my 
configured job.

My proposal is to allow the system to add data to running as well. 
Actually I think that is a more relevant case then adding configuration 
just to <operation>.

CH 4.4.)  "Validation is performed on  the contents of <intended>." This 
to me means that default data is not considered at validation which 
would be a backwards incompatible change. Also if validation does not 
consider system configured data that would allow cases like multiple 
interfaces named lo0. One from <intended> one from system configuration. 
IMHO while it is OK to violate uniqueness because of remnant data, the 
above violation of uniqueness seems a bad idea.

Ch. 4.7) Is it allowed to violate uniqueness of key values? IMHO it 
should not be.

Ch 5.1) IMHO actions and rpcs should be allowed to include other 
datastores in their XPath evaluation. My suggestion is that they need to 
specify it somehow. (Yang extension?)

UC1) I want to define a convinience action that allows me to do a big 
modification in <running> in one step. I wan't to validate what it is 
doing based on the current contents of running. E.g. configure the OAM 
settings for the system including SNMP/Netconf/FTP in one step, but for 
each step I need to check that I am putting the relevant server on an 
existing interface.
If specifying the datastore is an overkill, I would still rather chose 
runing as the accessible datastore. XPath is mostly use for checks. 
Checks are done against configuration.

Appendix B)

"4. How applied     : automatic"    This is definitely not enough to 
understand what happens even as an example. I propose:
Changes are automatically propagated to <operational>

C.1)  During the example the
     <ip>2001:db8::10</ip>
      <prefix-length>32</prefix-length>
is changed to 64 its. Is that intentional? It is not mentioned in the text.

regards Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: [email-masked]

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 14 Sep 2017 16:32:39 +0200 (CEST)

Hi Balazs,

Thanks for your review.  Comments inline.

Balazs Lengyel <[email-masked]> wrote:
> ip-address. The ip-address might be the local loopback address,
> however if that is only added to the <operational>, validation will
> fail indicating that the server is bound to a non-existent
> address. How to handle this?
> 
> UC2: I have a set of capabilities set by the system
> e.g. supported-reporting-intervals. I need to configure a job that
> MUST use one of these intervals. If the supported-reporting-intervals
> are only added to <operational> I can not validate the
> selected-interval in my configured job.
> 
> My proposal is to allow the system to add data to running as
> well. Actually I think that is a more relevant case then adding
> configuration just to <operation>.

I think the consensus is that in general it is a bad idea if servers
(spontaneously) add data to <running>.  However, there is nothing in
the new or old architectures that prohibits this.

Also note that the draft says:

  Currently there are no standard mechanisms defined that affect
  <intended> so that it would have different contents than <running>,
  but this architecture allows for such mechanisms to be defined.

which means that you can also define your own mechanisms for adding
things to <intended>, before validation.

> CH 4.4.)  "Validation is performed on the contents of <intended>."
> This to me means that default data is not considered at validation

Note that RFC 7950, section 6.4.1, says:

   In the accessible tree, all leafs and leaf-lists with default values
   in use exist (see Sections 7.6.1 and 7.7.2).

So defaults are taken into account when intended is validated.

> which would be a backwards incompatible change. Also if validation
> does not consider system configured data that would allow cases like
> multiple interfaces named lo0. One from <intended> one from system
> configuration. IMHO while it is OK to violate uniqueness because of
> remnant data, the above violation of uniqueness seems a bad idea.

If your system adds data to <running>, or to <intended>, it will be
validated.

> Ch. 4.7) Is it allowed to violate uniqueness of key values? IMHO it

Agreed.  Note that the draft explicitly lists the constraints that can
be violated, and uniqueness of keys is not listed.

> datastores in their XPath evaluation. My suggestion is that they need
> to specify it somehow. (Yang extension?)

This is something that the WG has discussed in the past as well, but
so far no concrete proposal has been made.  I think such extensions
can be done in a separate document in the future, or maybe if we do a
new version of YANG.

But note that for rpc and action, this section only talks about
XPath in input/output parameters.

> settings for the system including SNMP/Netconf/FTP in one step, but
> for each step I need to check that I am putting the relevant server on
> an existing interface.

I think this is covered.  If you have an rpc that modifies <running>,
the result will be valdiated according to the must expression in the
data models.

> runing as the accessible datastore. XPath is mostly use for
> checks. Checks are done against configuration.
> 
> Appendix B)
> 

I agree this is better.

> is changed to 64 its. Is that intentional? It is not mentioned in the

No this is a bug, will be fixed!

/martin

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 14 Sep 2017 17:35:51 +0200

See below!

On 2017-09-14 16:32, Martin Bjorklund
wrote:

Hi Balazs,

Hello,

however if that is only added to <operational>, validation will

BALAZS: I strongly disagree.  I know others are also adding stuff to
running as well.

IMHO the above use cases are real and used and actually important
for us.

I would like to see them included in some way.

regards Balazs

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 14 Sep 2017 17:44:00 +0200

See below !

> So defaults are taken into account when intended is validated.
BALAZS: Yes the two seem to contradict each other. This can be 
understood in your way, however the current text is not clear enough. I 
would add:
Validation is performed on the contents of <intended> (EXTENDED WITH 
DEFAULT CONFIGURATION).
> be violated, and uniqueness of keys is not listed.
BALAZS: If that is the intent I would propose to explicitly state it. 
For me it was non-trivial.
Can a a choice statement be violated? Having to existing branches at the 
same time? It seems a semantic constraint to me. IMHO yes.
Can an if-feature be violated? If  support has just changed and we have 
some remnant config, I can very well imagine it violated.

Also here could you change
If a node in  <operational> does not meet the syntactic constraints then 
it cannot   be returned
to
If a node in  <operational> does not meet the syntactic constraints then 
it MUST NOT be returned

---

From: Robert Wilton <[email-masked]>
Date: Thu, 14 Sep 2017 18:01:52 +0100

Hi Balazs,

Thanks for the review and comments.

On 14/09/2017 16:44, Balazs Lengyel wrote:
> understood in your way, however the current text is not clear enough. 
> I would add:
As an alternative suggestion, rather than saying contents of <intended>, 
we could instead say something like "<intended>must always be a valid 
configuration data tree.". Is that better?  I would rather not talk 
about "defaults for <intended> since that may imply that they are not 
applicable to other configuration datastores".  E.g. if <running> is 
validated then you would also expect defaults to be considered. Ditto 
for startup, candidate.

Thanks,
Rob

> Can a a choice statement be violated? Having to existing branches at 
> the same time? It seems a semantic constraint to me. IMHO yes.
> Can an if-feature be violated? If  support has just changed and we 
> have some remnant config, I can very well imagine it violated.
>
> If a node in  <operational> does not meet the syntactic constraints 
> then it cannot   be returned
> to
> If a node in  <operational> does not meet the syntactic constraints 
> then it MUST NOT be returned
>> /martin
>

---

From: Robert Wilton <[email-masked]>
Date: Thu, 14 Sep 2017 18:08:36 +0100

On 14/09/2017 16:35, Balazs Lengyel wrote:
>> Balazs Lengyel<[email-masked]>  wrote:
>>> Hello,
>>>
> IMHO the above use cases are real and used and actually important for us.
I basically agree with Martin here.

The architecture is cleaner if <running> is only written by the client.  
This avoid requiring clients tracking unexpected changes to running, and 
opens up the possibility of validating configuration off the box.  
Ideally extra stuff should be added into <intended> and then become 
visible in <operational>.

I understand that some systems add data to <running>, and this is fine.  
But I think that it is better for an architecture document to be silent 
on this point.

Thanks,
Rob

> Mobile: +36-70-330-7909              email:[email-masked]  
>
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Andy Bierman <[email-masked]>
Date: Thu, 14 Sep 2017 10:22:58 -0700

On Thu, Sep 14, 2017 at 10:08 AM, Robert Wilton <[email-masked]> wrote:

> Balazs Lengyel <[email-masked]> <[email-masked]> wrote:
>
> Hello,
>
> opens up the possibility of validating configuration off the box.  Ideally
> extra stuff should be added into <intended> and then become visible in
> <operational>.
>
> But I think that it is better for an architecture document to be silent on
> this point.
>
>
I agree with Balazs that system-created nodes in running are quite common
and
the vendors doing it have no intention of changing it.

If the added nodes need to be saved in non-volatile storage then then
definitely belong in <running>.

IMO the architecture is rather opaque wrt/ the interactions between
datastores,
especially the interactions between <running> and <intended>. Now it not
only
prunes inactive nodes, it adds system nodes?

Maybe it is too early for NMDA to be making lots of rules about how YANG
works
with new (and unimplemented) datastores.

Thanks,
> Rob
Andy

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

---

From: Kent Watsen <[email-masked]>
Date: Thu, 14 Sep 2017 20:30:54 +0000

> I agree with Balazs that system-created nodes in running are quite common and

Of course, what else were they going to do pre-NMDA…and also before require-instance
false?  Green-field deployments wouldn't be encumbered with backwards-compatibility.
Existing implementations are in a bind, but I'd recommend following nmda-guidelines.

For UC1: the loopback would only show in <operational> (as an applied instance of a
config true leaf), and the leafref would be require-instance false.  When committing
configuration that referenced loopback, the server sees that the referenced leaf is not in
<running>/<intended>, but it could see that it is or is-not in <operational>.  And, if it
is not in <operational>, the server might return a warning to the client, or not, assuming
the  client will use other mechanisms to discover what configuration was not applied.

For UC2: similar response.  The server could return a warning (e.g., a synchronous
update) or the client can discover the unapplied config afterwards using other
mechanisms.

> If the added nodes need to be saved in non-volatile storage then then definitely
> belong in <running>.

Neither of Balazs's use-cases regard persisted data, at least I didn't read it that way.

> IMO the architecture is rather opaque wrt/ the interactions between datastores,
> especially the interactions between <running> and <intended>. Now it not only

A template in <running> could be flattened, which has the apparent side-effect
of creating nodes, but not any nodes, just those per the input from <running>.
As the draft says: <intended> does not persist across reboots; its relationship
with <running> makes that unnecessary.   Generically speaking, <running>
can contain processing instructions that are consumed at commit time to
simultaneously create the <intended> view, and these PIs are the only thing
that can cause a deviation between the two datastores.

> Maybe it is too early for NMDA to be making lots of rules about how
> YANG works with new (and unimplemented) datastores.

Juniper has the equivalent of <intended> already.  I think others said they had
something like it as well.

Kent // contributor

---

From: Andy Bierman <[email-masked]>
Date: Thu, 14 Sep 2017 14:27:14 -0700

> Existing implementations are in a bind, but I'd recommend following

This might break non-NMDA clients expecting to see the system-created config
in retrieval responses. I think vendors will decide their own transition
plans
and decide how much disruption at once is OK.

> definitely

If I can only do YANG validation on expanded templates in <intended>, does
that mean
it is impossible to do YANG validation on the templates themselves in
<running>?
The template subtree can only use YANG constraints on external structures
in <intended>
and not refer to itself in anyway (in <running>)?

The RD draft sure has a lot of normative details for something that does
not use RFC 2119
terminology at all. I didn't know a Standards Track document could omit
these terms.
Architecture documents are usually Informational.

IMO the RD draft should not mention YANG or XPath at all.
That should be moved to an update to RFC 7950.
Those parts need more work anyway. The ARCH can move forward
without any dependence on YANG details.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 15 Sep 2017 07:37:54 +0200 (CEST)

> > something like it as well.

Yes, we have that as well.  (No template expansion, but removal of
inactive nodes).

> and not refer to itself in anyway (in <running>)?

Note that the architecture draft does not specify any templating
mechanism, it merely points out that templating is a mechanism that
_can_ influence intended.  When/if such a mechanism is designed, it
needs to work out all these details.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 15 Sep 2017 01:11:04 -0700

> needs to work out all these details.
Doesn't it say YANG validation is done on <intended> and not on <running>?
If so, then how are YANG validation statements inside the template objects
evaluated?
Do they exist in both datastores, yet YANG validation is done in only 1
datastore?

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 15 Sep 2017 10:19:31 +0200

> Do they exist in both datastores, yet YANG validation is done in only 1

What I have understood so far is that template mechanisms differ quite
a bit in the details how they work. Ideally, both the template content
and the expansion resulting from the template content should be valid.
But until someone tries to work out a standard template mechanism, we
simply won't know the details. (And whether a standard for templates
is feasible, I do not know.)

/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: Fri, 15 Sep 2017 12:07:22 +0100

Hi Balazs,

I also wanted to comment on validation.  Please see inline below ...

On 14/09/2017 15:04, Balazs Lengyel wrote:
> fail indicating that the server is bound to a non-existent address. 
> How to handle this?
>
> Actually I think that is a more relevant case then adding 
When we have been previously discussed this as part of the design team, 
we wanted the invariant that <running>/<intended> should not be able to 
become invalid due to an external change in the system (e.g. a linecard 
is removed or changed, or the device has run out of some resource).  I 
think that the corollary to this is that when the existing NETCONF 
validation is performed, the validation must not take into account 
anything specific to the device that could change due to some external 
event (e.g. linecard is changed etc).  So this means that a valid 
configuration just represents what could be applied to the device, if 
enough resources were available, and the correct types of linecards had 
been populated and were working, etc.

But often, clients want more than this.  They don't want to just know 
whether the configuration could theoretically work, but actually want to 
know whether the device anticipates that it will be able to enact the 
configuration successfully.  So, I think that NETCONF actually also 
needs a separate "should apply ok" extension RPC.  This "should apply 
ok" RPC would do everything that validate does today, but can also do 
many more checks to try and ensure that the configuration change is 
likely to be successful applied to <operational> (e.g. check that the 
necessary hardware is present and working, licenses have been enabled, 
resources are available, etc).  Obviously, this "should apply ok" 
invariant would not necessarily always hold for the configuration 
datastores.  An engineer may pull out a linecard that means that 
configuration currently in <running>/<intended> is valid (as is required 
in RFC 7950), but would not be applied successfully due to the missing 
hardware.

But I also think that this is beyond the scope of the current NMDA 
architecture, but perhaps something that could be specified by a 
separate draft, if others also think that this would be useful to 
standardize?

Thanks,
Rob

---

From: Robert Wilton <[email-masked]>
Date: Wed, 20 Sep 2017 16:57:54 +0100

Hi Balazs,

> Validation is performed on the contents of <intended> (EXTENDED WITH 

I've slightly reworked the text on intended.  It was sent to the alias 
yesterday on the thread <running> vs <intended>. The new text on 
intended states "<intended> must always be a 'valid configuration data 
tree' as defined in Section 8.1 of [RFC7950]. "

This implicitly means that it must consider default values, just like 
validation in any other configuration datastore is required to do.

Please can you check the proposed text on intended to see if it 
sufficient to resolve this issue. 
https://github.com/netmod-wg/datastore-dt/issues/9

Thanks,
Rob

---

From: Robert Wilton <[email-masked]>
Date: Thu, 28 Sep 2017 11:26:33 +0100

Hi,

This is regarding the question as to whether it should be allowed for a 
system to manipulate <running>:

This issue isn't really specific to the NMDA architecture, and there is 
no consensus on whether this should be allowed.

Hence, the proposal is that the NMDA architecture draft be completely 
silent on this, neither endorsing this behaviour, not restricting it.  
Hence no changes to the NMDA architecture draft are required for this issue.

However, I have added an FAQ entry to clarify that this being is not 
prevented, but pointing out some of the potential downsides to a device 
doing this.  The FAQ entry is 
https://github.com/netmod-wg/FAQ/wiki/FAQ-related-to-NMDA-implementations#Q9

Unless I hear otherwise, I propose closing this issue 
(https://github.com/netmod-wg/datastore-dt/issues/8). Comments/review of 
the FAQ text is also welcome.

Thanks,
Rob

On 14/09/2017 18:08, Robert Wilton wrote:
> The architecture is cleaner if <running> is only written by the 
> client.  This avoid requiring clients tracking unexpected changes to 
> running, and opens up the possibility of validating configuration off 
> the box.  Ideally extra stuff should be added into <intended> and then 
> become visible in <operational>.
>
> I understand that some systems add data to <running>, and this is 
> fine.  But I think that it is better for an architecture document to 
> be silent on this point.
>
> Thanks,
> Rob
>
>
>>
>> regards Balazs
>> --

---

From: Robert Wilton <[email-masked]>
Date: Thu, 28 Sep 2017 12:10:43 +0100

Hi,

This is regarding issue 
(https://github.com/netmod-wg/datastore-dt/issues/11): actions and rpcs 
should be allowed to include other datastores in their XPath evaluation

There has been no further discussion of this issue after Martin's reply, 
and this seems to be out of scope for the NMDA draft.  Hence the authors 
proposal is to close this issue with no change to the draft.

Thanks,
Rob

---

From: Robert Wilton <[email-masked]>
Date: Thu, 28 Sep 2017 17:28:37 +0100

Hi,

Regarding the issue "Is it allowed to violate uniqueness of key 
values?", https://github.com/netmod-wg/datastore-dt/issues/10

We have discussed this further, and would like to extend the text in the 
draft to explicitly allow key uniqueness to be violated!

We have thought of several cases where it is possible that duplicate 
entries could appear, and we don't want to force any overhead on the 
device to guarantee that this does not occur, nor do we want to force 
synchronization between configuration processing and what is reported in 
<operational>.  Of course, in normal circumstances this constraint, like 
the others, should not be violated.  This is already stated in the draft.

Examples of where uniqueness of list keys could be violated include:
1) If a device is internally paging the results back for a long list, 
then it is possible that a entry could have been reported near the 
beginning of the list, then moved, and then reported again at the end of 
the list.
2) If the list being stored somewhere in the system has become corrupted 
and contains duplicate entries.  It is better to return truth.
3) On a distributed system where the list is being constructed from 
multiple nodes (e.g. linecards or peer devices) then if a list entry is 
moved from one node to another then it is again possible that an entry 
could be reported in both places (or neither) for a short interval 
before the system becomes consistent again.

Proposed text:

OLD:

    <operational> SHOULD conform to any constraints specified in the data
    model, but given the principal aim of returning "in use" values, it
    is possible that constraints MAY be violated under some
    circumstances, e.g., an abnormal value is "in use", or due to remnant
    configuration (see Section 4.3.1).  Note, that deviations are still
    used when it is known in advance that a device does not fully conform
    to the <operational> schema.

    Only semantic constraints MAY be violated, these are the YANG "when",
    "must", "mandatory", "unique", "min-elements", and "max-elements"
    statements.

NEW:

    <operational> SHOULD conform to any constraints specified in the data
    model, but given the principal aim of returning "in use" values, it
    is possible that constraints MAY be violated under some
    circumstances, e.g., an abnormal value is "in use", the structure of
    a list is being modified, or due to remnant configuration (see
    Section 4.3.1).  Note, that deviations are still used when it is
    known in advance that a device does not fully conform to the
    <operational> schema.

    Only semantic constraints MAY be violated, these are the YANG "when",
    "must", "mandatory", "unique", "min-elements", and "max-elements"
    statements; and the uniqueness of key values.

Again, if there are no objections, I will apply this change.

Thanks,
Rob

---

From: Andy Bierman <[email-masked]>
Date: Fri, 29 Sep 2017 09:46:15 -0700

On Thu, Sep 28, 2017 at 9:28 AM, Robert Wilton <[email-masked]> wrote:

> Hi,
>
> Regarding the issue "Is it allowed to violate uniqueness of key values?",
> https://github.com/netmod-wg/datastore-dt/issues/10
>
so we can rubber-stamp buggy servers?
I do not agree this is needed.

> entries could appear, and we don't want to force any overhead on the device
> to guarantee that this does not occur, nor do we want to force
> 1) If a device is internally paging the results back for a long list, then
> it is possible that a entry could have been reported near the beginning of
> the list, then moved, and then reported again at the end of the list.
>

The data is question is simply part of an <rpc-reply> and it is subject to
the validation
requirements for RPC replies only.  Note also that the payload to represent
an arbitrary
configuration datastore has to be done with anydata or anyxml.  RPC reply
validation
rules for these nodes do not extend to contents of the anydata instance.

> and contains duplicate entries.  It is better to return truth.

It is better to fix the buggy server.
Again, a representation of some portion of a datastore in an <rpc-reply>
has nothing to do with the YANG validation of a datastore within a server.

> could be reported in both places (or neither) for a short interval before
> the system becomes consistent again.
>

Once again, this is an <rpc-reply> representation, not the validation of a
datastore
within a server.

Andy

>> BALAZS: Yes the two seem to contradict each other. This can be understood
>> in your way, however the current text is not clear enough. I would add:
>> BALAZS: If that is the intent I would propose to explicitly state it. For
>> me it was non-trivial.