Currently NCMP defines specific (supported) parameters for the passthrough endpoints

/v1/ch/{cm-handle}/data/ds/ncmp-datastore:passthrough-operational/{resourceIdentifier}
/v1/ch/{cm-handle}/data/ds/ncmp-datastore:passthrough-running/{resourceIdentifier}

parameters:
  - $ref: 'components.yaml#/components/parameters/cmHandleInPath'
  - $ref: 'components.yaml#/components/parameters/resourceIdentifierInPath'
  - $ref: 'components.yaml#/components/parameters/acceptParamInHeader'
  - $ref: 'components.yaml#/components/parameters/fieldsParamInQuery'
  - $ref: 'components.yaml#/components/parameters/depthParamInQuery'

This mean NCMP is not acting as a simply proxy as intended but has knowledge about the (ONAP) DMI Plugin ie. that it uses RESTConf to talk to the nodes it manages

However NCMP should be agnostic of underlying  interpretation of resourcePath and query parameters

as defined in the analysis: https://wiki.onap.org/display/DW/CPS-391Spike%3A+Define+and+Agree+NCMP+REST+Interface#CPS391Spike:DefineandAgreeNCMPRESTInterface-NCMPURI

in other word the 'query' part of the incoming URI should NOT be broken down any any combinations of zero or more parameters should be accepted and forwarded as is to the DMI Plugin.

in other words all below URLs are valid and should be forwarded to DMI:

/v1/ch/node1/data/ds/ncmp-datastore:passthrough-operational/turing-machine:turing-machine?fields=transition-function/delta&depth=4
/v1/ch/node1/data/ds/ncmp-datastore:passthrough-operational/turing-machine:turing-machine?someOtherOption=A&fields=transition-function/delta&depth=4
/v1/ch/node1/data/ds/ncmp-datastore:passthrough-operational/somePropietaryId?somePropietaryOption1=Z&somePropietaryOption2=Y&somePropietaryOption3=X

The bug affects the DMI REST Interface in the same way although it could be argued that the (ONAP) DMI Plugin does known about and only support whatever RESTConf supports (but not limited to depth an field options!) However if the DMI plugin also acts as a simpel proxy (for SDN-C) it would have several advantages

1. Added values as it would support ANY option support by SDNC/RESTConf stack
2. Interface Consistency
3. Simplicity

For more details see analysis here: https://wiki.onap.org/pages/viewpage.action?pageId=111120893

In summary the fix for this bug should:

1. Update NCMP REST interface as per original proposal supporting any number of any query parameters
2. Update DMI Plugin interface supporting any number of any query parameters
3. Forward all query parameters to SDN-C without intervention/checks in DMI Plugin
   1. This should be demo-ed using full stack possibly using some logging
4. URLs should be backward compatible with current implementation.
   This is no longer the case as it has been agreed that 'dept' and 'fields' paarmeter should no longer be declared in this fashion but as 'options' instead. See decisision #2 on https://wiki.onap.org/pages/viewpage.action?pageId=111120893
5. 'options' can be applied to both read and write passthrough operations
6. DMI Plugin needs to pass on the same options for read and write use-cases (no need to validate etc.) as normal query parameters