Discussion:
[core] comi and NMDA (configuration and operational state datastore)
Juergen Schoenwaelder
2017-07-20 08:33:13 UTC
Permalink
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/>
Andy Bierman
2017-07-20 09:44:13 UTC
Permalink
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 <
Post by Juergen Schoenwaelder
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/>
_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core
Juergen Schoenwaelder
2017-07-20 09:47:18 UTC
Permalink
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
Post by Andy Bierman
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 <
Post by Juergen Schoenwaelder
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/>
_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core
--
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/>
Andy Bierman
2017-07-21 01:57:32 UTC
Permalink
On Thu, Jul 20, 2017 at 2:47 AM, Juergen Schoenwaelder <
Post by Juergen Schoenwaelder
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.
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.
Post by Juergen Schoenwaelder
/js
Andy
Post by Juergen Schoenwaelder
Post by Andy Bierman
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 <
Post by Juergen Schoenwaelder
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/>
_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core
--
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/>
Juergen Schoenwaelder
2017-07-21 09:35:59 UTC
Permalink
Post by Andy Bierman
On Thu, Jul 20, 2017 at 2:47 AM, Juergen Schoenwaelder <
Post by Juergen Schoenwaelder
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.
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.
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
--
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/>
Michel Veillette
2017-07-21 05:45:23 UTC
Permalink
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:core-***@ietf.org] On Behalf Of Juergen Schoenwaelder
Sent: Thursday, July 20, 2017 10:33 AM
To: ***@ietf.org
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
--
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/>
Loading...