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

On 3/26/19 17:04, Alex Campbell wrote:
> As I understand it,the only purpose for the candidate and startup datastores is to indirectly set the contents of the running datastore.
> 
> Therefore it wouldn't make sense to have different factory defaults for the running, startup and candidate datastores. And those are the only writable ones.
> 
> Joe, which other datastores were you thinking of?

Again, this is likely vendor-dependent.  I was thinking of additional
system datastores that would also need to be reset to default for a full
device reset.  This is why I like the "reset-device" RPC, which would
take care of any such DS.

As a concrete example, Cisco switches have a vlan.dat file that is not
part of <running> or <startup> that would need to be reset to factory to
fully reset the device.

Joe

> 
> Alex
> 
> 
> ________________________________________
> From: netmod <netmod-bounces@ietf.org> on behalf of joel jaeggli <joelja@bogus.com>
> Sent: Tuesday, 26 March 2019 8:18 p.m.
> To: Joe Clarke; netmod@ietf.org
> Subject: Re: [netmod] Question on draft-wu-netmod-factory-default
> 
> On 3/25/19 07:14, 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?
> 
> the germ of the idea is sensible enough. reset a DS to it's factory state.
> 
> When it meets reality of course is that there seem to be a bunch of
> variants that seem like pretty compelling use cases.
> 
> reset the whole device being one of them.
> 
> the specification of a factory-default datastore and then
> 
>    o  startup configuration datastore
> 
>    o  candiate configuration datastore
> 
>    o  running configuration datastore
> 
> actually sound a bit implementation specific though I recognize that
> most network operating systems due tend to follow models that at least
> superficially resembled that.
> 
> I'm generally sympathetic to the application the draft proposes.
> 
>>
>> Joe
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
> 
> 