Hi,Jurgen:
-----邮件原件-----
发件人: netmod [mailto:[email protected]] 代表 Juergen Schoenwaelder
发送时间: 2019年3月25日 23:31
收件人: Joe Clarke <[email protected]>
抄送: [email protected]
主题: Re: [netmod] Question on draft-wu-netmod-factory-default
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>?
[Qin]: This is close to what Andy is asking, we allow multiple target datastore
to be reset.
If so, if we have a <factory-default>, why is invoking <copy-config> not good
enough?
[Qin]: Netconf <copy-config> operation needs to be extended to allow it to
operate on the factory-default datastore.
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?
[Qin]: In normal copy-config operation, how do we source config inline is used
for factory default setting.
YANG instance data draft could provide generic solution for this. We add a
note to see if there is additional parameters that need to be added, will see
how to address this.
I do not really understand why one would need to have reset-datastore on
<candidate> - is <discard-changes> not good enough?
[Qin]: It doesn't allow you reset to <candidate> without changing <running>.
Please fix the 'target-datasore' typo or better change the parameter name to
just 'datastore'.
[Qin]: Okay,will figure out the right terminology.
Should there be text explaining how an implementation is supposed to deal with
errors or will these resets never fail?
[Qin]: Okay, will add text in the next version.
/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
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
