Skip to main content

Last Call Review of draft-ietf-netmod-factory-default-14

Request Review of draft-ietf-netmod-factory-default
Requested revision No specific revision (document currently at 15)
Type Last Call Review
Team Routing Area Directorate (rtgdir)
Deadline 2020-03-16
Requested 2020-03-02
Requested by Alvaro Retana
Authors Qin Wu , Balázs Lengyel , Ye Niu
I-D last updated 2020-03-13
Completed reviews Yangdoctors Last Call review of -07 by Carl Moberg (diff)
Rtgdir Last Call review of -14 by Tony Przygienda (diff)
Genart Last Call review of -14 by Stewart Bryant (diff)
Secdir Last Call review of -14 by Stephen Kent (diff)
Assignment Reviewer Tony Przygienda
State Completed
Request Last Call review on draft-ietf-netmod-factory-default by Routing Area Directorate Assigned
Posted at
Reviewed revision 14 (document currently at 15)
Result Has issues
Completed 2020-03-13
I have been selected to do a routing directorate “early” review of this draft.

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


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


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.