Re: [netmod] Question on draft-wu-netmod-factory-default

[Qin Wu <[e-mail]>]

Hi,Jurgen:

-----邮件原件-----
发件人: netmod [mailto:[e-mail]] 代表 Juergen Schoenwaelder
发送时间: 2019年3月25日 23:31
收件人: Joe Clarke <[e-mail]>
抄送: [e-mail]
主题: 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>

_______________________________________________
netmod mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/netmod