There have been no objections to proposed changes (1), (3) and (4) so we
will apply those to the draft.
(2) is still awaiting further comment from the latest updated text that
I sent yesterday.
Thanks,
Rob
On 11/09/2017 16:22, Robert Wilton 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
