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

From: Qin Wu <[email-masked]>
Date: Tue, 26 Mar 2019 05:25:45 +0000

Joe,

-----邮件原件-----
发件人: netmod [mailto:[email-masked]] 代表 Joe Clarke
发送时间: 2019年3月25日 22:14
收件人: [email-masked]
主题: [netmod] Question on draft-wu-netmod-factory-default

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? 

[Qin]:We start with a simple case, you case could be addressed by invoking multiple rpc with each rpc to allow reset a set of datastores.
 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?

[Qin]: In simple case, target DS will only be reset by a single factory datastore. If there is a new factory datastore could be derived from that DS, I think target DS should be changed to reset that new factory datastore.

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?
[Qin]: So your point is should we allow multiple source, multiple target in the same RPC, will think it over. Thanks.
Joe

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 26 Mar 2019 06:51:18 +0100

Qin,

the idea should be to make things simpler, not more complex. Perhaps
it is not necessary to expose N options to reset a device. Perhaps a
simple "factory-reset" RPC which resets all relevant datastores in an
implementation specific manner is sufficient. Why expose more details
to the management client?

/js

-- 
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: Joe Clarke <[email-masked]>
Date: Tue, 26 Mar 2019 03:12:26 -0400

> to the management client?

This would certainly make it simpler from the RPC standpoint.  However,
if one can <get-data> from the factory-default DSes, I still think there
is a need to know what factory-default DS maps to what other DS (in the
case where there might be multiple that are different).

Joe

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 26 Mar 2019 08:22:42 +0100

> case where there might be multiple that are different).

The notion of multiple factory-default datastores sounds complex. And
what is a management application going to do with them? How would a
management application know which sets of datastores to reset together
in a meaningful way?

My naive interpretation of the factory default DS (a single one) would
be that it exposes the content you will find in <running> after the
factory-reset has been executed. An extended version of Figure 2 of
RFC 8342 would look like this:

     +-------------+                 +-----------+        +-----------+
     | <candidate> |                 | <startup> |        | <factory> |
     |  (ct, rw)   |<---+       +--->| (ct, rw)  |        | (ct, ro)  |
     +-------------+    |       |    +-----------+        +-----------+
            |           |       |           |                   |
            |         +-----------+         |                   |
            +-------->| <running> |<--------+                   |
                      | (ct, rw)  |<----------------------------+
                      +-----------+

And exposing such a factory default datastore would be optional I
think.

/js

---

From: Joe Clarke <[email-masked]>
Date: Tue, 26 Mar 2019 03:37:45 -0400

> management application know which sets of datastores to reset together

This is why I think having a single RPC to "reset the device to factory"
makes sense.  Not to say that's the only use case, but it would be
useful in a number of cases.

> RFC 8342 would look like this:

Yep, this makes sense.  And I fully admit that my use case is likely
vendor-specific, but we may not be the only vendor with ancillary
datastores that do not look like <running> or <startup>.

Joe

---

From: Kent Watsen <[email-masked]>
Date: Tue, 26 Mar 2019 07:50:26 +0000

Sent from my iPhone

> On Mar 26, 2019, at 8:37 AM, Joe Clarke <[email-masked]> wrote:
> 

Correct.   This was requested by the WG last time it was presented, as there are other things that need to be reset besides YANG-modeled configuration.  Not only does such an RPC make sense, I will likely object a Last Call if it if such an RPC is missing. 

>> RFC 8342 would look like this:

The contents are, effectively, the first <startup> data store, as shipped from factory. 

Resetting other datastores to default needs discussion.  For all of the “conventional configuration datastores”, there’s likely just the one mentioned previously; each dynamic datastore might have its own notion of a factory default. 

Kent // contributor

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tue, 26 Mar 2019 09:22:25 +0000

+1 to Juergen's comments and diagram.

Thanks,
Rob

> -----Original Message-----
> From: netmod <[email-masked]> On Behalf Of Juergen
> Schoenwaelder
> Sent: 26 March 2019 08:23
> To: Joe Clarke (jclarke) <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [netmod] Question on draft-wu-netmod-factory-default
> 
> > > simple "factory-reset" RPC which resets all relevant datastores in
> > > an implementation specific manner is sufficient. Why expose more
> > > details to the management client?
> >
> > This would certainly make it simpler from the RPC standpoint.
> > However, if one can <get-data> from the factory-default DSes, I still
> > think there is a need to know what factory-default DS maps to what
> > other DS (in the case where there might be multiple that are different).
> >
> 
> The notion of multiple factory-default datastores sounds complex. And what is a
> management application going to do with them? How would a management
> application know which sets of datastores to reset together in a meaningful
> way?
> 
> My naive interpretation of the factory default DS (a single one) would be that it
> exposes the content you will find in <running> after the factory-reset has been
> executed. An extended version of Figure 2 of RFC 8342 would look like this:
> 
> And exposing such a factory default datastore would be optional I think.
> 
> /js
> 
> --

---

From: Andy Bierman <[email-masked]>
Date: Tue, 26 Mar 2019 09:13:54 -0700

> to the management client?
+1

Some of us have not consumed the NMDA kool-aid ;-)
We still manage servers, not datastores.
You can reset the server so it comes back with the factory-default config.
I have never heard of resetting specific datastores to factory-default.

>From the client POV, why would I even want to know the
implementation-specific
details and have to provide reset contents for each datastore and the order
to reset them?
No customers are asking for this!

/js

Andy

> > 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?
> >
> > [Qin]:We start with a simple case, you case could be addressed by
> invoking multiple rpc with each rpc to allow reset a set of datastores.
> >  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?
> >
> > [Qin]: In simple case, target DS will only be reset by a single factory
> datastore. If there is a new factory datastore could be derived from that
> DS, I think target DS should be changed to reset that new factory datastore.
> >
> > 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)?
> >
> > [Qin]: So your point is should we allow multiple source, multiple target
> in the same RPC, will think it over. Thanks.
> > Joe
> >