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

[Juergen Schoenwaelder <[e-mail]>]

On Thu, Jul 20, 2017 at 06:57:32PM -0700, Andy Bierman wrote:
> On Thu, Jul 20, 2017 at 2:47 AM, Juergen Schoenwaelder <
> [e-mail]> wrote:
> 
> > 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: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <http://www.jacobs-university.de/>