On 2/12/2018 11:47 AM, Juergen Schoenwaelder wrote:
On Mon, Feb 12, 2018 at 10:49:48AM +0100, Balazs Lengyel wrote:
IMHO once we know whether the data is config=false or true and know the
datastores the server supports the datastore the instance data is relevant
to is fixed. One exception is the possible loading of dynamic datastores.
However as I do not have a use-case for these and we do not have any
dynamic datastores defined, IMHO we can leave the usage of these
datastores out of scope. If I added the following paragraphs would that
"If the instance data specifies config false (state data) and the server
support the operational datastore, the instance data documents the
operational datastore. If the operational datastore is not supported the
data documents additional state data that is stored outside the
configuration datastores. The instance data MAY be used to load the
relevant datastore or it MAY just be used to document its content.
Having to guess the datastore from the instance data feels wrong to
me. It is not robust.
If the instance data specifies config true (configuration data) the
instance data documents the running datastore. The instance data MAY be
used to load the running datastore or it MAY just be used to document its
content. While the instance data format MAY be used to load other e.g.
dynamic datastores that is out of scope for this specification."
Also further clarification may be provided for each use-case in the
Why not make the data format robust? What speaks against indicating
explicitly to which datastore data belongs?
BALAZS: Sorry but where is the guessing?
The YANG model explicitly states whether data is config=false or true.
For config=true data it is always the running datastore
For config=false data it only depends on the NMDA support. E.g. the
yanglib model will be used on new and old servers too.
Also it is an explicit aim of the draft that we should allow mixing of
config=true and config=false data in the same instance data set.
Would you prefer that I add as metadata "ida:config-datastore=XXX" ?
Here XXX could be running or some dynamic (e.g. SDN) with default being
running. Or do you see any use case for documenting/loading candidate,
startup, intended or operational data for config=true ? If so please
Config=false data it will always go into operational or "other" in case
of a preNMDA server; so I don't see a need for any extra selector here.
Balazs Lengyel Ericsson Hungary Ltd.
Mobile: +36-70-330-7909 email: balazs.leng...@ericsson.com
netmod mailing list