[netmod] Summary of issues for WG LC for draft-ietf-netmod-revised-datastores-04
Hi, Here is the status, and proposed resolution, of all the issues tracked on github for the WG LC of the revised datastores draft: https://github.com/netmod-wg/datastore-dt/issues Proposed text has been sent to the WG alias for all the open issues except the move to the RFC 2119 language and the updated introduction. I think that these 2 changes would be best be reviewed once all of WG feedback has been incorporated into the draft and a new version posted for the WG to verify that all concerns have been addressed. #1 Define "inactive configuration" Resolution: Proposal is that this issue is also covered by #5. #2 Emphasize that the schema for all conventional datastores must be the same Resolution: Proposed text accepted, draft updated, issue closed. #3 Enhance description of intended datastore Resolution: Proposed text sent to WG, draft will be updated. #4 Make convention datastores a subsection of conventional Resolution: Change accepted, draft updated, issue closed. #5 Provide a better introduction to justify the architecture Resolution: Change accepted, draft will be updated. #6 Describe validation Resolution: Proposed text defining sent to WG, draft will be updated. #7 Other cosmetic improvements proposed by Phil Resolution: Change accepted, draft updated, issue closed. #8 Allow the system to add configuration to Resolution: No change to the draft, issue will be closed. #9 Make it clear that validation of intended includes default values Resolution: Covered by propose text for issue #3, issue will be closed. #10 Is it allowed to violate uniqueness of key values? Resolution: Proposed text sent to WG, draft will be updated. #11 actions and rpcs should be allowed to include other datastores in their XPath evaluation. Resolution: Out of scope, issue will be closed. #12 Appendix minor comments Resolution: Change accepted, draft updated, issue closed. #13 Does the NMDA architecture need to update 7950? Resolution: Yes, document updated, issue closed. #14 Does the NMDA architecture need to use RFC 2119 language? Resolution: Yes, document will be updated. #15 How can a client determine that a module is NMDA compatible? Resolution: No change required, issue will be closed. #16 Remove "commonly" from datastore definition sentences. Resolution: New. Currently plan to accept the proposed change. Thanks, Rob ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Comments on NMDA-04
Hi, Regarding the issue "Is it allowed to violate uniqueness of key values?", https://github.com/netmod-wg/datastore-dt/issues/10 We have discussed this further, and would like to extend the text in the draft to explicitly allow key uniqueness to be violated! We have thought of several cases where it is possible that duplicate entries could appear, and we don't want to force any overhead on the device to guarantee that this does not occur, nor do we want to force synchronization between configuration processing and what is reported in . Of course, in normal circumstances this constraint, like the others, should not be violated. This is already stated in the draft. Examples of where uniqueness of list keys could be violated include: 1) If a device is internally paging the results back for a long list, then it is possible that a entry could have been reported near the beginning of the list, then moved, and then reported again at the end of the list. 2) If the list being stored somewhere in the system has become corrupted and contains duplicate entries. It is better to return truth. 3) On a distributed system where the list is being constructed from multiple nodes (e.g. linecards or peer devices) then if a list entry is moved from one node to another then it is again possible that an entry could be reported in both places (or neither) for a short interval before the system becomes consistent again. Proposed text: OLD: SHOULD conform to any constraints specified in the data model, but given the principal aim of returning "in use" values, it is possible that constraints MAY be violated under some circumstances, e.g., an abnormal value is "in use", or due to remnant configuration (see Section 4.3.1). Note, that deviations are still used when it is known in advance that a device does not fully conform to the schema. Only semantic constraints MAY be violated, these are the YANG "when", "must", "mandatory", "unique", "min-elements", and "max-elements" statements. NEW: SHOULD conform to any constraints specified in the data model, but given the principal aim of returning "in use" values, it is possible that constraints MAY be violated under some circumstances, e.g., an abnormal value is "in use", the structure of a list is being modified, or due to remnant configuration (see Section 4.3.1). Note, that deviations are still used when it is known in advance that a device does not fully conform to the schema. Only semantic constraints MAY be violated, these are the YANG "when", "must", "mandatory", "unique", "min-elements", and "max-elements" statements; and the uniqueness of key values. Again, if there are no objections, I will apply this change. Thanks, Rob On 14/09/2017 16:44, Balazs Lengyel wrote: See below ! On 2017-09-14 16:32, Martin Bjorklund wrote: CH 4.4.) "Validation is performed on the contents of ." This to me means that default data is not considered at validation Note that RFC 7950, section 6.4.1, says: In the accessible tree, all leafs and leaf-lists with default values in use exist (see Sections 7.6.1 and 7.7.2). So defaults are taken into account when intended is validated. BALAZS: Yes the two seem to contradict each other. This can be understood in your way, however the current text is not clear enough. I would add: Validation is performed on the contents of (EXTENDED WITH DEFAULT CONFIGURATION). which would be a backwards incompatible change. Also if validation does not consider system configured data that would allow cases like multiple interfaces named lo0. One from one from system configuration. IMHO while it is OK to violate uniqueness because of remnant data, the above violation of uniqueness seems a bad idea. If your system adds data to , or to , it will be validated. Ch. 4.7) Is it allowed to violate uniqueness of key values? IMHO it should not be. Agreed. Note that the draft explicitly lists the constraints that can be violated, and uniqueness of keys is not listed. BALAZS: If that is the intent I would propose to explicitly state it. For me it was non-trivial. Can a a choice statement be violated? Having to existing branches at the same time? It seems a semantic constraint to me. IMHO yes. Can an if-feature be violated? If support has just changed and we have some remnant config, I can very well imagine it violated. Also here could you change If a node in does not meet the syntactic constraints then it cannot be returned to If a node in does not meet the syntactic constraints then it MUST NOT be returned /martin ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] vs
On 28/09/2017 16:39, t.petch wrote: Robert I would like you to tweak the definition of running configuration datastore slightly. You say " The running configuration datastore () is a configuration datastore that holds the complete current configuration on the device" which I see as black and white, the terminology is . But then you say "This datastore is commonly referred to as "". 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 "". Yes. fine with me. We should also make the equivalent update for the other datastore definitions as well. Thanks, Rob Black and white. Tom Petch - Original Message - From: "Robert Wilton" Sent: Thursday, September 28, 2017 10:37 AM After comment from the other authors, an updated proposed description for is as follows: OLD: 4.3. The Running Configuration Datastore () The running configuration datastore () 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 and non-volatile is available, the device will typically use that non-volatile storage to allow to persist across reboots. NEW: 4.1.3. The Running Configuration Datastore () The running configuration datastore () 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, MUST always be a 'valid configuration data tree' as defined in Section 8.1 of [RFC7950]. MUST be supported if the device can be configured via conventional configuration datastores. If a device does not have a distinct and non-volatile is available, the device will typically use that non-volatile storage to allow to persist across reboots. Given that the definition of and 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 "". 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 "". 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 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 and 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 - holds the complete current configuration on the device. I agree. - This could include inactiveconfiguration I agree. - 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 ina
Re: [netmod] vs
Robert I would like you to tweak the definition of running configuration datastore slightly. You say " The running configuration datastore () is a configuration datastore that holds the complete current configuration on the device" which I see as black and white, the terminology is . But then you say "This datastore is commonly referred to as "". 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 "". Black and white. Tom Petch - Original Message - From: "Robert Wilton" Sent: Thursday, September 28, 2017 10:37 AM > > After comment from the other authors, an updated proposed description > for is as follows: > > OLD: > > 4.3. The Running Configuration Datastore () > > The running configuration datastore () 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 and non-volatile is > available, the device will typically use that non-volatile storage to > allow to persist across reboots. > > NEW: > > 4.1.3. The Running Configuration Datastore () > > The running configuration datastore () 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, MUST always be a 'valid > configuration data tree' as defined in Section 8.1 of [RFC7950]. > >MUST be supported if the device can be configured via > conventional configuration datastores. > > If a device does not have a distinct and non-volatile is > available, the device will typically use that non-volatile storage to > allow to persist across reboots. > > > Given that the definition of and 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 "". > > 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 "". > > > > 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 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 and 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 > >> > >> - holds the complete current configuration on the device. > > I agree. > > > >> > >> - This could include inactiveconfiguration > > I agree. > > > >> > >> - 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 configurat
Re: [netmod] draft-ietf-tictoc-1588v2-yang-05 - Concern over port identifier
Jiangyuanlong wrote:
> Sean,
>
> My personal opinion is that it can work, but I would like to ask for
> more opinions from our netmod experts;)
>
> Hi netmod experts,
> Considering the following sample module, my-list is a list, and it
> needs to use a leaf member "port-number" in my-port-container as a
> key.
> We now have 3 options:
> 1.
> list my-list {
> key "port-number";
> leaf port-number {
>type uint16;
> }
>
> container my-port-container {
> leaf port-number {
> type uint16;
> }
> leaf other-leaf {
>...
> }
> }
> }
> But this does not work for there is compiling error.
Why wouldn't this work?
I suspect you meant:
list my-list {
key "port-number";
container my-port-container {
leaf port-number {
type uint16;
}
leaf other-leaf {
...
}
}
}
> 2.
> list my-list {
> key "port-number";
> leaf port-number {
>type uint16;
> }
> container my-port-container {
> leaf port-number {
> type leafref{
> path "../../port-number";
> }
> }
> leaf other-leaf {
>...
> }
> }
> }
> Option 2 can parse, though leafref in a sub-module seems not very
> natural.
>
> 3.
> list my-list {
> key "port-number";
> leaf port-number {
>type leafref{
> path "../my-port-container/port-number";
>}
> }
> container my-port-container {
> leaf port-number {
> type uint16;
> }
> leaf other-leaf {
>...
> }
> }
> }
>
> Option 3 can also parse, though leafref seems not a very natural
> key. What is your favorite option? Or do you have any better schemes?
Having a leafref like in option 2 or 3 is just redundant and a hassle
for the client. In order to create a a list entry, the client would
have to first provide the port-number value once for the key, and then
again the exact same value in the container:
25
25
...
Note that both "port-number" MUST be given the exact same value by the
client.
In YANG, key leafs cannot be nested under containers. I would simply
have the key on the top of the list, and not in the container.
(It seems this is what others have proposed as well in this thread.)
/martin
> Your opinions are very important for our revision of this draft.
>
> Thanks,
> Yuanlong
>
>
> From: Sean Condon [mailto:sean.con...@microsemi.com]
> Sent: Wednesday, September 27, 2017 7:11 PM
> To: Jiangyuanlong
> Cc: tic...@ietf.org; Rodney Cummings
> Subject: RE: draft-ietf-tictoc-1588v2-yang-05 - Concern over port
> identifier
>
> Thanks guys for your responses.
>
> I accept your points to keep the structure as aligned to the IEEE 1588
> standard as possible.
>
> One alternate suggestion that I would make, is that the port-number
> currently defined as leafref should be made the real attribute
> (i.e. uint16) and that the port-number inside port-identity container
> should be made in to the leaf ref (and set to mandatory true).
>
> The reason I say this is that
>
> 1. XML models are usually navigated and constructed root-to-leaf, and
> the way it's portrayed at the moment is that port-number leafref
> points to something that may not exist at the time it is being
> defined. This makes it difficult to implement.
> 2. Also port-identity/port-number is not "mandatory true" meaning
> that it could be left out altogether. It's not valid for it to have a
> default value either since every item in the list will need a
> different identifier.
>
> With this suggestion the structure you require with port-identity
> still exists, but now the implementation is more straightforward, and
> the change will be transparent to an end user.
>
>
> Best regards, Sean
> ===
> Sean Condon
> System & Software Architect
> Frequency & Timing Division
> Microsemi Inc.
> sean.con...@microsemi.com
>
>
> From: Jiangyuanlong [jiangyuanl...@huawei.com]
> Sent: 27 September 2017 08:05
> To: Sean Condon
> Cc: tic...@ietf.org; Rodney Cummings
> Subject: RE: draft-ietf-tictoc-1588v2-yang-05 - Concern over port
> identifier
> EXTERNAL EMAIL
>
> Dear Sean,
>
>
>
> Thank you a lot for diving into the technical details of this
> module. Just as Rodney said, it is a challenge of 1588 info model to
> YANG, and we use the leafref of YANG to work around it.
>
> I would like to provide a little more backgrounds on the tradeoff:
>
>
>
> 1. It says in Sec. 7.5.2.1 in IEEE 1588-2008: portIdentity is a member
> of the portDS data set. A portIdentity consists of two attributes, as
>
> follows:
>
> ⎯ portIdentity.clockIdentity
>
> ⎯ portIdentity.portNumber
>
> Furthermore, the "portDS.portIdentity" attri
Re: [netmod] Comments on NMDA-04
Hi, This is regarding issue (https://github.com/netmod-wg/datastore-dt/issues/11): actions and rpcs should be allowed to include other datastores in their XPath evaluation There has been no further discussion of this issue after Martin's reply, and this seems to be out of scope for the NMDA draft. Hence the authors proposal is to close this issue with no change to the draft. Thanks, Rob On 14/09/2017 15:32, Martin Bjorklund wrote: Hi Balazs, Thanks for your review. Comments inline. Balazs Lengyel wrote: Ch 5.1) IMHO actions and rpcs should be allowed to include other datastores in their XPath evaluation. My suggestion is that they need to specify it somehow. (Yang extension?) This is something that the WG has discussed in the past as well, but so far no concrete proposal has been made. I think such extensions can be done in a separate document in the future, or maybe if we do a new version of YANG. But note that for rpc and action, this section only talks about XPath in input/output parameters. ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04 guessing
The authors have discussed this issue (https://github.com/netmod-wg/datastore-dt/issues/15), and their proposal is to close this with no change to the NMDA draft with the following justifications: 1) This assumption is that longer term all models would become NMDA compliant and over time it would likely require that all modules would need to have this extension added, creating a CLR. 2) Defining the extension would take time, and further delay the IETF standardization of YANG models, but it is important that IETF actually gets standard YANG models published as quickly as possible so that they can be implemented by the industry. 3) NMDA devices can implement "non NMDA style" modules (but with duplication of state), and non NMDA devices can implement "NMDA style" modules (but with reduced functionality). 4) YANG Catalog can identify what type of style a particular module is, by using some heuristically analysis of the structure of the model. Thanks, Rob On 15/09/2017 13:21, Martin Bjorklund wrote: Ladislav Lhotka wrote: t.petch píše v Pá 15. 09. 2017 v 12:29 +0100: Looking at a YANG module in future, how can I tell whether or not it is written to work with revised datastores? Ideally, this ought to be a wrong question. A YANG module (or rather a YANG data model) should specify constraints for a data tree, no matter where the tree happens to reside. I agree, and an old module can be implemented in an NMDA-compatible server (with some redundant info), and a new modules can be implemented in a non-NMDA-compatible server (with limited functionality). But the truth is that modules are and will be designed to fit into some environment (or "meta model"). For example, with NMDA, there will be a single tree. If we had an annotation for "comments" on nodes, you wouldn't see any leafs called "description". If we didn't have the ability to create things in the protocol, our models would have objects of type "RowStatus". Etc. /martin Coupling a data modelling language with rather specific aspects of an NM application is a bad design. Lada If the module is written assuming revised datastores and the environment does not support this in some regard, then we have a management malfunction, which could be disastrous. I think that there should be some mechanistic way, something that can be automated, for a system to check whether or not a module is assuming revised datastores or not. This is a bit like the change from YANG 1.0 to YANG 1.1; there needs to be a way of telling what environment the module is written for, and so we have the yang-version 1.1; statement. Revised datastores needs something similar in the module. Tom Petch - Original Message - From: "Lou Berger" Sent: Friday, September 01, 2017 10:02 PM 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 netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 ___ 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 . ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Adding system configuration to running [was: Re: Comments on NMDA-04]
Hi, This is regarding the question as to whether it should be allowed for a system to manipulate : This issue isn't really specific to the NMDA architecture, and there is no consensus on whether this should be allowed. Hence, the proposal is that the NMDA architecture draft be completely silent on this, neither endorsing this behaviour, not restricting it. Hence no changes to the NMDA architecture draft are required for this issue. However, I have added an FAQ entry to clarify that this being is not prevented, but pointing out some of the potential downsides to a device doing this. The FAQ entry is https://github.com/netmod-wg/FAQ/wiki/FAQ-related-to-NMDA-implementations#Q9 Unless I hear otherwise, I propose closing this issue (https://github.com/netmod-wg/datastore-dt/issues/8). Comments/review of the FAQ text is also welcome. Thanks, Rob On 14/09/2017 18:08, Robert Wilton wrote: On 14/09/2017 16:35, Balazs Lengyel wrote: See below! On 2017-09-14 16:32, Martin Bjorklund wrote: Hi Balazs, Thanks for your review. Comments inline. Balazs Lengyel wrote: Hello, Reading the draft-ietf-netmod-revised-datastores-04 some comments: General) The system often adds data to the or datastore already not just to : e.g. UC1: I have a server configured in running. I need to bind it to an ip-address. The ip-address might be the local loopback address, however if that is only added to , validation will fail indicating that the server is bound to a non-existent address. How to handle this? UC2: I have a set of capabilities set by the system e.g. supported-reporting-intervals. I need to configure a job that MUST use one of these intervals. If the supported-reporting-intervals are only added to I can not validate the selected-interval in my configured job. My proposal is to allow the system to add data to running as well. Actually I think that is a more relevant case then adding configuration just to . I think the consensus is that in general it is a bad idea if servers (spontaneously) add data to . However, there is nothing in the new or old architectures that prohibits this. BALAZS: I strongly disagree. I know others are also adding stuff to running as well. IMHO the above use cases are real and used and actually important for us. I would like to see them included in some way. I basically agree with Martin here. The architecture is cleaner if is only written by the client. This avoid requiring clients tracking unexpected changes to running, and opens up the possibility of validating configuration off the box. Ideally extra stuff should be added into and then become visible in . I understand that some systems add data to , and this is fine. But I think that it is better for an architecture document to be silent on this point. Thanks, Rob regards Balazs -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist Mobile: +36-70-330-7909 email:balazs.leng...@ericsson.com ___ 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 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] vs
Hi, After comment from the other authors, an updated proposed description for is as follows: OLD: 4.3. The Running Configuration Datastore () The running configuration datastore () 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 and non-volatile is available, the device will typically use that non-volatile storage to allow to persist across reboots. NEW: 4.1.3. The Running Configuration Datastore () The running configuration datastore () 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, MUST always be a 'valid configuration data tree' as defined in Section 8.1 of [RFC7950]. MUST be supported if the device can be configured via conventional configuration datastores. If a device does not have a distinct and non-volatile is available, the device will typically use that non-volatile storage to allow to persist across reboots. Given that the definition of and 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 "". 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 "". 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 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 and 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 - holds the complete current configuration on the device. I agree. - This could include inactiveconfiguration I agree. - 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" Sent: Friday, September 22, 2017 10:03 AM Hi, Regarding whether is always valid, the proposed modification to the draft is to add the following text to section 4.3 that describes : OLD: 4.3. The Running Configuration Datastore () The running configuration datastore () 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 and non-volatile is available, the device will typically use that non-volatile storage to allow to persist across reboots. NEW: 4.3. The Running Configuration
