idnits 2.17.1 draft-ietf-netmod-factory-default-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 9, 2020) is 1537 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC6421' is mentioned on line 206, but not defined == Missing Reference: 'RFC3688' is mentioned on line 292, but not defined == Missing Reference: 'RFC6020' is mentioned on line 300, but not defined == Missing Reference: 'RFC6241' is mentioned on line 310, but not defined == Missing Reference: 'RFC8040' is mentioned on line 310, but not defined == Missing Reference: 'RFC6242' is mentioned on line 312, but not defined == Missing Reference: 'RFC8446' is mentioned on line 314, but not defined == Missing Reference: 'RFC8573' is mentioned on line 400, but not defined == Unused Reference: 'I-D.ietf-netmod-yang-instance-file-format' is defined on line 370, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-netmod-yang-instance-file-format-06 Summary: 0 errors (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETMOD Working Group Q. Wu 3 Internet-Draft Huawei 4 Intended status: Standards Track B. Lengyel 5 Expires: August 12, 2020 Ericsson Hungary 6 Y. Niu 7 Huawei 8 February 9, 2020 10 Factory Default Setting 11 draft-ietf-netmod-factory-default-10 13 Abstract 15 This document defines a method to reset a server to its factory- 16 default content. The reset operation may be used, e.g., when the 17 existing configuration has major errors so re-starting the 18 configuration process from scratch is the best option. 20 A new factory-reset RPC is defined. When resetting a device, all 21 previous configuration settings will be lost and replaced by the 22 factory-default content. 24 A new optional "factory-default" read-only datastore is defined, that 25 contains the factory default configuration for the device. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on August 12, 2020. 44 Copyright Notice 46 Copyright (c) 2020 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Factory-Reset RPC . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Factory-Default Datastore . . . . . . . . . . . . . . . . . . 4 65 4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 69 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 72 9.2. Informative References . . . . . . . . . . . . . . . . . 8 73 Appendix A. Changes between revisions . . . . . . . . . . . . . 8 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 76 1. Introduction 78 This document defines a method to reset a server to its factory- 79 default content. The reset operation may be used, e.g., when the 80 existing configuration has major errors so re-starting the 81 configuration process from scratch is the best option. 83 A factory-reset RPC is defined. When resetting a device, all 84 previous configuration settings will be lost and replaced by the 85 factory-default content. 87 A "factory-default" read-only datastore is defined, that contains the 88 data to replace the contents of implemented read-write conventional 89 configuration datastores at reset. This datastore can also be used 90 in the operation. 92 The YANG data model in this document conforms to the Network 93 Management Datastore Architecture defined in [RFC8342]. 95 1.1. Terminology 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 99 "OPTIONAL" in this document are to be interpreted as described in BCP 100 14 [RFC2119] [RFC8174] when, and only when, they appear in all 101 capitals, as shown here. 103 The following terms are defined in [RFC8342] [RFC7950] and are not 104 redefined here: 106 o server 108 o startup configuration datastore 110 o candidate configuration datastore 112 o running configuration datastore 114 o intended configuration datastore 116 o operational state datastore 118 o conventional configuration datastore 120 o RPC operation 122 The following terms are defined in this document as follows: 124 o factory-default: a preconfigured initial configuration that is 125 used to initialize the configuration of a server. 127 o factory-default datastore: A read-only configuration datastore 128 holding a preconfigured initial configuration that is used to 129 initialize the configuration of a server. 131 2. Factory-Reset RPC 133 A new "factory-reset" RPC is introduced. Upon receiving the RPC 135 o All supported conventional read-write configuration datastores 136 (i.e. , , and ) are all reset to the 137 contents of . 139 o Read-only datastores receive their content from other 140 datastores(e.g. gets its content from ). 142 o All data in any ephemeral datastores MUST be discarded. 144 o The contents of the datastore MUST reflect the 145 operational state of the device after applying the factory default 146 configuration. 148 In addition, the "factory-reset" RPC MUST restore non-volatile 149 storage to factory condition. Depending on the system, this may 150 entail deleting dynamically generated files, such as those containing 151 keys (e.g., /etc/ssl/private), certificates (e.g., /etc/ssl), and 152 logs (e.g., /var/log), temporary files (e.g., /tmp/*). All security 153 sensitive data (i.e., private keys, passwords, etc.) SHOULD be 154 overwritten with zeros or a pattern before deletion. The "factory- 155 reset" RPC MAY also be used to trigger some other resetting tasks 156 such as restarting the node or some of the software processes. 158 Note that operators should be aware that since all read-write 159 datastores are immediately reset to factory-default, the device may 160 become unreachable on the network. It is important to understand how 161 a given vendor's device will behave after the RPC is executed. 162 Implementors SHOULD reboot the device or otherwise restart processes 163 needed to bootstrap it. 165 3. Factory-Default Datastore 167 Following the guidelines for defining Datastores in the appendix A of 168 [RFC8342], this document introduces a new optional datastore resource 169 named "factory-default" that represents a preconfigured minimal 170 initial configuration that can be used to initialize the 171 configuration of a server. A device MAY implement the RPC without implementing the "factory-default" datastore, 173 which would only eliminate the ability to programmatically determine 174 the factory-default configuration. 176 o Name: "factory-default" 178 o YANG modules: all 180 o YANG nodes: all "config true" data nodes 182 o Management operations: The content of the datastore is set by the 183 server in an implementation dependent manner. The content can not 184 be changed by management operations via NETCONF, RESTCONF, the CLI 185 etc. unless specialized, dedicated operations are provided. The 186 datastore can be read using the standard NETCONF/RESTCONF protocol 187 operations. The operation copies the factory 188 default content to and, if present, 189 and then the content of these datastores is propagated 190 automatically to any other read only datastores, e.g., 191 and . 193 o Origin: This document does not define a new origin identity as it 194 does not interact with datastore. 196 o Protocols: RESTCONF, NETCONF and other management protocol. 198 o Defining YANG module: "ietf-factory-default". 200 The contents of is defined by the device vendor and 201 MUST persist across device restarts. 203 4. YANG Module 205 This module imports typedefs from [RFC8342], and it references 206 [RFC6421],[RFC8341]. 208 file "ietf-factory-default@2019-11-27.yang" 209 module ietf-factory-default { 210 yang-version 1.1; 211 namespace "urn:ietf:params:xml:ns:yang:ietf-factory-default"; 212 prefix fd; 214 import ietf-datastores { 215 prefix ds; 216 reference 217 "RFC 8342: Network Management Datastore Architecture (NMDA)"; 218 } 219 import ietf-netconf-acm { 220 prefix nacm; 221 reference 222 "RFC8341: Network Configuration Access Control Model"; 223 } 225 organization 226 "IETF NETMOD (Network Modeling) Working Group"; 227 contact 228 "WG Web: 229 WG List: 231 Editor: Qin Wu 232 233 Editor: Balazs Lengyel 234 235 Editor: Ye Niu 236 "; 237 description 238 "This module defines an RPC called 'factory-reset', a 239 datastore identity called 'factory-default-datastore'. 241 It provides functionality to reset a server to its 242 factory-default content. 244 Copyright (c) 2019 IETF Trust and the persons identified as 245 authors of the code. All rights reserved. 247 Redistribution and use in source and binary forms, with or 248 without modification, is permitted pursuant to, and subject 249 to the license terms contained in, the Simplified BSD License 250 set forth in Section 4.c of the IETF Trust's Legal Provisions 251 Relating to IETF Documents 252 (http://trustee.ietf.org/license-info). 254 This version of this YANG module is part of RFC XXXX; 255 see the RFC itself for full legal notices."; 257 revision 2019-11-27 { 258 description 259 "Initial revision."; 260 reference 261 "RFC XXXX: Factory default Setting"; 262 } 264 feature factory-default-datastore { 265 description 266 "Indicates that the factory-default configuration is 267 available as a datastore."; 268 } 270 rpc factory-reset { 271 nacm:default-deny-all; 272 description 273 "The server resets the content of all read-write 274 configuration datastores (i.e., , , 275 and ) to their factory-default content."; 276 } 278 identity factory-default { 279 if-feature "factory-default-datastore"; 280 base ds:datastore; 281 description 282 "This read-only datastore contains the factory-default 283 configuration for the device used to replace the contents 284 of the read-write conventional configuration datastores 285 during a factory-reset RPC operation."; 286 } 287 } 288 290 5. IANA Considerations 292 This document registers one URI in the IETF XML Registry [RFC3688]. 293 The following registration has been made: 295 URI: urn:ietf:params:xml:ns:yang:ietf-factory-default 296 Registrant Contact: The IESG. 297 XML: N/A, the requested URI is an XML namespace. 299 This document registers one YANG module in the YANG Module Names 300 Registry [RFC6020]. The following registration has been made: 302 name: ietf-factory-default 303 namespace: urn:ietf:params:xml:ns:yang:ietf-factory-default 304 prefix: fd 305 RFC: xxxx 307 6. Security Considerations 309 The YANG module defined in this document extends the base operations 310 for NETCONF [RFC6241] and RESTCONF [RFC8040]. The lowest NETCONF 311 layer is the secure transport layer, and the mandatory-to-implement 312 secure transport is Secure Shell (SSH) [RFC6242]. The lowest 313 RESTCONF layer is HTTPS, and the mandatory-to-implement secure 314 transport is TLS [RFC8446]. 316 Access to the RPC operation is considered sensitive 317 in and therefore has been restricted using the "default- deny-all" 318 access control defined in . [RFC8341] 320 The "factory-reset" RPC can prevent any further management of the 321 device if the session and client config is included in the factory- 322 reset contents. 324 The operational disruption caused by setting the config to factory- 325 reset contents varies greatly depending on the implementation and 326 current config. 328 7. Acknowledgements 330 Thanks to Juergen Schoenwaelder, Ladislav Lhotka, Alex Campbell, Joe 331 Clarke, Robert Wilton, Kent Watsen, Joel Jaeggli, Lou Berger, Andy 332 Bierman, Susan Hares to review this draft and provide important input 333 to this document. 335 8. Contributors 337 Rohit R Ranade 338 Huawei 339 Email: rohitrranade@huawei.com 341 9. References 343 9.1. Normative References 345 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 346 Requirement Levels", BCP 14, RFC 2119, 347 DOI 10.17487/RFC2119, March 1997, 348 . 350 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 351 RFC 7950, DOI 10.17487/RFC7950, August 2016, 352 . 354 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 355 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 356 May 2017, . 358 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 359 Access Control Model", STD 91, RFC 8341, 360 DOI 10.17487/RFC8341, March 2018, 361 . 363 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 364 and R. Wilton, "Network Management Datastore Architecture 365 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 366 . 368 9.2. Informative References 370 [I-D.ietf-netmod-yang-instance-file-format] 371 Lengyel, B. and B. Claise, "YANG Instance Data File 372 Format", draft-ietf-netmod-yang-instance-file-format-06 373 (work in progress), December 2019. 375 Appendix A. Changes between revisions 377 Editorial Note (To be removed by RFC Editor) 379 v09 - 10 381 o Incorporate Shepherd review's comments. 383 v08 - 09 385 o Provide some guideline for operators and implementor who implement 386 factory defaut method. 388 v07 - 08 390 o Provide clarification and recommendation on the relationship 391 between factory-reset RPC and reboot. 393 o Nits fixed based on YANG Doctor Review. 395 v06 - 07 397 o Remove Factory-default content specification; 399 o Remove reference to YANG instance data file format and zero touch 400 provision [RFC8573]; 402 o Remove copy-config operation extension on factory-default 403 datastore 405 v05 - 06 407 o Additional text to enhance security section. 409 o Add nacm:default-deny-all on "factory-reset" RPC. 411 o A few clarification on Factory-default content specification. 413 v03 - 04 415 o Additional text to clarify factory-reset RPC usage. 417 v02 - 03 419 o Update security consideration section. 421 v01 - v02 423 o Address security issue in the security consideration section. 425 o Remove an extension to the NETCONF operation which 426 allows it to operate on the factory-default datastore. 428 o Add an extension to the NETCONF operation which 429 allows it to operate on the factory-default datastore. 431 v00 - v01 433 o Change YANG server into server defined in NMDA architecture based 434 on discussion. 436 o Allow reset the content of all read-write configuraton datastores 437 to its factory-default content except . 439 o Add clarification text on factory-reset protocol operation 440 behavior. 442 v03 - v00 444 o Change draft name from draft-wu to draft-ietf-netmod-factory- 445 default-00 without content changes. 447 v02 - v03 449 o Change reset-datastore RPC into factory-reset RPC to allow reset 450 the whole device with factory default content. 452 o Remove target datastore parameter from factory-reset RPC. 454 o Other editorial changes. 456 v01 - v02 458 o Add copy-config based on Rob's comment. 460 o Reference Update. 462 v03 - v00 - v01 464 o Changed name from draft-wu-netconf-restconf-factory-restore to 465 draft-wu-netmod-factory-default 467 o Removed copy-config ; reset-datastore is enough 469 v02 - v03 471 o Restructured 473 o Made new datastore optional 475 o Removed Netconf capability 477 o Listed Open issues 478 v01 - v02 480 o - 482 v00 - v01 484 o - 486 Authors' Addresses 488 Qin Wu 489 Huawei 490 101 Software Avenue, Yuhua District 491 Nanjing, Jiangsu 210012 492 China 494 Email: bill.wu@huawei.com 496 Balazs Lengyel 497 Ericsson Hungary 498 Magyar Tudosok korutja 11 499 1117 Budapest 500 Hungary 502 Phone: +36-70-330-7909 503 Email: balazs.lengyel@ericsson.com 505 Ye Niu 506 Huawei 508 Email: niuye@huawei.com