Subject: [netmod] Adoption poll for draft-wu-netmod-factory-default-02

From: Kent Watsen <[email-masked]>
Date: Mon, 25 Mar 2019 20:34:57 +0000

This email begins a 2-week adoption poll for:

    https://tools.ietf.org/html/draft-wu-netmod-factory-default-02

Please voice your support or objections before April 8.

Kent (and Lou)

---

From: Alex Campbell <[email-masked]>
Date: Mon, 25 Mar 2019 21:05:56 +0000

Support.

________________________________
From: netmod <[email-masked]> on behalf of Kent Watsen <[email-masked]>
Sent: Tuesday, 26 March 2019 9:34 a.m.
To: [email-masked]
Subject: [netmod] Adoption poll for draft-wu-netmod-factory-default-02

Kent (and Lou)

---

From: Andy Bierman <[email-masked]>
Date: Mon, 25 Mar 2019 15:10:48 -0700

> Please voice your support or objections before April 8.

I have significant concerns about this draft and work item.
The intentions are good and the scope is well-defined.
The problem is that this is a very proprietary implementation detail.

I have already raised the issue that our server cannot factory reset a
single datastore.
It can only do that for the whole server (which will setup the datastores
in an implementation manner and order). So another RPC is needed, and
if-features.

I have seen some comments on this issue: "This is great but our server
does not work that way, so we need X,Y,Z"  (Just like I am doing ;-)
How will the WG keep that from happening 10 or 30 times?

I support this work if the WG can figure out how to keep it simple.
(Meaning I support adoption of the work but not going to wait 2+ years for
it)

Kent (and Lou)

Andy

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

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 25 Mar 2019 22:19:06 +0000

If you do a factory reset, does that also mean that the device should be rebooted at the same time to get it into a consistent state?

Or should clients have the opportunity to update the config after the reset and before it has been rebooted?

Or is it not necessary to reboot the device at all?

Thanks,
Rob

From: netmod <[email-masked]> On Behalf Of Andy Bierman
Sent: 25 March 2019 23:11
To: Kent Watsen <[email-masked]>
Cc: NetMod WG <[email-masked]>
Subject: Re: [netmod] Adoption poll for draft-wu-netmod-factory-default-02

On Mon, Mar 25, 2019 at 1:35 PM Kent Watsen <[email-masked]<mailto:[email-masked]>> wrote:
This email begins a 2-week adoption poll for:

I have already raised the issue that our server cannot factory reset a single datastore.
It can only do that for the whole server (which will setup the datastores
in an implementation manner and order). So another RPC is needed, and if-features..

I support this work if the WG can figure out how to keep it simple.
(Meaning I support adoption of the work but not going to wait 2+ years for it)

Kent (and Lou)

Andy

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

---

From: Andy Bierman <[email-masked]>
Date: Mon, 25 Mar 2019 15:35:04 -0700

On Mon, Mar 25, 2019 at 3:19 PM Rob Wilton (rwilton) <[email-masked]>
wrote:

> If you do a factory reset, does that also mean that the device should be
> rebooted at the same time to get it into a consistent state?
>
>
>

I have not seen factory reset of datastores supported at all.
It is always the service or the device.
Sound like you are talking about the SysVinit command "reload" vs.
"restart".

IMO it would be a good goal to support this framework by providing
factory-reload and factory-restart RPC operations.

Thanks,

Andy

>
>
>
>
> *From:* netmod <[email-masked]> *On Behalf Of *Andy Bierman
> *Sent:* 25 March 2019 23:11
> *To:* Kent Watsen <[email-masked]>
> *Cc:* NetMod WG <[email-masked]>
> *Subject:* Re: [netmod] Adoption poll for
> draft-wu-netmod-factory-default-02
>
>
>
>
>
>
>
> if-features..

---

From: joel jaeggli <[email-masked]>
Date: Mon, 25 Mar 2019 23:35:34 -0700

On 3/25/19 13:34, Kent Watsen wrote:
> <x-apple-data-detectors://1>

support.

I would note that it probably needs a security considerations section
that addresses the two points raised in the security considerations
section of the informatively referenced  rfc 5870.

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tue, 26 Mar 2019 07:01:53 +0000

I support this draft as a starting place for this work, but I would like to see some changes in the final solution:

I think that having a datastore report the factory default configuration is good, and it is also right that this should be optional to implement, since some devices might not have default factory configuration, but instead run a first boot sequence to construct an initial configuration.

I don’t really understand the need to be able to perform a factory reset on a per datastore basis, but instead I would prefer to see a single device level factory reset RPC.  Such an RPC may do more than just resetting the configuration and rebooting the device, it might also change the software version, wipe areas of storage such as log files, cached files, etc.  Possibly, some of these options could be controlled via parameters to the RPC if there is enough commonality, of otherwise vendors could augment in their own options to a minimal standard RPC.

Copying from <factory-default> to another datastore is OK with me, although I don’t see any particular need/value in doing this, hence I would rather see <copy-config> fixed more generically to allow copying between two configuration datastores than specifically augmenting specifically for this datastore.  Hence, I think that extending/replacing the <copy-config> RPC could probably be deferred to a NETCONF-bis or NETCONF-NMDA-bis document.

I don’t see a need for this document to reference or refer to the instances-data draft.  I think that using instance-data rather than a factory-default datastore is just an internal implementation detail and shouldn’t be exposed to the user.

However, Balazs, I do see merit in allowing the contents of any configuration datastore to be loaded from an instance-data file, or written to an instance data file (either local or remote).   But, I don’t think that this should go into this draft, and probably it is too late to add this to the instance-data draft.

Thanks,
Rob

From: netmod <[email-masked]> On Behalf Of Kent Watsen
Sent: 25 March 2019 21:35
To: [email-masked]
Subject: [netmod] Adoption poll for draft-wu-netmod-factory-default-02

Please voice your support or objections before April 8.<x-apple-data-detectors://1>

Kent (and Lou)

---

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

> <x-apple-data-detectors://1>

I support, and I've already sent some comments.  I think more work is
needed in the case where multiple datastores need to be reset with
different factory-default data.  I agree with others' comments that an
RPC that does all of the required work without needing to specify the
input datastore is simpler.  Still, understanding what factory-default
datastore maps to what other datastore is needed IMO.

Joe

---

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

> I would rather see <copy-config> fixed more generically to allow copying between two configuration datastores than specifically augmenting specifically for this datastore.  Hence, I think that extending/replacing the <copy-config> RPC could probably be deferred to a NETCONF-bis or NETCONF-NMDA-bis document.

Agreed.  Qin, please add to the NETCONF-next issue tracker. 

https://github.com/netconf-wg/netconf-next/issues

Kent

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Tue, 26 Mar 2019 08:33:19 +0000

I support adoption of this draft as a WG document.

+1 to what various people said with regards to simplifications needed in the document.

From: netmod <[email-masked]> on behalf of Kent Watsen <[email-masked]>
Date: Monday, March 25, 2019 at 9:35 PM
To: "[email-masked]" <[email-masked]>
Subject: [netmod] Adoption poll for draft-wu-netmod-factory-default-02

Kent (and Lou)