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

From: Joe Clarke <[email-masked]>
Date: Mon, 25 Mar 2019 10:14:03 -0400

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 25 Mar 2019 16:30:52 +0100

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:
> _______________________________________________
> netmod mailing list
> [email-masked]
> 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/>

---

From: joel jaeggli <[email-masked]>
Date: Tue, 26 Mar 2019 00:18:58 -0700

> 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.

---

From: Alex Campbell <[email-masked]>
Date: Tue, 26 Mar 2019 21:04:07 +0000

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?

Alex

________________________________________
From: netmod <[email-masked]> on behalf of joel jaeggli <[email-masked]>
Sent: Tuesday, 26 March 2019 8:18 p.m.
To: Joe Clarke; [email-masked]
Subject: Re: [netmod] Question on draft-wu-netmod-factory-default

---

From: Joe Clarke <[email-masked]>
Date: Tue, 26 Mar 2019 17:15:26 -0400

> 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