Subject: [netmod] Y12: initialized-by system

From: Martin Bjorklund <[email-masked]>
Date: Mon, 23 Mar 2015 19:35:23 -0500 (CDT)

Hi,

The issue Y12 is in EDIT state.  But looking at the edits and thinking
some more, I am having second thoughts.  I don't think we should add
this new statement, and the issue should be moved to DEAD.

The idea behind this statement is to be able to catch situations where
the device will initialize some leaf when a parent list/container is
created.  By having this marked in the data model, a client knows that
this is happening, and can theoretically react accordingly.

The first observation is that this rarely happens.

The second observation is that this new statement solves only parts of
this (rare) problem.  For example, there are cases where the device
will modify the value that is being written to a leaf (e.g., changing
a clear text password into a hashed or encrypted value).  At the YANG
editing session yesterday, it was mentioned that a certain device
would initialize not just a leaf, but a nested list instance when the
parent node is created.

So, for these reasons, I suggest we do not add this new statement.

/martin

---

From: Phil Shafer <[email-masked]>
Date: Mon, 23 Mar 2015 20:48:07 -0400

Would it make sense to have  a simpler "you need to re-read this
data after you create it" flag that's less specific/more useful?

Thanks,
 Phil

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

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 23 Mar 2015 19:56:04 -0500 (CDT)

> data after you create it" flag that's less specific/more useful?

That seems to cover the "cleartext to hash" use case, but not the
original initialized-by system use case (since in that case the data
is created by the server, not the client).

But something like this would be needed.  The question is now if this
falls into the category of being useful enough to be included in YANG
1.1 or not.  I think this could also be done w/ extensions later.

/martin

---

From: Kent Watsen <[email-masked]>
Date: Tue, 24 Mar 2015 15:12:21 +0000

Adding to Phil's comment, we tried to do something like this a fews years
back - we called it implicit-changes.  We created three solutions trying
to address the issue:

  1) putting markup into the data-model describing conditions
     that would cause implicit changes  (similar to Y12)

  2) have the device return an roc-error of type warning for
     when any implicit changes occurred, returning an optional
     list of xpaths to the nodes that changed

  3) have the NETCONF client fetch the entire config after each
     update, on the off-chance that an impact change occurred.

In the end, #2 was the winner, as it was easy to implement and covered all
cases.  #1 was not popular with the router engineers.  Sooner or later,
we'll need to update netconf/restconf (not yang) to support this.  FWIW,
ETag solves a related but different problem.

For the example listed in Y12, would it make sense to model it as a
config=false value? As a corollary, we many times discuss the configured
MTU value and the running MTU value.

Also, for systems having 'explicit' default handling, would initialized-by
system be treated like user configuration or a default value?   Maybe a
better solution is to give for default statement a special value?  (e.g.
default initialized-by-system)

Thanks,
Kent

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 24 Mar 2015 10:23:13 -0500 (CDT)

> ETag solves a related but different problem.

So does this mean that you also support moving Y12 to DEAD?

> config=false value?

I don't think so b/c you want to be able to save the
system-initialized values in your backup and be able to restore the
backup w/ the correct uid values; you don't what the system to assign
different values when the backup is restored.

> system be treated like user configuration or a default value?

User configuration.

/martin

---

From: Kent Watsen <[email-masked]>
Date: Tue, 24 Mar 2015 15:46:25 +0000

>So does this mean that you also support moving Y12 to DEAD?

Yes.  For netconf/restconf clients, the proposed solution is not
comprehensive enough, and the remaining value of the initialized-by
statement can equally by captured in the node's description statement.

Thanks,
Kent

---

From: "Sterne, Jason (Jason)" <[email-masked]>
Date: Tue, 24 Mar 2015 19:06:12 +0000

>From below:

>> Also, for systems having 'explicit' default handling, would 
>> initialized-by system be treated like user configuration or a default value?
>
>User configuration.

Agree this should be modeled as user config. There may be initialized-by system objects that are list entries (not just basic leaves) that can be deleted by the client/operator. You'd want to see those in a <get-config> response (for explicit or trim systems).

Jason

-----Original Message-----
From: netmod [mailto:[email-masked]] On Behalf Of Martin Bjorklund
Sent: Tuesday, March 24, 2015 10:23 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [netmod] Y12: initialized-by system

Kent Watsen <[email-masked]> wrote:
> 
> Adding to Phil's comment, we tried to do something like this a fews 
> years back - we called it implicit-changes.  We created three 
> solutions trying to address the issue:
> 
> In the end, #2 was the winner, as it was easy to implement and covered 
> all cases.  #1 was not popular with the router engineers.  Sooner or 
> later, we'll need to update netconf/restconf (not yang) to support 
> this.  FWIW, ETag solves a related but different problem.

> For the example listed in Y12, would it make sense to model it as a 

I don't think so b/c you want to be able to save the system-initialized values in your backup and be able to restore the backup w/ the correct uid values; you don't what the system to assign different values when the backup is restored.

> Also, for systems having 'explicit' default handling, would 
> initialized-by system be treated like user configuration or a default value?

User configuration.

/martin

---

From: "Sterne, Jason (Jason)" <[email-masked]>
Date: Tue, 24 Mar 2015 19:11:25 +0000

Hi Kent,

Did you end up implementing and deploying with these severity=warning responses ? It sounds like it but just checking if it caused any problems with clients (not sure if it has had enough field exposure yet).

We've also looked at using the rpc-error warning severity for some similar cases (i.e. somehow indicating side-effects) but we've been hesitant for a few reasons:
1) in theory the NETCONF RFC doesn't support them (no standard rpc-error responses with severity=warning)
2) not sure if most NETCONF clients might just see the <rpc-error> and not check the severity. Many may just implicitly consider any rpc-error as severity=error.

Jason

-----Original Message-----
From: netmod [mailto:[email-masked]] On Behalf Of Kent Watsen
Sent: Tuesday, March 24, 2015 10:12 AM
To: Martin Bjorklund; Phil Shafer
Cc: [email-masked]
Subject: Re: [netmod] Y12: initialized-by system

Adding to Phil's comment, we tried to do something like this a fews years back - we called it implicit-changes.  We created three solutions trying to address the issue:

In the end, #2 was the winner, as it was easy to implement and covered all cases.  #1 was not popular with the router engineers.  Sooner or later, we'll need to update netconf/restconf (not yang) to support this.  FWIW, ETag solves a related but different problem.

For the example listed in Y12, would it make sense to model it as a config=false value? As a corollary, we many times discuss the configured MTU value and the running MTU value.

Thanks,
Kent

On 3/23/15, 8:56 PM, "Martin Bjorklund" <[email-masked]> wrote:

>> Would it make sense to have  a simpler "you need to re-read this data 
>> after you create it" flag that's less specific/more useful?
>
>original initialized-by system use case (since in that case the data is 
>created by the server, not the client).
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 25 Mar 2015 14:02:27 +0100

>      update, on the off-chance that an impact change occurred.

Another option could be to generate a nc:netconf-config-change
notification. Of course, this requires that clients pay attention to
these notification (but if they really want to always be in sync, I
guess they better do anyway).

/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: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 25 Mar 2015 14:03:20 +0100

> So, for these reasons, I suggest we do not add this new statement.

Anybody against Martin's proposal to move this to DEAD?

/js