Re: [RTG-DIR] rtgdir Last Call Review requested: draft-ietf-netmod-factory-default

[Antoni Przygienda <[e-mail]>]

I have been selected to do a routing directorate “early” review of this draft.
​https://datatracker.ietf.org/doc/draft-ietf-netmod-factory-default/

Document: draft-ietf-netmod-factory-default
Reviewer: Tony Przygienda
Review Date: 03/15/20
Intended Status: Standards Track    

Summary:

I have some minor concerns about this document that I think should be resolved before it is submitted to the IESG.

Comments:

Good, clear, concise draft. Clear references, easy read. 

Following items need to be explained, treated IMO:

* it is not clear how "default configuration" defined in [RFC8342] interacts/is correlated with the "factory-default" store. Can "factory-default" overwrite the default configuration? Probably not since "it's in the data model" (RFC8342 is quite sparse on the subject). Generally I think it would be helpful to the reader to point out in a sentence that "default store" and "factory-default store" are utterly un-correlated since the language is suggesting they are closely related which in fact they are not.  
There is a subtle but big danger here with making it "read-only" and people misunderstanding this. If the device has been shipped with image X containing the store and then upgraded to image Y the factory-default-store for X may brick the device. It would be possibly a good thing to add somehow to the draft this consideration as in "when upgrading software version or Yang model of the server/device/node factory-default store in normally upgraded with it". 
* the draft says 

   o  Origin: This document does not define a new origin identity as it
      does not interact with the <operational> datastore.

This seems somewhat doubtful to me. Even if no new origin is defined here (maybe it should be) the draft should define what origins needs to be set or whether old origin should be preserved (I doubt that since .e.g. factory reset can overwrite default origin on current indented/operational)
* is the device clock reset/pertained or is the operation undefined as to what it does to internal device clock. This is often a very important operational consideration. 
* what happens to hardware installed keys on e.g. MACSEC? Are they reset/pertain/expected to be on factory-default and installed (vendors do different things here AFAIK), is that outside scope of this draft? 
* serialization, can other operations be performed @ the same time as factory reset? If so, which values do persist and when can the reset be executed? Will existing sessions be shut-down/warned/time-out'ed? If I missed the implications due to previous RFCs, which RFC governs the behavior here?
* Can the factory-default RPC lead to device reboot? Is that undefined/undesired (I think either is fine for the draft to say)? This is often an important operational consideration. The model says " after
          being reset, the device may become unreachable on the
          network". Does that pertain to this "reset" operation here or a reboot? IMO following terms should be added & defined/distinguished in the glossary "reset" and "reboot". What is "on the network"? management interfaces/uplinks/inband ports. Either treat that more explicitly as in "after factory-default the device SHOULD be reachable via management ports and may not be reachable via uplinks/inband ports" or drop the "network". There is a big difference between "bricking it", "needs physical removal or hook up to short-range e.g. USB/WLAN" and "can only be reached out-of-band" ... Using vague descriptions like "on the network" is probably worse than not saying anything at all.