Kent Watsen <[email protected]> wrote: > 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
Or just remove "all". > 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>. Ok. > 3) I'm okay with this. I agree that the proposed TOC changes are better. > 4) This is better. Agreed. /martin > > > Thanks, > Kent > > > > On 9/11/17, 11:22 AM, "Robert Wilton" > <[email protected]<mailto:[email protected]>> 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 [email protected] https://www.ietf.org/mailman/listinfo/netmod
