Subject: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-operational-00.txt

From: Martin Bjorklund <[email-masked]>
Date: Fri, 05 Oct 2012 10:28:05 +0200 (CEST)

Hi,

Lada and I have written a draft where we try to define the concept of
operational state data.  There are a couple of open issues in the
draft that need to be discussed, so please comment!

/martin & lada

Subject: New Version Notification for draft-bjorklund-netmod-operational-00.txt
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Date: Fri, 05 Oct 2012 01:23:30 -0700

A new version of I-D, draft-bjorklund-netmod-operational-00.txt
has been successfully submitted by Martin Bjorklund and posted to the
IETF repository.

Filename:	 draft-bjorklund-netmod-operational
Revision:	 00
Title:		 Operational Data in NETCONF and YANG
Creation date:	 2012-10-05
WG ID:		 Individual Submission
Number of pages: 21
URL:             http://www.ietf.org/internet-drafts/draft-bjorklund-netmod-operational-00.txt
Status:          http://datatracker.ietf.org/doc/draft-bjorklund-netmod-operational
Htmlized:        http://tools.ietf.org/html/draft-bjorklund-netmod-operational-00

Abstract:
   This document defines the concept of operational state data in the
   context of YANG and the Network Configuration Protocol (NETCONF).  It
   updates RFC 6020 with rules for how to model the operational state,
   and defines NETCONF operations to retrieve and modify the operational
   state.

The IETF Secretariat

---

From: Andy Bierman <[email-masked]>
Date: Fri, 5 Oct 2012 08:12:59 -0700

> draft that need to be discussed, so please comment!
I will just comment on the problem statements in section 3.

3.1) I don't agree that modeling config and operational data
separately is is real problem, or that it is counter-intuitive
to operators.

The operational state (e.g., FIB) may come from multiple
parts of the configuration, not just the simple example shown
in sec. 3.1.1. I do not agree with that example, showing
a separate interface-oper table.  That is not needed.
Just add a leaf to the interface entry to identify it as 'active'.
This is a contrived example.

3.2)  I do not agree that operational state needs to be edited directly
by the client.  I actually think the custom RPC approach in the
example in 3.2.1 is better and more clear within the model.
Editing config=false nodes is a fundamental change to the
NETCONF/YANG architecture and it should not be done.

Actions like <add-route> and <delete-route> properly model
the API between client and server, not <edit-operational>.

> /martin & lada

Andy

>
>
>
>
> ---------- Forwarded message ----------
> Subject: New Version Notification for
> draft-bjorklund-netmod-operational-00.txt
>
> URL:
> http://www.ietf.org/internet-drafts/draft-bjorklund-netmod-operational-00.txt
> Status:
> http://datatracker.ietf.org/doc/draft-bjorklund-netmod-operational
> Htmlized:
> http://tools.ietf.org/html/draft-bjorklund-netmod-operational-00
>
>
> Abstract:
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 05 Oct 2012 17:49:28 +0200

> Just add a leaf to the interface entry to identify it as 'active'.

Who is supposed to add such a leaf - the server? And how can the client learn about the existence of inactive interfaces? 

> NETCONF/YANG architecture and it should not be done.

But this is exactly what the IRS and SCIM (and maybe other) folks are about to do.
  
> the API between client and server, not <edit-operational>.

The means for modelling RPCs are very limited - the semantics has to be told in prose.
This is exactly why REST is superior to all kinds of RPC-based APIs.

Lada

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

---

From: Andy Bierman <[email-masked]>
Date: Fri, 5 Oct 2012 09:24:10 -0700

On Fri, Oct 5, 2012 at 8:49 AM, Ladislav Lhotka <[email-masked]> wrote:

> Who is supposed to add such a leaf - the server? And how can the client
> learn about the existence of inactive interfaces?
>

The data modeler writing the YANG module should add the leaf.

> But this is exactly what the IRS and SCIM (and maybe other) folks are

They haven't decided what to do yet AFAIK.
IRS hasn't even had a BOF yet, let alone a WG.
I suspect they will create an API, not a data model
that is edited like configuration.  We don't need
to change N/Y based on speculation about what IRS WG
will choose for a solution.

> This is exactly why REST is superior to all kinds of RPC-based APIs.

IMO operational state is a representation of internal device state.
It may be very implementation-specific how the operational state
can be edited.

The use-cases where operational state is injected or altered
are very limited.  We already have a solution that works for
these corner cases (custom RPCs).

Your draft returns config=true nodes in <get-operational>,
like duplex=auto vs. duplex=full.  IMO these corner cases
do not show up that often, and the old solution of
separate admin-status and oper-status is good enough.
Returning config=true nodes in <get-operational>
requires a new YANG extension and server customization
to support it.

The validation/constraints/transaction model in NETCONF
should be limited to config=true nodes.  Operational nodes
change too fast and are too distributed to justify adding
editing capabilities for config=false nodes.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Sat, 06 Oct 2012 11:17:18 +0200

> The data modeler writing the YANG module should add the leaf.

I mean: who is supposed to set the value of the "active" leaf - the server or client? But my second question is more important: how does the client learn about an existing interface that's not in the configuration?
 
> will choose for a solution.

This was just examples. The thing is, some applications and devices don't need the comfort (and overhead) of NETCONF. If I want to temporarily switch off forwarding on a Linux box, I simply set /proc/sys/net/ipv4/ip_forward to zero.

While you may argue that creators of new configuration APIs are doomed to reinvent the NETCONF wheels, I don't think it always has to be the case.

Our draft is also intended to enable coexistence of NETCONF with other management interfaces, and the operational state datastore (rather than NETCONF configuration datastores) is supposed to be the common playground.  

> editing capabilities for config=false nodes.

Even then operational nodes have to satisfy some constraints that must be common to all management interfaces and/or protocols that work with the data, and often constraints on config data also involve operational data.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Sun, 7 Oct 2012 06:09:26 -0700

On Sat, Oct 6, 2012 at 2:17 AM, Ladislav Lhotka <[email-masked]> wrote:

> I mean: who is supposed to set the value of the "active" leaf - the server
> or client? But my second question is more important: how does the client
> learn about an existing interface that's not in the configuration?
>
>

I meant the server sets it.
Your problem statement does not mention client pre-provisioning of
config data or disabling config data.  These are still unsolved problems
in NETCONF.

> This was just examples. The thing is, some applications and devices don't
> need the comfort (and overhead) of NETCONF. If I want to temporarily switch
> off forwarding on a Linux box, I simply set /proc/sys/net/ipv4/ip_forward
> to zero.
>

I don't agree that NETCONF should have editable state.
You can mess up a Linux system hacking on /proc.
I do not want to add a hack or a full-blown validation system
for editing config=false nodes.

In your duplex example, let's say it is set to 'auto'
and negotiates to 'half'.  Then I <edit-operational> the
value to be 'full'.

Now config says 'auto' and state says 'full'.
How does every other operator know that I did that?
To them it looks like the auto-negotiated value is 'full' but it is not.

> While you may argue that creators of new configuration APIs are doomed to
> reinvent the NETCONF wheels, I don't think it always has to be the case.
>
> Our draft is also intended to enable coexistence of NETCONF with other
> management interfaces, and the operational state datastore (rather than
> NETCONF configuration datastores) is supposed to be the common playground.
>
> >
> >
> >
> >>
> >> >
> Even then operational nodes have to satisfy some constraints that must be
> common to all management interfaces and/or protocols that work with the
> data, and often constraints on config data also involve operational data.
>
> Lada
>
> >
> >
>

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 07 Oct 2012 21:45:18 +0200 (CEST)

Hi Andy,

Andy Bierman <[email-masked]> wrote:
> separately is is real problem

We have this problem for interfaces, ip, and routing.  If this is not
a problem, maybe you can suggest a solution for these drafts?

For example, in interface, there is no way to report status for
interfaces that are not configured by the operator, since these config
false nodes are defined in a config true list.  It seems you are
saying that data model duplication is not a problem, so I assume your
proposal is to have two separate top-level containers, the current
"interfaces" and a new one "interfaces-state" or something?  And then
two separate "interface" lists, one in each container?  Is this
correct?

> or that it is counter-intuitive
> to operators.

It is counter-intuitive to data model designers.  For example, the
ipfix module mixes config false under config true nodes.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sun, 7 Oct 2012 13:28:24 -0700

> a problem, maybe you can suggest a solution for these drafts?
I think the server knows if a config entry is pre-provisioned,
disabled, or active, etc.. This is built into the implementation.

I like the idea of a meta-data tag (XML attribute) to identify
the config-state, to be used as a sub-filter on config=true,
and returned by the <get2> operation, like with-timestamps.
e.g.:

  // get only the disabled config in running db
  <get2>
     <config-state>disabled</config-state>
  </get2>

  // get all the config-state tags in running db
  <get2>
     <with-config-state />
  </get2>

> ipfix module mixes config false under config true nodes.
So?  This is fine if the counters only exist under a list subtree
when that list instance exists.  I don't agree that some config
for an interface that is not present is somehow operational state.
It is config is the 'pre-provision' or 'disabled' state.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 08 Oct 2012 10:33:41 +0200 (CEST)

> disabled, or active, etc.. This is built into the implementation.

The problem is not the server, but the client.  pre-provisioning can
be dealt with if the data model designer thought about it.  For
example, the data model designer can add a "operational-status" leaf
for objects that he believes can be pre-provisioned.  This way, the
client can learn which things are configured, but not in operational
use.  But this only works if the data model designer was clever enough
to realize this need in advance.

However, this approach does not work if there are objects that appears
operationally but are not (yet) configured.  It seems you are
suggesting that you have a solution to this, so could you please

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 08 Oct 2012 11:10:45 +0200

> I meant the server sets it.

The concept of the server writing something to the configuration is not supported by the existing specs and IMO it is a non-starter. So you should write a draft defining the rules for this. 

In our draft, configuration contains only stuff explicitly written by client(s). The server writes the data about pre-provisioned object to the operational state datastore.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Mon, 8 Oct 2012 02:53:22 -0700

On Mon, Oct 8, 2012 at 2:10 AM, Ladislav Lhotka <[email-masked]> wrote:

> The concept of the server writing something to the configuration is not
> supported by the existing specs and IMO it is a non-starter. So you should
> write a draft defining the rules for this.
>

The concept of returning config=true nodes as operational data and the
concept of
editing config=false nodes does not exist in NETCONF/YANG and it should
stay that way.
I don't agree with any of your problem statements so of course I don't think
we need your solution either.

If the WG wants to support pre-provisioned config or disabled config,
then a new charter item for that should be proposed.  I am not interested
in this problem enough to write a draft about it.

Client provided config that is not currently in use is not operational
state.

The client cannot set server operational state.  It can perform actions
which have side effects that change server operational state.

> In our draft, configuration contains only stuff explicitly written by
> client(s). The server writes the data about pre-provisioned object to the
> operational state datastore.
>

This is not the way real servers work.
There are PHY interfaces and other top level containers that
the server will create in the factory default config.

Andy

> >> >> The means for modelling RPCs are very limited - the semantics has to
> be
> >> >> told in prose.
> >> >> >>    context of YANG and the Network Configuration Protocol
> (NETCONF).
> >>  It

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 8 Oct 2012 13:21:14 +0200

On Oct 8, 2012, at 11:53 AM, Andy Bierman <[email-masked]> wrote:

> The concept of returning config=true nodes as operational data and the concept of
> editing config=false nodes does not exist in NETCONF/YANG and it should stay that way.

config=true nodes (e.g., an IP address) become operational state data as soon as the server decides to use them for its operation. We wanted to avoid the duplication of nodes, so that's why the pair of the related config and OS values is modelled as a single node.

> in this problem enough to write a draft about it.

The WG has already agreed that the issues of operational state versus configuration would be investigated. I believe the issues are real and not contrived.

> 
> Client provided config that is not currently in use is not operational state.

For sure it isn't, and we didn't say it was. Such a config is present in the configuration datastore but it is ignored by the server.

> which have side effects that change server operational state.

And vice versa: the server cannot write operational state data to client's configuration.
It all depends on how we define the terms. The long-term problem of NETCONF is that terms like configuration or operational state data can be (and are) understood in different ways by different people and vendors. Maybe it was originally considered a feature but I think it's a bug.

> the server will create in the factory default config.

I suppose such items then cannot be deleted by the client, contrary to the rules for the configuration datastore.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Mon, 8 Oct 2012 08:33:11 -0700

On Mon, Oct 8, 2012 at 4:21 AM, Ladislav Lhotka <[email-masked]> wrote:

> > >> >> > On Fri, Oct 5, 2012 at 1:28 AM, Martin Bjorklund <[email-masked]
> >
> > >> wrote:
> > >> >> >
> > >> >> >> Hi,
> > >> >> >>
> config=true nodes (e.g., an IP address) become operational state data as
> soon as the server decides to use them for its operation. We wanted to
> avoid the duplication of nodes, so that's why the pair of the related
> config and OS values is modelled as a single node.
>
>
No, config=true nodes don't become operational data.
There may be some operational data that is changed as a result
of a config change or some action operation.

The problem of dual-mode objects is a very tiny corner-case,
which has been solved in the real world using an 'admin' leaf and an
operational leaf.

A nice-to-have feature would be complete management of
config state to support pre-provisioning and disabled config,
but that is not the problem you are trying to solve.

Maybe somebody else has read the draft and has a different opinion.

Andy

> The WG has already agreed that the issues of operational state versus
> configuration would be investigated. I believe the issues are real and not
> contrived.
>
> >
> For sure it isn't, and we didn't say it was. Such a config is present in
> the configuration datastore but it is ignored by the server.
>
> >
> It all depends on how we define the terms. The long-term problem of
> NETCONF is that terms like configuration or operational state data can be
> (and are) understood in different ways by different people and vendors.
> Maybe it was originally considered a feature but I think it's a bug.
>
> >
> >
> >
> > >> >> But this is exactly what the IRS and SCIM (and maybe other) folks
> are
> > >> >> about to do.
> > >> >>
> > >> >
> > >> >
> > >> >> The means for modelling RPCs are very limited - the semantics has
> to be
> > >> >> told in prose.

---

From: "Muthumayan Madhayyan (muthu)" <[email-masked]>
Date: Tue, 23 Oct 2012 19:03:28 +0000

Hi Martin,

Seems like a good start for modeling writeable operational data.

A few comments on the I-D:

  *   Terminology: The term 'operational state' has typically referred to read-only type of information. Here the intent is to make this an 'editable state data' .
     *   Read-only data in YANG is denoted by 'config false' statement on those nodes.
     *   Operational data stores could contain both read-only and read-write nodes. So, just using 'config false' may not suffice. Unfortunately, 'config' can take only true or false argument. So, nodes in operational data stores have to use 'config false'.
     *   Now to make those nodes 'writeable', adding another keyword like oper: writeable makes sense.
     *   However, I have a question here:  There could be two different use-cases:
        *   A node to be writeable both in the configuration store and the operational-datastore (obviously with different values).  Ex: Configured value of MTU overridden by operational MTU on an interface.
        *   Different instances of the same node where one instance works off the configuration store and the other from the ODS. Ex: Some interfaces working off the configured MTU, while others work off either the default or ODS. This is similar to the example of route table modification in 3.2.1.
        *   Can the same node have both 'config true' and 'oper: writeable' attributes ?  I presume not.
  *   4.2:  This seems to suggest that there is a standalone operational datastore whose contents may be derived from the configuration datastore. Why is it a required to have the operational datastore tied to a configuration datastore ? There may be cases that would require just an operational datastore that is independent of configuration datastore.

- muthu

On 10/5/12 1:28 AM, "Martin Bjorklund" <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

/martin & lada

---

From: Andy Bierman <[email-masked]>
Date: Tue, 23 Oct 2012 17:19:34 -0700

Hi,

IMO, there are many problems with editing operational state.

There are security concerns wrt/ data injection attacks.
Does the server have to validate an operational datastore
with YANG constraints like must-stmt and min-elements?
Do any servers in existence today actually validate operational state
in any way?  Without validation, there increased vulnerabilities introduced.

Since there is no 'candidate' config for editing operational
state, there are ordering issues (similar to writing directly
to running config).  The server may not allow arbitrary edits
in arbitrary order for operational state.  This seems very difficult
to standardize.  There is no all-or-nothing transaction capability
that the candidate config provides, so partial errors can leave
the system in an unstable state.

IMO, the <edit-operational> design is too unconstrained,
and multi-vendor interopability would be much easier
to achieve with custom operations like <inject-route>
that require certain parameters to be presented together,
and the expected changes to the system behavior clearly documented.

Andy

On Tue, Oct 23, 2012 at 12:03 PM, Muthumayan Madhayyan (muthu) <
[email-masked]> wrote:

>    - Terminology: The term 'operational state' has typically referred to
>    read-only type of information. Here the intent is to make this an 'editable
>    state data' .
>       - Read-only data in YANG is denoted by 'config false' statement on
>       those nodes.
>       - Operational data stores could contain both read-only and
>       read-write nodes. So, just using 'config false' may not suffice.
>       Unfortunately, 'config' can take only true or false argument. So, nodes in
>       operational data stores have to use 'config false'.
>       - Now to make those nodes 'writeable', adding another keyword like
>       oper: writeable makes sense.
>       - However, I have a question here:  There could be two different
>       use-cases:
>          - A node to be writeable both in the configuration store and the
>          operational-datastore (obviously with different values).  Ex: Configured
>          value of MTU overridden by operational MTU on an interface.
>          - Different instances of the same node where one instance works
>          off the configuration store and the other from the ODS. Ex: Some interfaces
>          working off the configured MTU, while others work off either the default or
>          ODS. This is similar to the example of route table modification in 3.2.1.
>          - Can the same node have both 'config true' and 'oper:
>          writeable' attributes ?  I presume not.
>        - 4.2:  This seems to suggest that there is a standalone
>    operational datastore whose contents may be derived from the configuration
>    datastore. Why is it a required to have the operational datastore tied to a
>    configuration datastore ? There may be cases that would require just an
>    operational datastore that is independent of configuration datastore.
>
>
>
>  - muthu
>
>  On 10/5/12 1:28 AM, "Martin Bjorklund" <[email-masked]> wrote:
>
>  Hi,
>

---

From: Andy Bierman <[email-masked]>
Date: Tue, 23 Oct 2012 19:52:11 -0700

IMO the most interesting aspect of this draft is the configuration
pre-provisioning mentioned
in the example in 3.1.1.  I agree that NETCONF should support it somehow.
I do agree that config provided by the client for HW not present is
operational state
instead of config is a "pre-provisioned" state.

There is another important corner-case related to operational state not
mentioned
in the draft, which is config=true operational state nodes.  These are
containers
or lists that only the server can create -- e.g., the PHY interface list
from the kernel.
There is no standard way in YANG to say that the client can only edit
descendant nodes
of this config=true node.  These nodes have to be saved in the NV-config
because
they are the parent nodes for all the client config.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 23 Oct 2012 19:59:17 -0700

> I do agree that config provided by the client for HW not present is
         ^ not

I would also throw in client-disabled configuration an an important
use-case to support.
I think of this as config in a different state than "active", not
operational state.

Andy

>>          - A node to be writeable both in the configuration store and
>>          the operational-datastore (obviously with different values).  Ex:
>>          Configured value of MTU overridden by operational MTU on an interface.

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 24 Oct 2012 09:44:16 +0200 (CEST)

Hi,

"Muthumayan Madhayyan (muthu)" <[email-masked]> wrote:
>   * Terminology: The term 'operational state' has typically referred to
>     read-only type of information. Here the intent is to make this an
>     'editable state data' . 

When you say that the operational state is read-only, you probably
mean read-only through the management interface?  The operational
state changes all the time, obviously.

Even today the operational state is indirectly changed through the
management protocol when the configuration is changed (depending on
the type of change of course).

It seems there are use cases for modififying the operational state
directly, for example in IRS they want to modify the routing table.

So the question is how can we change the operational state through the
management protocol?

>From a logical point of view, it doesn't really matter if the
operational state is modified directly by a generic rpc like
'edit-operational' or by special rpc 'inject-route', 'edit-route',
'delete-route' etc.

As noted in the draft, this idea of 'edit-operational' is 

>       + Read-only data in YANG is denoted by 'config false' statement on those
>         nodes. 
>       + Operational data stores could contain both read-only and read-write
>         nodes. So, just using 'config false' may not suffice. Unfortunately,
>         'config' can take only true or false argument. So, nodes in
>       + Now to make those nodes 'writeable', adding another keyword like oper:
>         writeable makes sense.
>       + However, I have a question here:  There could be two different
>         use-cases:
>           o A node to be writeable both in the configuration store and the
>             operational-datastore (obviously with different values).  Ex:
>           o Different instances of the same node where one instance works off
>             the configuration store and the other from the ODS. Ex: Some
>             interfaces working off the configured MTU, while others work off
>             either the default or ODS. This is similar to the example of route
>             table modification in 3.2.1.
>           o Can the same node have both 'config true' and 'oper: writeable'
>             attributes ?  I presume not.  

Probably not.  You can run into the same problem today if you define
something like this:

  leaf foo-address {
    config true;
    ...
  }

  rpc set-foo-address {
    description
      "directly sets the foo-address in the operational state";
    input {
      leaf address {
        ...
      }
    }
  }

>   * 4.2:  This seems to suggest that there is a standalone operational
>     datastore

Yes, conceptually.  In real implementations this "datastore" probably
is built on the fly as needed, by using callbacks into the application.

> whose contents may be derived from the configuration datastore.
>     Why is it a required to have the operational datastore tied to a

Most configuration parameters affect the operational behaviour of the
device.  So when the running config is modified, the applications pick
up the changes and changes its behaviours accordingly, thus changing
the operational state.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 24 Oct 2012 09:56:31 +0200 (CEST)

> As noted in the draft, this idea of 'edit-operational' is 

I meant to write:

As noted in the draft, this idea of 'edit-operational' is not
finished.  We need to have more discussions about this.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 24 Oct 2012 13:32:13 +0200 (CEST)

> There are security concerns wrt/ data injection attacks.

Actually, this is can be controlled on a more fine-grained level (with
NACM) if the state is edited by a generic operation.  If you have a
specific operation like 'inject-route' you can only permit/deny the
operation itself, you cannot check parameters to the rpc.

> with YANG constraints like must-stmt and min-elements?

No, I don't think this makes sense.

> in any way?  Without validation, there increased vulnerabilities introduced.

This is true also for special rpcs.

> to running config).

I think ordering is a bigger problem for special rpcs.  With a generic
edit-operational, the client can send all data in one go.  With
special rpcs it has to split the data into a bunch of special rpcs and
send them *in the correct order*.

> The server may not allow arbitrary edits

This is not better than if you do a bunch of special rpcs, and the 4th
fails.

> IMO, the <edit-operational> design is too unconstrained,

Yes, I agree that this can be a drawback with this design.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 24 Oct 2012 13:37:57 +0200 (CEST)

> instead of config is a "pre-provisioned" state.

I think you meant "I do not agree...".

Well, neither do I.  I don't think anyone said that pre-provisioned
config is operational state.

> they are the parent nodes for all the client config.

This is a different topic, but super simple to solve:  The server
should not mess with the config at all.  No magic handling of physical
interfaces.  (they can be present as initial "factory created" config
though).

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 24 Oct 2012 08:14:17 -0700

> interfaces.  (they can be present as initial "factory created" config

A factory-created config node that the client cannot change in anyway,
that gets saved in NV-storage as part of the config, is a special type
of node.  Even if the client could delete it, the server would add it right
back,
so what's the point?

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 24 Oct 2012 08:20:57 -0700

> operation itself, you cannot check parameters to the rpc.
IMO this is simpler.  You don't really need to allow/deny
based on individual parameters, just the acrtion.

> No, I don't think this makes sense.
Without it there are even more security concerns.
Yet operational data can change a million times a second,
way faster than config chances.  Doing validation would
be so expensive nobody could implement it.

> This is true also for special rpcs.
No it is not -- all the CLI commands I have seen to alter system behavior
have been specialized commands.  There is no generic 'configure' command
for arbitrary operational nodes.

> send them *in the correct order*.
No -- poking data into the running state is way worse than
forcing all related parameters for a particular task to be present at once.

> This is not better than if you do a bunch of special rpcs, and the 4th
Not if the special RPCs are designed correctly so they are independent.
If you need 4 RPCs to make 1 change, then we are back to the
writable-running vs. candidate problem, and custom RPCs are the
same as <edit-operational> in this case.

Andy

---

From: Xiang Li <[email-masked]>
Date: Thu, 25 Oct 2012 19:17:25 -0500

Hi

I have read this draft. I think it's a good draft since it helped me a lot understand the various issues with this "Operational state data". Just a few quick comments for now.

1. Terminology:

The draft's title uses "Operational Data", but then later it defines "operational state data". I assume they are same thing and they probably should be made consistent.

Similarly, both "operational data store" and "operational state datastore" are used in the draft.

The objectives of the draft mention "to develop a general model applicable not only to NETCONF but also to   other approaches (RESTful, editable state data etc.)". What's the difference between "editable state data" and "operational state data"? Or they are same thing?

2. Section 1.1.1 Terms: operational state data: The data in the operational state  datastore.

I think this definition is too vague. I think you might want to add something like the definition  available from RFC6244:

-Operational state data is a set of data that has been obtained by  the system at runtime and influences the system's behavior similar to configuration data. In contrast to configuration data,  operational state is transient and modified by interactions with  internal components or other systems via specialized protocols.

In general, the problem statement in this draft can be made clearer by including some background information,. For example, "Configuration data", "Operational state data", and "Statistical data"., and NETCONF's "config data" and 'state data" etc.  in RFC6244.

I think the terminology is rather important here since they are not something a lot of us already familiar.

3. In section 3.1.1 Interface list  example,  there is a sentence reads "The counter is operational state data." . I think it would help to explain a bit why is that? Most people would probably feel confused here since we all know "counter" is statistical data.

4 In appendix C. Example Admin vs Oper state. I thought this draft is going to solve the schema duplication even for this scenario. Looks like that's not the case.

It would help if the draft explains a bit why the "schema duplication" in this case is not a concern?

--Xiang

-- 
--
Xiang Li
Web: www.seguesoft.com
Voice: 1 (872) 216-2610