Subject: [core] comi and NMDA (configuration and operational state datastore)

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 20 Jul 2017 10:33:13 +0200

Hi,

are there plans to make draft-ietf-core-comi-00 support NMDA
(draft-ietf-netmod-revised-datastores-03)?

/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: Andy Bierman <[email-masked]>
Date: Thu, 20 Jul 2017 02:44:13 -0700

Hi,

I doubt this will be a primary feature of CoMI.
It is similar to RESTCONF, attempting to hide datastores from the client.
It also allows access to any RPC (just like RESTCONF operation resources)
so protocol operations that support NMDA can be supported.

Andy

On Thu, Jul 20, 2017 at 1:33 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 20 Jul 2017 11:47:18 +0200

Hi,

well, I am trying to understand what the scope of CoMI is. If CoMI is
only for ~100k memory devices, you may be right.

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 20 Jul 2017 18:57:32 -0700

> only for ~100k memory devices, you may be right.

IMO the NMDA stuff is only interesting if the device includes some sort of
dynamic configuration datastores (extremely unlikely). But in case I am
wrong,
CoMI provides full access to operation resources, so NETCONF operations
such as <edit-config> and <get-data> can be used if really needed.

A few obvious problems with using a multi-step editing process is that it
is not REST-full at all, it requires locking, it requires lock recovery
when the client goes away with outstanding locks, and it requires that
the client support lots of different server transaction models (i.e.,
just as heavyweight as NETCONF, but much harder without any session-based
interaction model).

We should be trying to make CoMI as simple as possible, not a binary
NETCONF.

Andy

---

From: Michel Veillette <[email-masked]>
Date: Fri, 21 Jul 2017 05:45:23 +0000

Hi Juergen

draft-ietf-core-comi-00 won't support NMDA directly but some of these concepts might be reused in a complementary draft. I see different use cases of using multiple datastores in IOT devices.
- The ability to support default configuration profiles
- The ability to support synchronized (scheduled) update between multiple devices
- The ability to roolback a configuration

If you remember the modem AT command set, this is equivalent to
AT&Wn (e.g. AT&W0 Save as user profile 0)
ATZn (e.g. ATZ0 Resets the modem and loads stored profile 0)

Interactions with these datastores can still be performed using RESTful operation (GET, PUT, POST, DELETE).

You are welcome to write such draft for CoMI if this subject is of interest to you.

Regards,
Michel

-----Original Message-----
From: core [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Thursday, July 20, 2017 10:33 AM
To: [email-masked]
Subject: [core] comi and NMDA (configuration and operational state datastore)

Hi,

are there plans to make draft-ietf-core-comi-00 support NMDA (draft-ietf-netmod-revised-datastores-03)?

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 21 Jul 2017 11:35:59 +0200

> We should be trying to make CoMI as simple as possible, not a binary
 
Exactly. You do not want to use NETCONF operations and hence be able
to expose multiple datastores as different resources, as proposed for
RESTCONF.

My point is that YANG data models move towards NMDA and hence having
<running> and <operational> exposed become an issue.  Well, if CoMI is
only for 100k devices, then probably not. The question for me really
is whether CoMI targets a very narrow target market (these ~100k
memory constrained devices) while embedded devices capable to run
embedded Unix flavours will simply do RESTCONF. (I personally believe
this is the most likely scenario; and I personally believe many of the
100k devices will likely do something like mud, i.e., pulling a config
from a server, and not expose a real management interface.)

If so, what is the market for CoMI? Perhaps CoMI has a market if
application data is communicated with it, i.e., a device pulls its
config etc from a server and afterwards ships application data that is
defined in YANG via CoMI (in which case CoMI is kind of a misnomer).

/js