The I-D says:
o factory-default datastore: A read-only datastore holding a
preconfigured minimal initial configuration that can be used to
initialize the configuration of a server. The content of the
datastore is usually static, but MAY depend on external factors
like available HW.
The problem here is the phrase 'can be used to initialize the
configuration of a server'. In terms of the well-known NMDA
datastores, it is not clear whether the content is copied to <running>
or <startup> or both. Section 2 adds a bit more confusion since it
says:
Factory-default content SHALL be specified by one of the following
means in order of precedence
1. For the <running>, <candidate> and <startup> datastores as the
content of the <factory-default> datastore, if it exists
So do all these configuration datastores receive a 1:1 copy of
<factory-default>? If so, if we have a <factory-default>, why is
invoking <copy-config> not good enough?
2. YANG Instance Data [I-D.ietf-netmod-yang-instance-file-format]
How would this be done? I do not see anything in reset-datastores that
provides instance data. The copy-config operation already allows to
provide source config inline. Why do we need another way of doing the
same?
I do not really understand why one would need to have reset-datastore
on <candidate> - is <discard-changes> not good enough?
Please fix the 'target-datasore' typo or better change the parameter
name to just 'datastore'. Should there be text explaining how an
implementation is supposed to deal with errors or will these resets
never fail?
/js
On Mon, Mar 25, 2019 at 10:14:03AM -0400, Joe Clarke wrote:
> I support the need for being able to reset a DS to its factory default.
> However, I have a question on the current design of the model and the
> "factory-default" DS.
>
> It seems to me that this is a single DS that might have been intended to
> reset running or startup. However, what if I have different DSes that
> each have unique factory default data? If I choose to extend
> factory-default with a new identity of my other DS, how can I indicate
> that the target DS will be reset to _that_ DS? Does that make sense?
>
> Or if I do a <get-data> on a factory-default DS, how do I know what
> other DSes does this DS pertain? Perhaps the server will use this to
> reset a given DS, but how would a user know that (other than perhaps
> naming of the factory-default DS)?
>
> Maybe the module needs a mapping to let the client know what DS will be
> used to reset what other DS?
>
> Joe
>
> _______________________________________________
> netmod mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
