As an author, I believe the draft is ready for publication. Regarding Robert's editorial suggestions:
1) how moving "all" like this? (i.e., must have same modules, deviations, etc.) - datastores that all share exactly the same schema, allowing data to be copied + datastores that share exactly the same schema, allowing all data to be copied 2) better, but I think we should expand "It" in the beginning of the 2nd paragraph to "The intended configuration datastore". Also, how about this for the 3rd paragraph instead? (fixes a couple plurality issues and one transition issue): The contents of <intended> are related to the 'config true' subset of <operational>, such that a client can determine to what extent the intended configuration is currently applied by checking whether the contents of <intended> also appear in <operational>. 3) I'm okay with this. 4) This is better. Thanks, Kent On 9/11/17, 11:22 AM, "Robert Wilton" <rwil...@cisco.com<mailto:rwil...@cisco.com>> wrote: As one of the authors, I would like to see a few minor editorial updates, described below. Otherwise I believe that the document is ready for publication. Proposed changes: 1. I think that the document could further emphasis that the schema for all the conventional datastores must be the same. Old: 4.5. Conventional Configuration Datastores The conventional configuration datastores are a set of configuration datastores that share a common schema, allowing data to be copied between them. The term is meant as a generic umbrella description of these datastores. The set of datastores include: New: 4.5. Conventional Configuration Datastores The conventional configuration datastores are a set of configuration datastores that all share exactly the same schema, allowing data to be copied between them. The term is meant as a generic umbrella description of these datastores. The set of datastores include: 2. I think that the description of the intended datastore could be expanded to give a bit more clarity. OLD: 4.4. The Intended Configuration Datastore (<intended>) The intended configuration datastore (<intended>) is a read-only configuration datastore. It is tightly coupled to <running>. When data is written to <running>, the data that is to be validated is also conceptually written to <intended>. Validation is performed on the contents of <intended>. For simple implementations, <running> and <intended> are identical. <intended> does not persist across reboots; its relationship with <running> makes that unnecessary. ... NEW: 4.4. The Intended Configuration Datastore (<intended>) The intended configuration datastore (<intended>) is a read-only configuration datastore. It represents the configuration after all configuration transformations to <running> are performed (e.g. template expansion, inactive configuration removal), and is the configuration that the system attempts to apply. It is tightly coupled to <running>. When data is written to <running>, the data that is to be validated is also conceptually written to <intended>. Validation is performed on the contents of <intended>. For simple implementations, <running> and <intended> are identical. The contents of <intended> is also related to the 'config true' subset of <operational>, and hence a client can determine to what extent the intended configuration is currently applied by checking whether the contents of <intended> also appears in <operational>. <intended> does not persist across reboots; its relationship with <running> makes that unnecessary. ... 3. I think that it may aid readability if the section on conventional configuration datastores was moved above the description of the individual conventional configuration datastores, which could then be intended one level. Best illustrated via the change to the table of contents. E.g. current TOC: 4. Architectural Model of Datastores . . . . . . . . . . . . . . 8 4.1. The Startup Configuration Datastore (<startup>) . . . . . 9 4.2. The Candidate Configuration Datastore (<candidate>) . . . 10 4.3. The Running Configuration Datastore (<running>) . . . . . 10 4.4. The Intended Configuration Datastore (<intended>) . . . . 10 4.5. Conventional Configuration Datastores . . . . . . . . . . 11 4.6. Dynamic Configuration Datastores . . . . . . . . . . . . 11 4.7. The Operational State Datastore (<operational>) . . . . . 11 4.7.1. Remnant Configuration . . . . . . . . . . . . . . . . 12 4.7.2. Missing Resources . . . . . . . . . . . . . . . . . . 13 4.7.3. System-controlled Resources . . . . . . . . . . . . . 13 4.7.4. Origin Metadata Annotation . . . . . . . . . . . . . 13 Proposed TOC: 4. Architectural Model of Datastores . . . . . . . . . . . . . . 8 4.1. Conventional Configuration Datastores . . . . . . . . . . 9 4.1.1. The Startup Configuration Datastore (<startup>) . . . 10 4.1.2. The Candidate Configuration Datastore (<candidate>) . 10 4.1.3. The Running Configuration Datastore (<running>) . . . 10 4.1.4. The Intended Configuration Datastore (<intended>) . . 11 4.2. Dynamic Configuration Datastores . . . . . . . . . . . . 12 4.3. The Operational State Datastore (<operational>) . . . . . 12 4.3.1. Remnant Configuration . . . . . . . . . . . . . . . . 13 4.3.2. Missing Resources . . . . . . . . . . . . . . . . . . 13 4.3.3. System-controlled Resources . . . . . . . . . . . . . 14 4.3.4. Origin Metadata Annotation . . . . . . . . . . . . . 14 4. Finally, I noticed one reference that could be improved, by changing it from "(described below)" to a proper section reference: 647,648c644,645 < circumstances, e.g., an abnormal value is 'in use', or due to remnant < configuration (described below). Note, that deviations are still --- > circumstances, e.g., an abnormal value is "in use", or due to remnant > configuration (see Section 4.7.1). Note, that deviations are still Thanks, Rob On 01/09/2017 22:02, Lou Berger wrote: All, This starts a two week working group last call on draft-ietf-netmod-revised-datastores-04. The working group last call ends on September 17. Please send your comments to the netmod 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. Thank you, Netmod Chairs
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
