Subject: Re: [netmod] [netconf] WG Last Call: draft-ietf-netmod-factory-default-05

From: Kent Watsen <[email-masked]>
Date: Tue, 5 Nov 2019 17:46:44 +0000

- NETCONF
+ NETMOD

> On Nov 5, 2019, at 6:44 AM, Kent Watsen <[email-masked]> wrote:
> 
> Hi Qin,
> 
>> [Qin]: The question is should rpc or factory default config or both enable ztp?
>> I think during initial zero-touch configure, it is factory default config to enable ztp.
>> In the middle of session, rpc can be used to trigger ztp process execution.
> 
> The factory-default config enables ZTP.  
> The RPC activates the factory-default config. 
> 
> K.  
> _______________________________________________
> netconf mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>

---

From: Kent Watsen <[email-masked]>
Date: Fri, 15 Nov 2019 21:16:00 +0000

Today ends the two-week Last Call, which passed.  Thank you everyone who participated.  

Qin, I'll start the shepherd writeup after -07 has been posted addressing the Last Call comments.

Kent // shepherd 

> On Nov 1, 2019, at 10:57 AM, Kent Watsen <[email-masked]> wrote:
> 
> This begins a two-week Working Group Last Call (WGLC) on draft-ietf-netmod-factory-default-05.  The WGLC ends on Nov 15 (two days before the NETMOD 106 session).  Please send your comments to the working group mailing list.
> 
> Positive comments, e.g., "I've reviewed this document and believe it is ready for publication", are welcome!  This is useful and important, even from authors.  Objections, concerns, and suggestions are also welcomed at this time.
> 
> Thank you,
> NETMOD Chairs

---

From: Qin Wu <[email-masked]>
Date: Sat, 30 Nov 2019 13:03:18 +0000

发件人: Joe Clarke (jclarke) [mailto:[email-masked]]
发送时间: 2019年11月19日 17:20
收件人: Qin Wu <[email-masked]>
抄送: Kent Watsen <[email-masked]>; [email-masked]; [email-masked]
主题: Re: [netmod] [netconf] WG Last Call: draft-ietf-netmod-factory-default-05

[Qin]: Yes, resetting processes or restarting node did cover ZTP part, from Martin’s comment, I feel we don’t need to tie resetting process with RFC8572, since RFC8572 actually focuses on SZTP.
Actually we may have a lot of legacy ZTP mechanism we can leverage, I am not sure which reference I should stick to. Make sense?

It does.  You should remove the informative reference.

[Qin]: Okay

More importantly, though, how do you see this practically being implemented?  With an ops dir hat, I’m walking through Section 2, and sending a factory-reset RPC to a device.  The device immediately resets <running> to default and <operational> to some similar default state.  The device has become unreachable within the network.  A reboot or other reset is optional to implement, so as an operator I’m not really sure what to expect at this point.

[Qin]:I am not sure we should make restart or reboot as mandatory after factory-reset rpc, I think factory-reset rpc affects kernel level, it will be good not to restart the node, if it touches hardware level, it is be important to reboot or restart the node. Another angle we can have is if factory-reset rpc is executed in the trust environment, it may be not necessary to restart the node or root.

Here’s my use case.  I have a switch that has a config (including a management IP [OOB or IB]).  When I send it the factory-default RPC, I now have a switch in the network I cannot reach.  It continues to run, but with a factory default config (which doesn’t include the management IP).  I now have a problem.  Sure, the switch may not need to reboot.  It might immediately do DHCP and begin a bootstrap workflow.  It may need a reboot to do that.

What I was asking is does it make sense to add some Operational Considerations text to let implementors and operators know about these types of things and encourage them (vendors in particular) to do think about how they will implement factory-default to ensure that these types of processes can be restarted without additional user intervention?

[Qin]: How about the add a few text at the end of section 2 to say:
OLD TEXT:
“
The "factory-reset" RPC MAY also be used to trigger some other resetting tasks such as restarting the node or some of the software processes.

”
NEW TEXT:
“
The "factory-reset" RPC MAY also be used to trigger some other resetting tasks such as restarting the node or some of the software processes,
especially after having onboard information being processed or when a specified boot image needs to be downloaded, verified and installed.
”
Joe