Subject: [netmod] ietf-system: separate config and state conformance?

From: Andy Bierman <[email-masked]>
Date: Fri, 7 Jun 2013 09:45:27 -0700

Hi,

The state information within this module contains the system time of day.
Since the scope of the RFC is common system management,
no longer just system configuration, the RFC should be usable for
monitoring.  It is quite possible that small NETCONF devices
will not have the ability to set the hostname or provide time-of-day
management or system restart commands.  Yet it will still need
to report its notion of current time if an EMS is going to correlate
its data and notifications wrt/ timestamps and other devices.

There are limited conformance mechanisms in YANG to separate the
system-state
objects.  The WG needs to choose between:

  1) do nothing; leave draft as-is
  2 add a YANG feature (e.b. system-config) that covers all operations
      and config objects
  3) move the system-state objects to a new module in the same RFC

I would like to resolve this issue.
Am I the only one who is concerned that NETCONF devices
will not support the current-datetime object because module
conformance is too steep?

Moving the objects around within the same module is a different issue.
That is fine with me if the WG chooses (1).  It may be easier on
clients to retrieve just the non-config objects that way.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 10 Jun 2013 11:26:01 +0200

> clients to retrieve just the non-config objects that way.

Can people please comment on this so that we can move forward?

As technical contributor, I am fine with 1) - I think even the small
Contiki devices we experimented with would be fine supporting a reboot
operation etc.

/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: Martin Bjorklund <[email-masked]>
Date: Mon, 10 Jun 2013 15:01:38 +0200 (CEST)

Juergen Schoenwaelder <[email-masked]> wrote:
> As technical contributor, I am fine with 1)

So am I.

> I think even the small

The mandatory-to-implement nodes are (all if-feature nodes removed):

module: ietf-system
   +--rw system
      +--rw contact?          string
      +--rw hostname?         inet:domain-name
      +--rw location?         string
      +--ro platform
      |  +--ro os-name?      string
      |  +--ro os-release?   string
      |  +--ro os-version?   string
      |  +--ro machine?      string
      +--rw clock
      |  +--ro current-datetime?      yang:date-and-time
      |  +--ro boot-datetime?         yang:date-and-time
      |  +--rw (timezone)?
      |     +--:(timezone-utc-offset)
      |        +--rw timezone-utc-offset?   int16
      +--rw dns-resolver
         +--rw search*    inet:domain-name
         +--rw server* [name]
         |  +--rw name    string
         |  +--rw (transport)
         |     +--:(udp)
         |        +--rw udp
         |           +--rw address    inet:ip-address
         +--rw options
            +--rw timeout?    uint8
            +--rw attempts?   uint8

rpcs:
   +---x set-current-datetime    
   |  +--ro input     
   |     +--ro current-datetime    yang:date-and-time
   +---x system-restart          
   +---x system-shutdown         

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 10 Jun 2013 16:37:55 +0200

On Jun 7, 2013, at 6:45 PM, Andy Bierman <[email-masked]> wrote:

> There are limited conformance mechanisms in YANG to separate the system-state

Why cannot the "system-state" subtree be in the same module, as it is in interfaces-11? I believe a few other nodes also deserve to be both in configuration and state. For instance, the DNS resolver options can be obtained from DHCP, so the client should be able to learn them form operational state data.

Lada

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

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

---

From: Andy Bierman <[email-masked]>
Date: Mon, 10 Jun 2013 09:33:40 -0700

On Mon, Jun 10, 2013 at 7:37 AM, Ladislav Lhotka <[email-masked]> wrote:

> Why cannot the "system-state" subtree be in the same module, as it is in
> interfaces-11? I believe a few other nodes also deserve to be both in
> configuration and state. For instance, the DNS resolver options can be
> obtained from DHCP, so the client should be able to learn them form
> operational state data.
>
>

I did not list that option because it has no impact on module conformance.

I am OK with option (1).  The subtree filter needed to retrieve just a
few non-config nodes is not a burden on client developers, so moving them
to a new subtree in the same module is not really needed.  I think
the read-only objects would get implemented by vendors more quickly
if they were separate.

There were various proposals to indicate the DHCP vs. config property,
and they were are rejected.  I don't like the solution of duplicating
the config parameters in another tree to indicate they are in fact
the values in use.  IMO, this is meta-data and duplicating the data
is the wrong solution. A new <get2> or <get-operational> operation
is the right approach.

Lada

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 10 Jun 2013 20:13:11 +0200

> the values in use.  IMO, this is meta-data and duplicating the data

Mechanisms external to NETCONF cannot be expected to update anything in a NETCONF datastore, and the NETCONF server - if it is notified about a change - may not be able to do it either, e.g. because of a lock on the datastore. 

> is the wrong solution. A new <get2> or <get-operational> operation

I don't think we've got anywhere close to a consensus wrt to get-operational.

Lada

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 18 Jun 2013 10:05:36 +0200

> Mechanisms external to NETCONF cannot be expected to update anything in a NETCONF datastore, and the NETCONF server - if it is notified about a change - may not be able to do it either, e.g. becaus…
I always thought that the configuration datastore (not a netconf 
datastore) can be updated by many interfaces: Netconf, CLI, GUI, SNMP, 
the node itself, SON, etc.
AFAIK the Tailf implementation has a common datastore serving all 
interfaces.

IMHO after Call-Home get2 would be my next interest in Netconf, which 
could include get-informational.

Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
System Manager
ECN: 831 7320                        Tel: +36-1-437-7320
Mobile: +36-70-330-7909              email: [email-masked]

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 18 Jun 2013 10:26:43 +0200

Hi Balazs,

On Jun 18, 2013, at 10:05 AM, Balazs Lengyel <[email-masked]> wrote:

> I always thought that the configuration datastore (not a netconf datastore) can be updated by many interfaces: Netconf, CLI, GUI, SNMP, the node itself, SON, etc.
> AFAIK the Tailf implementation has a common datastore serving all interfaces.

If we talk about the NETCONF datastore(s), this could work only if all these interfaces behave as fully compliant NETCONF clients, because otherwise they may interfere with locks, commits, rollbacks etc. This is IMO quite difficult.

Of course, having another datastore as "writable operational state" is a different story. We can enable this concept by separating operational state data from (NETCONF) configuration, which has been recently done in the interfaces module.

Lada   

> 
> IMHO after Call-Home get2 would be my next interest in Netconf, which could include get-informational.
> 
> Balazs
> 
> --

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 18 Jun 2013 10:53:13 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> >> Mechanisms external to NETCONF cannot be expected to update anything
> >> in a NETCONF datastore, and the NETCONF server - if it is notified
> >> about a change - may not be able to do it either, e.g. because of a
> >> lock on the datastore.
> If we talk about the NETCONF datastore(s), this could work only if all
> these interfaces behave as fully compliant NETCONF clients, because
> otherwise they may interfere with locks, commits, rollbacks etc. This
> is IMO quite difficult.

This is what implementations do.  It would be extremely weird to have
*different* running configs in NETCONF and the CLI for example.  The
fact that they are shared are hinted at in RFC 6241, section 7.5:

      The <lock> operation allows the client to lock the
      entire configuration datastore system of a device.  Such locks are
      intended to be short-lived and allow a client to make a change
      without fear of interaction with other NETCONF clients, non-
      NETCONF clients (e.g., SNMP and command line interface (CLI)
      scripts), and human users.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 18 Jun 2013 10:58:36 +0200

>      scripts), and human users.

So what if the NETCONF server has a candidate datastore and non-writeable running? Are the alternative interfaces, such as SNMP, supposed to go through candidate and perform commits?

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 18 Jun 2013 10:59:32 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> So what if the NETCONF server has a candidate datastore and
> non-writeable running? Are the alternative interfaces, such as SNMP,
> supposed to go through candidate and perform commits?

Some implementations do this, and some might now allow SNMP write
access...

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 18 Jun 2013 11:41:56 +0200

On Jun 18, 2013, at 10:59 AM, Martin Bjorklund <[email-masked]> wrote:

> access…

Those that do it may easily run into well-known problems with shared candidate.

Lada