A YANG Data Model for Factory Default Settings
draft-ietf-netmod-factory-default-15
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2020-08-28
|
15 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2020-07-27
|
15 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2020-06-18
|
15 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2020-05-13
|
15 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2020-05-13
|
15 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2020-05-13
|
15 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2020-05-12
|
15 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2020-05-11
|
15 | (System) | RFC Editor state changed to EDIT |
2020-05-11
|
15 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2020-05-11
|
15 | (System) | Announcement was received by RFC Editor |
2020-05-11
|
15 | (System) | IANA Action state changed to In Progress |
2020-05-11
|
15 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2020-05-11
|
15 | Amy Vezza | IESG has approved the document |
2020-05-11
|
15 | Amy Vezza | Closed "Approve" ballot |
2020-05-11
|
15 | Amy Vezza | Ballot approval text was generated |
2020-05-11
|
15 | Robert Wilton | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2020-05-08
|
15 | Roman Danyliw | [Ballot comment] Thank you for addressing my DISCUSS items. |
2020-05-08
|
15 | Roman Danyliw | [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss |
2020-04-25
|
15 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2020-04-25
|
15 | Qin Wu | New version available: draft-ietf-netmod-factory-default-15.txt |
2020-04-25
|
15 | (System) | New version approved |
2020-04-25
|
15 | (System) | Request for posting confirmation emailed to previous authors: Qin WU , Ye Niu , Balazs Lengyel |
2020-04-25
|
15 | Qin Wu | Uploaded new revision |
2020-04-24
|
14 | Cindy Morgan | IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation |
2020-04-24
|
14 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund |
2020-04-22
|
14 | Benjamin Kaduk | [Ballot comment] While many of the secdir reviewer's complaints stem from the YANG security considerations boilerplate, it still seems like it would be worth some … [Ballot comment] While many of the secdir reviewer's complaints stem from the YANG security considerations boilerplate, it still seems like it would be worth some form of response to the review. Section 1 This document defines a method to reset a server to its factory default content. The reset operation may be used, e.g., when the existing configuration has major errors so re-starting the configuration process from scratch is the best option. A "factory-reset" RPC is defined. When resetting a device, all previous configuration settings will be lost and replaced by the factory default content. nit: these two paragraphs talk about the same thing, but the next paragraph is a different thing. It may be better to combine these two in to a single paragraph. A "factory-default" read-only datastore is defined, that contains the data to replace the contents of implemented read-write conventional configuration datastores at reset. [...] Can I suggest instead: % A "factory-default" read-only datastore is defined, that reflects what the % conventional read-write datastores would be overwritten with in the case of % a factory-reset operation. Section 2 All security sensitive data (i.e., private keys, passwords, etc.) SHOULD be overwritten with zeros or a pattern before deletion. [...] I might suggest instead: % When this process includes security-sensitive data such as cryptographic % keys or passwords, it is RECOMMENDED to perform the deletion in as % thorough a manner as possible (e.g., overwriting the physical storage % medium with zeros and/or random bits) to reduce the risk of the sensitive % material being recoverable. It's probably worth noting that since this is only dymanically generated files, any cryptographic keys that are part of the factory-installed image will be retained (such as an IDevID certificate). Section 3 Following the guidelines for defining Datastores in the appendix A of [RFC8342], this document introduces a new optional datastore resource named "factory-default" that represents a preconfigured initial configuration that can be used to initialize the configuration of a nit/soapbox: "preconfigured initial configuration" feels like an awkward wording to me; perhaps "pre-set initial configuration" or "fixed initial configuration"? Section 4 description "This read-only datastore contains the factory default configuration for the device used to replace the contents of the read-write conventional configuration datastores during a 'factory-reset' RPC operation."; nit: the grammar here is off; maybe "for the device that will be used"? (Or some adaptation of my proposed text from earlier.) Section 6 If the factory-default configuration is an "open" one, then performing the reset could leave the device (and thus the network!) vulnerable to attack until it is properly configured. The rtgdir reviewer's comments seem related to this. An attacker that could somehow cause the factory-reset to be performed would cause the loss of running state/crypto keys that would potentially require a lot of operator effort to recover (in addition to the more immediate DoS issues). There is some discussion in draft-ietf-anima-bootstrapping-keyinfra about attacks that are possible when a device is restored to its factory default state; it might be worth trying to incorporate some of that discussion in some manner (whether inline or by reference). The "factory-reset" RPC can prevent any further management of the device if the session and client config are included in the factory default contents. I'm not sure this is 100% correct. If the factory default config overwrites this items, then yes, it will prevent further management. But we also say to delete dynamic files from nonvoliatile storage, which at least to me seems like it could include this class of items and cause the same symptoms even if the configuration items in question are not included in the factory default contents. |
2020-04-22
|
14 | Benjamin Kaduk | [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk |
2020-04-22
|
14 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2020-04-22
|
14 | Alvaro Retana | [Ballot comment] [Thank you for addressing the rtg-dir review.] |
2020-04-22
|
14 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2020-04-21
|
14 | Éric Vyncke | [Ballot comment] Thank you for the work put into this document. The document is clear, easy to read and quite useful. Please find below some … [Ballot comment] Thank you for the work put into this document. The document is clear, easy to read and quite useful. Please find below some non-blocking COMMENTs. An answer will be appreciated. I also support Barry's comment. I hope that this helps to improve the document, Regards, -éric == COMMENTS == If the "factory-default" is optional (per section 3), then it may be worth to specify this quality in the abstract and in the introduction. -- Section 2 -- What happens with the different counters in the data store ? Why is this a SHOULD for overwritting sensitive data and not a MUST? At least section 6 writes that "owner of the device MUST NOT rely on any sensitive data (e.g., private keys) being forensically unrecoverable" |
2020-04-21
|
14 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2020-04-21
|
14 | Martin Duke | [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke |
2020-04-21
|
14 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2020-04-21
|
14 | Roman Danyliw | [Ballot discuss] Please use YANG security considerations template from https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines. Specifically (as a DISCUSS item): ** (Per the template questions “for all YANG modules … [Ballot discuss] Please use YANG security considerations template from https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines. Specifically (as a DISCUSS item): ** (Per the template questions “for all YANG modules you must evaluate whether any readable data”) Would factory-default contain any sensitive information in certain network environments where the ACLs should be more restrictive that world readable for everyone? Per “The operational disruption caused by setting the config to factory default contents varies greatly depending on the implementation and current config”, it seems like it could be worse than just an operational disruption. Please note that a default configuration could be insecure or not have security controls enabled whereby exposing the network to compromise. |
2020-04-21
|
14 | Roman Danyliw | [Ballot comment] Please use YANG security considerations template from https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines. Specifically (as a COMMENT item): ** Add “The Network Configuration Access Control Model (NACM) … [Ballot comment] Please use YANG security considerations template from https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines. Specifically (as a COMMENT item): ** Add “The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to …” |
2020-04-21
|
14 | Roman Danyliw | [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw |
2020-04-20
|
14 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2020-04-20
|
14 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2020-04-13
|
14 | Barry Leiba | [Ballot comment] The Abstract mentions the YANG data model and the datastore, but not the Factory-Reset RPC. I think it should mention that as well. |
2020-04-13
|
14 | Barry Leiba | Ballot comment text updated for Barry Leiba |
2020-04-13
|
14 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2020-04-06
|
14 | Robert Wilton | Placed on agenda for telechat - 2020-04-24 |
2020-04-03
|
14 | Murray Kucherawy | [Ballot comment] Section 2: * "All security sensitive data (i.e., private keys, passwords, etc.) SHOULD be overwritten ..." presents a choice. Why would an implementer … [Ballot comment] Section 2: * "All security sensitive data (i.e., private keys, passwords, etc.) SHOULD be overwritten ..." presents a choice. Why would an implementer not do this? * "Implementors SHOULD reboot the device or otherwise restart processes needed to bootstrap it." leads me to the same question. Nits: * "Upon receiving the RPC" is followed by a list, so please add a colon * "datastores(e.g.," -- add a space after "datastores" Section 3: Nits: * "The contents of is defined ..." -- s/is/are/ Section 5: * "This document registers one URI in the IETF XML Registry [RFC3688]. ..." should say explicitly that it's the "ns" sub-registry receiving a new entry. |
2020-04-03
|
14 | Murray Kucherawy | [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy |
2020-04-03
|
14 | Robert Wilton | IESG state changed to IESG Evaluation from Waiting for Writeup |
2020-04-03
|
14 | Robert Wilton | Ballot has been issued |
2020-04-03
|
14 | Robert Wilton | [Ballot Position Update] New position, Yes, has been recorded for Robert Wilton |
2020-04-03
|
14 | Robert Wilton | Created "Approve" ballot |
2020-04-03
|
14 | Robert Wilton | Ballot writeup was changed |
2020-04-03
|
14 | Robert Wilton | Ballot approval text was generated |
2020-04-02
|
14 | Warren Kumari | Shepherding AD changed to Robert Wilton |
2020-03-16
|
14 | Sabrina Tanamal | IANA Experts State changed to Expert Reviews OK from Reviews assigned |
2020-03-16
|
14 | Sabrina Tanamal | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2020-03-16
|
14 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2020-03-13
|
14 | Min Ye | Request for Last Call review by RTGDIR Completed: Has Issues. Reviewer: Tony Przygienda. |
2020-03-13
|
14 | Sabrina Tanamal | IANA Experts State changed to Reviews assigned |
2020-03-13
|
14 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2020-03-13
|
14 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-netmod-factory-default-14. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-netmod-factory-default-14. If any part of this review is inaccurate, please let us know. The IANA Services Operator understands that, upon approval of this document, there are two actions which we must complete. First, in the ns registry on the IETF XML Registry page located at: https://www.iana.org/assignments/xml-registry/ a single, new namespace will be registered as follows: ID: yang:ietf-factory-default URI: urn:ietf:params:xml:ns:yang:ietf-factory-default Filename: [ TBD-at-Registration ] Reference: [ RFC-to-be ] As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC. Second, in the YANG Module Names registry on the YANG Parameters registry page located at: https://www.iana.org/assignments/yang-parameters/ a single, new YANG module will be registered as follows: Name: ietf-factory-default File: [ TBD-at-Registration ] Maintained by IANA? N Namespace: urn:ietf:params:xml:ns:yang:ietf-factory-default Prefix: fd Module: Reference: [ RFC-to-be ] While the YANG module name will be registered after the IESG approves the document, the YANG module file will be posted after the RFC Editor notifies us that the document has been published. The IANA Services Operator understands that these are the only actions required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2020-03-12
|
14 | Stewart Bryant | Request for Last Call review by GENART Completed: Ready. Reviewer: Stewart Bryant. Sent review to list. |
2020-03-09
|
14 | Stephen Kent | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Stephen Kent. Sent review to list. |
2020-03-06
|
14 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Stephen Kent |
2020-03-06
|
14 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Stephen Kent |
2020-03-05
|
14 | Min Ye | Assignment of request for Last Call review by RTGDIR to Dave Sinicrope was marked no-response |
2020-03-05
|
14 | Min Ye | Request for Last Call review by RTGDIR is assigned to Tony Przygienda |
2020-03-05
|
14 | Min Ye | Request for Last Call review by RTGDIR is assigned to Tony Przygienda |
2020-03-05
|
14 | Jean Mahoney | Request for Last Call review by GENART is assigned to Stewart Bryant |
2020-03-05
|
14 | Jean Mahoney | Request for Last Call review by GENART is assigned to Stewart Bryant |
2020-03-03
|
14 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Fred Baker |
2020-03-03
|
14 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Fred Baker |
2020-03-02
|
14 | Min Ye | Request for Last Call review by RTGDIR is assigned to Dave Sinicrope |
2020-03-02
|
14 | Min Ye | Request for Last Call review by RTGDIR is assigned to Dave Sinicrope |
2020-03-02
|
14 | Alvaro Retana | Requested Last Call review by RTGDIR |
2020-03-02
|
14 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2020-03-02
|
14 | Cindy Morgan | The following Last Call announcement was sent out (ends 2020-03-16): From: The IESG To: IETF-Announce CC: netmod@ietf.org, warren@kumari.net, netmod-chairs@ietf.org, draft-ietf-netmod-factory-default@ietf.org, Kent … The following Last Call announcement was sent out (ends 2020-03-16): From: The IESG To: IETF-Announce CC: netmod@ietf.org, warren@kumari.net, netmod-chairs@ietf.org, draft-ietf-netmod-factory-default@ietf.org, Kent Watsen , kent+ietf@watsen.net Reply-To: last-call@ietf.org Sender: Subject: Last Call: (A YANG Data Model for Factory Default Settings) to Proposed Standard The IESG has received a request from the Network Modeling WG (netmod) to consider the following document: - 'A YANG Data Model for Factory Default Settings' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2020-03-16. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Note: Warren Kumari is officially the Responsible AD, but is simply acting as a proxy for Rob Wilton, the incoming Management AD. Abstract This document defines a YANG data model to allow clients to reset a server back to its factory default condition. It also defines a "factory-default" datastore to allow clients to read the factory default configuration for the device. The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-netmod-factory-default/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-netmod-factory-default/ballot/ No IPR declarations have been submitted directly on this I-D. |
2020-03-02
|
14 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2020-03-02
|
14 | Warren Kumari | Last call was requested |
2020-03-02
|
14 | Warren Kumari | Ballot approval text was generated |
2020-03-02
|
14 | Warren Kumari | Ballot writeup was generated |
2020-03-02
|
14 | Warren Kumari | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2020-03-02
|
14 | Warren Kumari | Last call announcement was changed |
2020-02-26
|
14 | Qin Wu | New version available: draft-ietf-netmod-factory-default-14.txt |
2020-02-26
|
14 | (System) | New version accepted (logged-in submitter: Qin Wu) |
2020-02-26
|
14 | Qin Wu | Uploaded new revision |
2020-02-25
|
13 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2020-02-25
|
13 | Qin Wu | New version available: draft-ietf-netmod-factory-default-13.txt |
2020-02-25
|
13 | (System) | New version accepted (logged-in submitter: Qin Wu) |
2020-02-25
|
13 | Qin Wu | Uploaded new revision |
2020-02-24
|
12 | Warren Kumari | Warren Kumari acting as proxy for Rob Wilton |
2020-02-24
|
12 | Warren Kumari | IESG state changed to AD Evaluation::Revised I-D Needed from Publication Requested |
2020-02-18
|
12 | Warren Kumari | Shepherding AD changed to Warren "Ace" Kumari |
2020-02-17
|
12 | Kent Watsen | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 1 November 2019. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Shepherd: Proposed Standard. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. Shepherd: This document defines a method to reset a server to its factory- default content. The reset operation may be used, e.g., when the existing configuration has major errors so re-starting the configuration process from scratch is the best option. A new factory-reset RPC is defined. When resetting a datastore, all previous configuration settings will be lost and replaced by the factory-default content. A new optional "factory-default" read-only datastore is defined, that contains the data that will be copied over to the running datastore at reset. Working Group Summary: Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Shepherd: There was nothing in the process worth noting. The authors originally thought the solution should reset a "datastore", but the WG convinced them that the restoring of the "running" datastore was simply an artifact of the RPC. Document Quality: Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Shepherd: The Shepherd is unaware of an implementations nor commitments. The document went through a YANG Doctor review as part of the Last Call process. Here is a direct link to that review: https://datatracker.ietf.org/doc/review-ietf-netmod-factory-default-07-yangdoctors-lc-moberg-2019-11-27 Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Shepherd: The Shepherd is Kent Watsen. The responsible AD is/was Ignas Bagdonas (now Robert Wilton) (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. Shepherd: The Shepherd reread the entire document, which led to requesting an update to address numerous non-technical issues that were addressed in the -10 and -11 updates. The Shepherd validated the syntactical correctness of the module using both `yanglint` and `pyang`, with neither returning any errors or warnings. $ yanglint --strict ietf-factory-default\@2019-11-27.yang $ pyang --strict --ietf ietf-factory-default\@2019-11-27.yang (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Shepherd: The Shepherd does not have any concerns about the depth or breadth of the reviews that have been performed. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. Shepherd: The Shepherd does not believe that portions of the document need from a particular or from broader perspective. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Shepherd: The Shepherd has no specific concerns or issues with this document. The draft is very simple, straightforward, and long overdue. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Shepherd: All authors confirmed that they are not aware any IPR related to this document. Here is the link to the IPR call request: https://mailarchive.ietf.org/arch/msg/netmod/gyhsCTz9NqIHx87XGplShG0CrX4 Disclaimer: My kickoff message erroneously says "In order to complete the Adoption poll". It should've said "Last Call". This was a copy/paste error. Warning: For some reason Niu Ye's response sent on Nov 14 does not appear above. I have tried to find it by justing looking at the messages sent on that date, but to no avail. I have the message in my local mailbox and see that it was sent to the "netmod" list. I don't understand why Niu Ye's response doesn't appear. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. Shepherd: No IPR disclosure has been filed that references this document. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Shepherd: WG consensus behind this document is very solid. The WG as a whole understands and agrees with it. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) Shepherd: No one has threatened an appeal or otherwise indicated discontent (extreme or otherwise). (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Shepherd: Idnits was tested against -10, which led to the publication of -11. Currently the "very verbose" mode returns one warning and one comment: 1) The warning: == Missing Reference: 'RFC8573' is mentioned on line 419, but not defined 'provision [RFC8573];...' Is a non-issue because the "reference" appears in the Change Log section that will be removed by RFC Editor. 2) The comment: -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with ' ' and |
2020-02-17
|
12 | Kent Watsen | Responsible AD changed to Ignas Bagdonas |
2020-02-17
|
12 | Kent Watsen | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2020-02-17
|
12 | Kent Watsen | IESG state changed to Publication Requested from I-D Exists |
2020-02-17
|
12 | Kent Watsen | IESG process started in state Publication Requested |
2020-02-17
|
12 | Kent Watsen | Changed consensus to Yes from Unknown |
2020-02-17
|
12 | Kent Watsen | Intended Status changed to Proposed Standard from None |
2020-02-17
|
12 | Kent Watsen | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 1 November 2019. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Shepherd: Proposed Standard. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. Shepherd: This document defines a method to reset a server to its factory- default content. The reset operation may be used, e.g., when the existing configuration has major errors so re-starting the configuration process from scratch is the best option. A new factory-reset RPC is defined. When resetting a datastore, all previous configuration settings will be lost and replaced by the factory-default content. A new optional "factory-default" read-only datastore is defined, that contains the data that will be copied over to the running datastore at reset. Working Group Summary: Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Shepherd: There was nothing in the process worth noting. The authors originally thought the solution should reset a "datastore", but the WG convinced them that the restoring of the "running" datastore was simply an artifact of the RPC. Document Quality: Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Shepherd: The Shepherd is unaware of an implementations nor commitments. The document went through a YANG Doctor review as part of the Last Call process. Here is a direct link to that review: https://datatracker.ietf.org/doc/review-ietf-netmod-factory-default-07-yangdoctors-lc-moberg-2019-11-27 Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Shepherd: The Shepherd is Kent Watsen. The responsible AD is/was Ignas Bagdonas (now Robert Wilton) (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. Shepherd: The Shepherd reread the entire document, which led to requesting an update to address numerous non-technical issues that were addressed in the -10 and -11 updates. The Shepherd validated the syntactical correctness of the module using both `yanglint` and `pyang`, with neither returning any errors or warnings. $ yanglint --strict ietf-factory-default\@2019-11-27.yang $ pyang --strict --ietf ietf-factory-default\@2019-11-27.yang (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Shepherd: The Shepherd does not have any concerns about the depth or breadth of the reviews that have been performed. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. Shepherd: The Shepherd does not believe that portions of the document need from a particular or from broader perspective. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Shepherd: The Shepherd has no specific concerns or issues with this document. The draft is very simple, straightforward, and long overdue. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Shepherd: All authors confirmed that they are not aware any IPR related to this document. Here is the link to the IPR call request: https://mailarchive.ietf.org/arch/msg/netmod/gyhsCTz9NqIHx87XGplShG0CrX4 Disclaimer: My kickoff message erroneously says "In order to complete the Adoption poll". It should've said "Last Call". This was a copy/paste error. Warning: For some reason Niu Ye's response sent on Nov 14 does not appear above. I have tried to find it by justing looking at the messages sent on that date, but to no avail. I have the message in my local mailbox and see that it was sent to the "netmod" list. I don't understand why Niu Ye's response doesn't appear. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. Shepherd: No IPR disclosure has been filed that references this document. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Shepherd: WG consensus behind this document is very solid. The WG as a whole understands and agrees with it. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) Shepherd: No one has threatened an appeal or otherwise indicated discontent (extreme or otherwise). (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Shepherd: Idnits was tested against -10, which led to the publication of -11. Currently the "very verbose" mode returns one warning and one comment: 1) The warning: == Missing Reference: 'RFC8573' is mentioned on line 419, but not defined 'provision [RFC8573];...' Is a non-issue because the "reference" appears in the Change Log section that will be removed by RFC Editor. 2) The comment: -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with ' ' and |
2020-02-17
|
12 | Kent Watsen | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 1 November 2019. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. Working Group Summary: Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Document Quality: Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. (13) Have all references within this document been identified as either normative or informative? (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? |
2020-02-17
|
12 | Kent Watsen | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2020-02-16
|
12 | Qin Wu | New version available: draft-ietf-netmod-factory-default-12.txt |
2020-02-16
|
12 | (System) | New version approved |
2020-02-16
|
12 | (System) | Request for posting confirmation emailed to previous authors: Ye Niu , Qin WU , Balazs Lengyel |
2020-02-16
|
12 | Qin Wu | Uploaded new revision |
2020-02-12
|
11 | Qin Wu | New version available: draft-ietf-netmod-factory-default-11.txt |
2020-02-12
|
11 | (System) | New version approved |
2020-02-12
|
11 | (System) | Request for posting confirmation emailed to previous authors: Ye Niu , Qin WU , Balazs Lengyel |
2020-02-12
|
11 | Qin Wu | Uploaded new revision |
2020-02-09
|
10 | Qin Wu | New version available: draft-ietf-netmod-factory-default-10.txt |
2020-02-09
|
10 | (System) | New version approved |
2020-02-09
|
10 | (System) | Request for posting confirmation emailed to previous authors: Ye Niu , Qin WU , Balazs Lengyel |
2020-02-09
|
10 | Qin Wu | Uploaded new revision |
2019-12-06
|
09 | Qin Wu | New version available: draft-ietf-netmod-factory-default-09.txt |
2019-12-06
|
09 | (System) | New version accepted (logged-in submitter: Qin Wu) |
2019-12-06
|
09 | Qin Wu | Uploaded new revision |
2019-12-04
|
08 | Qin Wu | New version available: draft-ietf-netmod-factory-default-08.txt |
2019-12-04
|
08 | (System) | New version approved |
2019-12-04
|
08 | (System) | Request for posting confirmation emailed to previous authors: Ye Niu , Qin WU , Balazs Lengyel |
2019-12-04
|
08 | Qin Wu | Uploaded new revision |
2019-11-27
|
07 | Carl Moberg | Request for Last Call review by YANGDOCTORS Completed: Ready with Nits. Reviewer: Carl Moberg. Sent review to list. |
2019-11-17
|
07 | Qin Wu | New version available: draft-ietf-netmod-factory-default-07.txt |
2019-11-17
|
07 | (System) | New version approved |
2019-11-17
|
07 | (System) | Request for posting confirmation emailed to previous authors: Ye Niu , Qin WU , Balazs Lengyel |
2019-11-17
|
07 | Qin Wu | Uploaded new revision |
2019-11-03
|
06 | Qin Wu | New version available: draft-ietf-netmod-factory-default-06.txt |
2019-11-03
|
06 | (System) | New version accepted (logged-in submitter: Qin Wu) |
2019-11-03
|
06 | Qin Wu | Uploaded new revision |
2019-11-01
|
05 | Mehmet Ersue | Request for Last Call review by YANGDOCTORS is assigned to Carl Moberg |
2019-11-01
|
05 | Mehmet Ersue | Request for Last Call review by YANGDOCTORS is assigned to Carl Moberg |
2019-11-01
|
05 | Kent Watsen | IETF WG state changed to In WG Last Call from WG Document |
2019-11-01
|
05 | Kent Watsen | This document now replaces draft-wu-netmod-factory-default instead of None |
2019-11-01
|
05 | Kent Watsen | Requested Last Call review by YANGDOCTORS |
2019-10-31
|
05 | Qin Wu | New version available: draft-ietf-netmod-factory-default-05.txt |
2019-10-31
|
05 | (System) | New version approved |
2019-10-31
|
05 | (System) | Request for posting confirmation emailed to previous authors: Ye Niu , Qin WU , Balazs Lengyel |
2019-10-31
|
05 | Qin Wu | Uploaded new revision |
2019-10-27
|
04 | Qin Wu | New version available: draft-ietf-netmod-factory-default-04.txt |
2019-10-27
|
04 | (System) | New version approved |
2019-10-27
|
04 | (System) | Request for posting confirmation emailed to previous authors: Ye Niu , Qin WU , Balazs Lengyel |
2019-10-27
|
04 | Qin Wu | Uploaded new revision |
2019-09-20
|
03 | Kent Watsen | Notification list changed to Kent Watsen <kent+ietf@watsen.net> |
2019-09-20
|
03 | Kent Watsen | Document shepherd changed to Kent Watsen |
2019-09-10
|
03 | Qin Wu | New version available: draft-ietf-netmod-factory-default-03.txt |
2019-09-10
|
03 | (System) | New version approved |
2019-09-10
|
03 | (System) | Request for posting confirmation emailed to previous authors: Ye Niu , Qin Wu , Balazs Lengyel |
2019-09-10
|
03 | Qin Wu | Uploaded new revision |
2019-06-29
|
02 | Qin Wu | New version available: draft-ietf-netmod-factory-default-02.txt |
2019-06-29
|
02 | (System) | New version approved |
2019-06-29
|
02 | (System) | Request for posting confirmation emailed to previous authors: Ye Niu , Qin Wu , Balazs Lengyel |
2019-06-29
|
02 | Qin Wu | Uploaded new revision |
2019-05-17
|
01 | Qin Wu | New version available: draft-ietf-netmod-factory-default-01.txt |
2019-05-17
|
01 | (System) | New version approved |
2019-05-17
|
01 | (System) | Request for posting confirmation emailed to previous authors: Ye Niu , Qin Wu , Balazs Lengyel |
2019-05-17
|
01 | Qin Wu | Uploaded new revision |
2019-05-16
|
00 | Qin Wu | New version available: draft-ietf-netmod-factory-default-00.txt |
2019-05-16
|
00 | (System) | WG -00 approved |
2019-05-16
|
00 | Qin Wu | Set submitter to "Qin Wu ", replaces to (none) and sent approval email to group chairs: netmod-chairs@ietf.org |
2019-05-16
|
00 | Qin Wu | Uploaded new revision |