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

[Robert Wilton <[e-mail]>]

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
>>
>>