On 2/12/2018 11:47 AM, Juergen Schoenwaelder wrote:
On Mon, Feb 12, 2018 at 10:49:48AM +0100, Balazs Lengyel wrote:
    Hello Jurgen,

    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
    help?

    "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
    relevant document.
Why not make the data format robust? What speaks against indicating
explicitly to which datastore data belongs?

/js
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 describe.

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.

regards Balazs

--
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: balazs.leng...@ericsson.com

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to