• Get the latest study information from Kieran Mccarthy <kieran.a.mccarthy@ericsson.com>
• Create a Wiki page with a clear diagram showing NCM and DMI and its interfaces detailing the scope of THIS (and other) spike
• Update V1 of the interface (communicate with E2E Slicing)
• Detail CRUD operations
• Detail Patch 
• Include datastore options (pass-through) 
• Agree on parameter names and use them consistently
• Agree on JSON output format 
• Resource 'path' can cover cps-paths, rest-conf path (for pass-through), and any proprietary paths
• Only 'hint' at 
  • async options
  • bulk operations

A/C

• Wiki page detailing points above
• Share an agreement with the team
• Present at community

Out of scope

• actual YAML definitions (separate user story)

Open Issues & Decisions

Principles

1. Follow principles/patterns of RESTCONF RFC-8040
2. Follow principles/patterns of yang-patch RFC-8072
3. Follow principles/patterns of RESTCONF NMDA RFC-8527

RESTCONF/NETCONF relationship

NCMP URI

NCMP URI format to follow below pattern

<OP>    ncmp / <v{v-number}> / cm-handle /<cmhandle> /<data|operations|{ncmp-action}> /ds/{datastore} / <resource-path> ? <query>

where:

<OP> : the HTTP method

<ncmp> : the ncmp root resource

<v{v-number}> : version of the ncmp interface <path> is the target resource URI <query> is the query

parameter list

<request-category> : yang data, rpc operation or a (non-modelled) ncmp api action

<datastore> : optional datastore

<cmhandle> : unique (string) identifier of a yang tree instance.

<resource-path> : the path expression identifying the resource that is being accessed by the operation. If this field is not present, then the target resource is the API itself.

<query> : the set of parameters associated with the RESTCONF message; see Section 3.4 of [RFC3986]. RESTCONF parameters have the

familiar form of "name=value" pairs. Most query parameters are optional to implement by the server and optional to use by the client. Each optional query parameter is identified by a URI

Datastores

New datastores are defined for ncmp to access the CPS 'intended' or 'operational' datastore.

Alternatively, the request can be sent directly to the 'device' itself (bypassing CPS datastores) using one of the 'passthrough-*' datastores options as below

The new ncmp datastores required for ONAP Release I include :

Future datastores to be supported by NCMP include :

If datastore (ds/{datastore}) is omitted from URI AND the model/moduleSet is not available in NCMP, the datastore is defaulted to ncmp-datastores: passthrough-running

If datastore (ds/{datastore}) is omitted from URI AND the model/moduleSet exists, the datastore is defaulted to ncmp-datastores:running

Yang data resource actions and RPC operations are run directly on the 'device' meaning ncmp-datastores:passthrough-running is used for these request