Robert I would like you to tweak the definition of running configuration datastore slightly.
You say " The running configuration datastore (<running>) is a configuration datastore that holds the complete current configuration on the device" which I see as black and white, the terminology is <running>. But then you say "This datastore is commonly referred to as "<running>". which I see as introducing wiggle room with the use of 'commonly' so I would like you to excise 'commonly' leaving NEW This datastore is referred to as "<running>". Black and white. Tom Petch ----- Original Message ----- From: "Robert Wilton" <rwil...@cisco.com> Sent: Thursday, September 28, 2017 10:37 AM > > After comment from the other authors, an updated proposed description > for <running> is as follows: > > OLD: > > 4.3. The Running Configuration Datastore (<running>) > > The running configuration datastore (<running>) holds the complete > current configuration on the device. It may include inactive > configuration or template-mechanism-oriented configuration that > require further expansion. > > If a device does not have a distinct <startup> and non-volatile is > available, the device will typically use that non-volatile storage to > allow <running> to persist across reboots. > > NEW: > > 4.1.3. The Running Configuration Datastore (<running>) > > The running configuration datastore (<running>) is aconfiguration > datastore that holds the complete current configuration > on the device. It may include configuration that requires further > transformation before it can be applied, e.g., inactive > configuration, or template-mechanism-oriented configuration that > needs further expansion. However, <running> MUST always be a 'valid > configuration data tree' as defined in Section 8.1 of [RFC7950]. > > <running> MUST be supported if the device can be configured via > conventional configuration datastores. > > If a device does not have a distinct <startup> and non-volatile is > available, the device will typically use that non-volatile storage to > allow <running> to persist across reboots. > > > Given that the definition of <running> and <intended> are being updated, > I think that the definitions should similarly be updated. Hence I propose: > > > > OLD: > o running configuration datastore: A configuration datastore holding > the current configuration of the device. It may include inactive > configuration or template-mechanism-oriented configuration that > require further expansion. This datastore is commonly referred to > as "<running>". > > NEW (based on the new description of running above): > o running configuration datastore: A configuration datastore holding > the current configuration of the device. It may include > configuration that requires furthertransformations before it can > be applied. This datastore is commonly referred to > as "<running>". > > > > OLD: > > o intended configuration: Configuration that is intended to be used > by the device. For example, intended configuration excludes any > inactive configuration and it would include configuration produced > through the expansion of templates. > > > NEW (based on the proposed updated description of intended): > > o intended configuration: Configuration that is intended to be used > by the device. It represents the configuration after all > configuration transformations to <running> have been performed and > is the configuration that the system attempts to apply. > > > > It may also be helpful if we define "configuration transformation", or > would that be better captured in the introduction text? > > A possible definition could be along the lines of: > > configuration transformation: The addition, modification or removal of > configuration between the <running> and <intended> datastores. > Examples of configuration transformations include the removal of > inactive configuration and the configuration produced through the > expansion of templates. > > If I don't hear anything back, I'll take that as a tacit approval of > these proposed changes. > > Thanks, > Rob > > > On 22/09/2017 18:12, Robert Wilton wrote: > > Hi Tom, > > > > > > On 22/09/2017 17:34, t.petch wrote: > >> Robert > >> > >> I wonder if this says the opposite of what is intended > >> > >> - <running> holds the complete current configuration on the device. > > I agree. > > > >> > >> - This could include inactiveconfiguration > > I agree. > > > >> > >> - <running> must always be a 'valid configuration data tree' as > >> defined in Section 8.1 of [RFC7950]. > > I agree. > > > >> > >> Ergo, inactiveconfiguration must form part of a valid configuration > >> tree. > > > > Ergo, inactive configuration can form part of a valid configuration > > tree. > > > >> > >> I thought the idea was that inactiveconfiguration was logically removed > >> before validation but this seems to state the opposite.. > > I don't think that this is necessarily true. One choice is inactive > > configuration is removed before validation, but this isn't quite what > > I'm proposing. I'm proposing that the act of validation itself is > > refined (via an tbd inactive configuration draft) such that it ignores > > configuration nodes marked as inactive. > > > > Thanks, > > Rob > > > >> > >> Tom Petch > >> > >> ----- Original Message ----- > >> From: "Robert Wilton" <rwil...@cisco.com> > >> Sent: Friday, September 22, 2017 10:03 AM > >> > >>> Hi, > >>> > >>> Regarding whether <running> is always valid, the proposed modification > >>> to the draft is to add the following text to section 4.3 that > >> describes > >>> <running>: > >>> > >>> OLD: > >>> > >>> 4.3. The Running Configuration Datastore (<running>) > >>> > >>> The running configuration datastore (<running>) holds the complete > >>> current configuration on the device. It may include inactive > >>> configuration or template-mechanism-oriented configuration that > >>> require further expansion. > >>> > >>> If a device does not have a distinct <startup> and non-volatile is > >>> available, the device will typically use that non-volatile storage > >> to > >>> allow <running> to persist across reboots. > >>> > >>> NEW: > >>> > >>> 4.3. The Running Configuration Datastore (<running>) > >>> > >>> The running configuration datastore (<running>) holds the complete > >>> current configuration on the device. This could, for example, > >> include > >>> inactiveconfiguration or template-mechanism-oriented configuration > >>> thatrequires further expansion.However, <running> must always be a > >>> 'valid configuration data tree' as defined in Section 8.1 of > >> [RFC7950]. > >>> If a device does not have a distinct <startup> and non-volatile is > >>> available, the device will typically use that non-volatile storage > >> to > >>> allow <running> to persist across reboots. > >>> > >>> END > >>> > >>> > >>> Then the intention is that if inactive or a templating solution is > >>> standardized then those drafts would update the validation rules in > >> RFC > >>> 7950 such that <running> is still valid. E.g. an inactive config draft > >>> would probably indicate that validation excludes all configuration > >> nodes > >>> that are marked as inactive. > >>> > >>> Does anyone have any comments? > >>> > >>> Do we also need to state that <startup> must always be a 'valid > >>> configuration data tree'? > >>> > >>> Thanks, > >>> Rob > >>> > >>> > >>> On 19/09/2017 16:22, Robert Wilton wrote: > >>>> > >>>> On 19/09/2017 10:55, Martin Bjorklund wrote: > >>>>> Robert Wilton <rwil...@cisco.com> wrote: > >>>>>> On 18/09/2017 19:25, Andy Bierman wrote: > >>>>>>> On Mon, Sep 18, 2017 at 11:07 AM, Martin Bjorklund > >> <m...@tail-f.com > >>>>>>> <mailto:m...@tail-f.com>> wrote: > >>>>>>> > >>>>>>> Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de > >>>>>>> <mailto:j.schoenwael...@jacobs-university.de>> wrote: > >>>>>>>> On Mon, Sep 18, 2017 at 05:17:46PM +0100, Robert Wilton wrote: > >>>>>>>>>> No. I do not agree that the MUST in RFC 7950 can be > >>>>>>> removed. > >>>>>>>>>> I do not agree the architecture should update YANG at all. > >>>>>>>>> OK. > >>>>>>>> I am with Andy here. <running> has always had the > >>>>>>> requirement to be > >>>>>>>> valid and we are not supposed to change that. Mechanisms for > >>>>>>> inactive > >>>>>>>> configuration or templating must be designed to be backwards > >>>>>>> compatible > >>>>>>>> I think. > >>>>>>> Ok. If we keep the requirement that <running> in itself must be > >>>>>>> valid, it just restricts the usefulness/expressiveness of > >>>>>>> inactive and > >>>>>>> template mechanisms, but it might be ok. > >>>>>>> > >>>>>>> I think that even w/o this requirement, the observable > >>>>>>> behavior for a > >>>>>>> client can be backwards compatible. For example, suppose we > >>>>>>> have an > >>>>>>> inactive access control rule that refers to a non-existing > >>>>>>> interface in > >>>>>>> <running>. If a client that doesn't know anything about > >>>>>>> inactive asks > >>>>>>> for the contents of <running>, our implementation removes the > >>>>>>> inactive > >>>>>>> nodes from the reply to the client. Only a client that > >>>>>>> opts-in to > >>>>>>> inactive will receive a reply with things that looks invalid > >>>>>>> if you > >>>>>>> don't take the inactive annotation into account. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> There are many ways that validation can fail because inactive > >> nodes > >>>>>>> are present, > >>>>>>> and considered part of the validation. > >>>>>>> > >>>>>>> e,g, min-elements, max-elements, mandatory, unique. > >>>>>>> > >>>>>>> I think we all agree that validation on the enabled nodes is > >> supposed > >>>>>>> to continue to work. > >>>>> Yes. > >>>>> > >>>>>>> Here is an attempt at a backwards-compatible solution: > >>>>>>> > >>>>>>> 1) current <get-config> and <get> responses only include enabled > >>>>>>> nodes. > >>>>>>> 2) old-style <edit-config> operations do not alter inactive nodes > >>>>>>> 3) NMDA clients use <get-data>, not <get-config> or <get>. These > >>>>>>> responses > >>>>>>> include enabled and disabled nodes, so validation does not apply > >>>>>>> for <running> > >>>>>>> 4) new style <edit-config> (i.e. <datastore> parameter used) can > >> alter > >>>>>>> any type of data node > >>>>>> //I think that inactive should always be an optional extension. > >> Not > >>>>>> everything needs the additional complexity. > >>>>>> > >>>>>> Hence rather than tying this function to specific NETCONF > >> operations, > >>>>>> I would suggest that there should be an extra parameter (like for > >>>>>> with-defaults) to allow a client to indicate to the server that a > >> get > >>>>>> or edit request is using the "with-inactive" extension. > >>>>>> 1) The server should also have a capability (or perhaps a leaf > >> defined > >>>>>> in YANG library) to indicate that it supports inactive > >> configuration. > >>>>>> 2) If a client doesn't use the extra "with-inactive" parameter > >> during > >>>>>> a get request then only active nodes are returned. > >>>>>> 3) If a client doesn't use the extra "with-inactive" parameter > >> during > >>>>>> an edit-data request then the request cannot include an extra > >> inactive > >>>>>> meta-data. The request is processed in a way that is equivalent to > >> an > >>>>>> existing NETCONF implementation, but it may unknowingly remove > >> some > >>>>>> inactive configuration (e.g. via a replace or remove operation on > >> an > >>>>>> inactive node). Operations like create, delete, none, replace > >> should > >>>>>> all treat an inactive target node the same way as in the node > >> doesn't > >>>>>> exist (e.g. delete on an inactive node would return a > >> "data-missing" > >>>>>> error), this ensures that the behaviour that an unaware client > >>>>>> observes is the same as the existing behaviour that it would > >> expect > >>>>>> from a regular 6241 compliant NETCONF implementation. > >>>>>> 4) It a client makes a get request including the "with-inactive" > >>>>>> parameter then they also get the inactive nodes as well, marked > >> with a > >>>>>> meta-data annotation. > >>>>>> 5) If a client makes an edit request including the "with-inactive" > >>>>>> parameter, then the inactive meta-data annotation can be used to > >> label > >>>>>> inactive nodes. Inactive nodes are regarded as regular data nodes > >> for > >>>>>> create/delete/replace/none operation error checking. > >>>>>> > >>>>>> I think that this approach is similar (perhaps even the same) as > >>>>>> Martin described. > >>>>> This is indeed how our implementation works (except I think we > >> don't > >>>>> do 5; if the client sends an "inactive" attribute it doesn't have > >> to > >>>>> also send with-inactive). > >>>>> > >>>>>>> Note that the YANG MUST rule still applies, because validation is > >> only > >>>>>>> done on enabled nodes. > >>>>>>> It is only the response message representations that cannot be > >>>>>>> validated, not the contents > >>>>>>> of <running> on a server. > >>>>> So the question is how we can make sure that the text in the NMDA > >>>>> draft covers this yet-to-be-defined feature w/o having to define it > >>>>> now? We thought that the current text was sufficient, but do we > >> have > >>>>> to make any changes to it? > >>>> 1) Do we also need to illustrate a similar proof of concept > >> templating > >>>> implementation to show that templating could work whilst keeping > >>>> running valid? I would prefer that this is just deferred to > >> whichever > >>>> draft defines templating. > >>>> > >>>> 2) I think that we need to reach a decision as to whether the NMDA > >>>> architecture needs to explicitly state that <running> is always > >> valid, > >>>> or if that can be left to the existing statement in 7950. My > >> thinking > >>>> is that if the conclusion is that <running> must always be valid, > >> then > >>>> it would be helpful to explicitly state it the descriptions of both > >>>> <running> and <startup> in the NMDA architecture. > >>>> > >>>> 3) I think that it would be useful to further refine my previous > >>>> proposed text for intended, particularly rewriting the text on > >>>> validation. This should hopefully also address Balazs' concern about > >>>> default values be included in validation. > >>>> > >>>> <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. > >>>> > >>>> Currently there are no standard mechanisms defined that affect > >>>> <intended> so that it would have different contents than <running>, > >>>> but this architecture allows for such mechanisms to be defined. > >>>> > >>>> One example of such a mechanism is support for marking nodes as > >>>> inactive in <running>. Inactive nodes are not copied to <intended>, > >>>> and are thus not taken into account when validating the > >>>> configuration. > >>>> > >>>> Another example is support for templates. Templates are expanded > >>>> when copied into <intended>, and the expanded result is validated. > >>>> > >>>> </Old> > >>>> <Proposed> > >>>> > >>>> 4.1.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, removal of inactive configuration), and is the > >>>> configuration that the system attempts to apply. > >>>> > >>>> <intended> is tightly coupled to <running>. Whenever data is written > >>>> to <running>, then <intended> is also immediately updated by > >>>> performing all necessary transformations to the contents of > >> <running> > >>>> and then <intended> is validated. > >>>> > >>>> <intended> may also be updated independently of <running> (e.g., if > >>>> one of the configuration transformations is changed), but <intended> > >>>> must always be a 'valid configuration data tree' as defined in > >>>> Section 8.1 of [RFC7950]. > >>>> > >>>> 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 in use by checking > >>>> whether the contents of <intended> also appears in <operational>. > >>>> > >>>> <intended> does not persist across reboots; its relationship with > >>>> <running> makes that unnecessary. > >>>> > >>>> Currently there are no standard mechanisms defined that affect > >>>> <intended> so that it would have different contents than <running>, > >>>> but this architecture allows for such mechanisms to be defined. > >>>> > >>>> One example of such a mechanism is support for marking nodes as > >>>> inactive in <running>. Inactive nodes are not copied to <intended>. > >>>> A second example is support for templates, which can perform > >>>> transformations on the configuration from <running> to the > >>>> configuration written to <intended>. > >>>> > >>>> </Proposed> > >>>> > >>>> Thanks, > >>>> Rob > >>>> > >>>> > >>>>> > >>>>> /martin > >>>>> . > >>>>> > >>>> . > >>>> > >> . > >> > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
