Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04

[Martin Bjorklund <[e-mail]>]

Kent Watsen <[e-mail]> 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"
> <[e-mail]<mailto:[e-mail]>> 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