Hi Andy, I can’t think of a specific problem immediately. But I think it means templates would be considered as “applied” always right ? Or do you see cases where templates don’t show up when <operational> is read ?
Special rules are likely to be needed for validation though. A DS (with templates) won’t be valid unless you validate an exploded view. Jason From: Andy Bierman [mailto:[email protected]] Sent: Thursday, November 02, 2017 16:58 To: Sterne, Jason (Nokia - CA/Ottawa) <[email protected]> Cc: Kent Watsen <[email protected]>; Robert Wilton <[email protected]>; [email protected] Subject: Re: [netmod] revised-datastores and commonality of schemas Hi, On Thu, Nov 2, 2017 at 1:40 PM, Sterne, Jason (Nokia - CA/Ottawa) <[email protected]<mailto:[email protected]>> wrote: Hi Kent, Yeah - I realize that I'm jumping ahead of where we are. I'm a bit worried that we're making forward looking assumptions that we'll be able to stick to those constraints that we're defining in revised-datastores, and we may find that difficult later. For this specific issue I suppose there is at least the possibility that we *could* have a common schema (and have operational be a superset). What problem is caused by having a template appear in <operational> or <intended>? If none (appears that way) then no special rules are needed for templates. What if I have a special RPC to override part of a template, so the operational value of the template is actually different than the configured value? Since it is all proprietary at this point, better to leave templates for later. Rgds, Jason Andy > -----Original Message----- > From: Kent Watsen [mailto:[email protected]<mailto:[email protected]>] > Sent: Thursday, November 02, 2017 16:31 > To: Sterne, Jason (Nokia - CA/Ottawa) > <[email protected]<mailto:[email protected]>>; Robert > Wilton <[email protected]<mailto:[email protected]>>; > [email protected]<mailto:[email protected]> > Subject: Re: [netmod] revised-datastores and commonality of schemas > > Hi Jason, > > All those details would need to be specified by some future templating > drafts. In this draft, there is only the provision for "configuration > transformations" to keep that door open. > > Kent // contributor > > > -- > > Hi guys, > > > > Templates are something that may be problematic for this concept of > common schemas across the running/candidate/intended DSes and then > operational being a superset. > > > > The <running> DS needs to have both the template itself in the schema as > well as whatever nodes are used to hold 'exploded' data. But what about > intended and operational ? > > > > For example, imagine we have the following instance data in a candidate & > running DS: > > 1) a template that sets an admin-state leaf to 'enabled' in all interfaces > > 2) a set of 3 interfaces with a few leafs of config in them (address, etc) > > > > Clearly the schema for the candidate/running DSes contain both the > template and the interface schema nodes. > > > > But does the schema for the intended DS actually have the template schema > nodes ? In theory it doesn't *need* to (since templates are exploded > between running & intended), and it feels strange to have those in there, > but I suppose it could have them. If they are there, then a read of the > intended would show "admin-state enabled" in the template *and* in the 3 > interfaces. > > > > Does the operational DS contain the template schema nodes ? If yes, then I > suppose we would consider all templates as 'applied' implicitly ? > > > > Rgds, > > Jason > > > > > > > -----Original Message----- > > > From: netmod > > [mailto:[email protected]<mailto:[email protected]>] On Behalf > > Of Robert > > > Wilton > > > Sent: Tuesday, October 31, 2017 10:01 > > > To: [email protected]<mailto:[email protected]> > > > Subject: Re: [netmod] I-D Action: draft-ietf-netmod-revised-datastores- > > > 06.txt > > > > > > So this version of the draft contains the small change that defines > "datastore > > > schema" and describes the "datastore schema" of <operational> as being > the > > > superset of the datastore schema for all the configuration datastores. > > > > > > There are two remaining issues open on the issue tracker > > > (https://urldefense.proofpoint.com/v2/url?u=https- > 3A__github.com_netmod-2Dwg_datastore- > 2Ddt_issues&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK- > ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m > =HmlA7hSACCJBmjNombXsdSLxNs5JnF3BrFaYXPWYosg&s=Oh70ToB2vUTvtf > OGlJFxq9b-VdJvIq7Nw6S69fNgcTA&e=): > > > > > > (1) Sign off that usage of RFC 2119 language is appropriate. Perhaps one of > > > the proponents of this change could please verify this. > > > (2) The email thread regarding Actions and RPCs in NMDA. I will send > > > updated proposed text on the appropriate thread. > > > > > > Thanks, > > > Rob > > > > > > > > > On 30/10/2017 18:04, > > [email protected]<mailto:[email protected]> wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > directories. > > > > This draft is a work item of the Network Modeling WG of the IETF. > > > > > > > > Title : Network Management Datastore Architecture > > > > Authors : Martin Bjorklund > > > > Juergen Schoenwaelder > > > > Phil Shafer > > > > Kent Watsen > > > > Robert Wilton > > > > Filename : draft-ietf-netmod-revised-datastores-06.txt > > > > Pages : 38 > > > > Date : 2017-10-30 > > > > > > > > Abstract: > > > > Datastores are a fundamental concept binding the data models written > > > > in the YANG data modeling language to network management > protocols > > > > such as NETCONF and RESTCONF. This document defines an > architectural > > > > framework for datastores based on the experience gained with the > > > > initial simpler model, addressing requirements that were not well > > > > supported in the initial model. > > > > > > > > > > > > The IETF datatracker status page for this draft is: > > > > https://urldefense.proofpoint.com/v2/url?u=https- > 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dnetmod-2Drevised- > 2Ddatastores_&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK- > ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m > =HmlA7hSACCJBmjNombXsdSLxNs5JnF3BrFaYXPWYosg&s=kntbgpHJnrByHY > nP6-gIQawFyxzuB4qqA8a7sJ73Yro&e= > > > > > > > > There are also htmlized versions available at: > > > > https://urldefense.proofpoint.com/v2/url?u=https- > 3A__tools.ietf.org_html_draft-2Dietf-2Dnetmod-2Drevised-2Ddatastores- > 2D06&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK- > ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m > =HmlA7hSACCJBmjNombXsdSLxNs5JnF3BrFaYXPWYosg&s=l8WerMNvfvgZVJ > CnIEqxPofbgMz_Q_EzSiIoGbCQgNI&e= > > > > https://urldefense.proofpoint.com/v2/url?u=https- > 3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dnetmod-2Drevised- > 2Ddatast&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK- > ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m > =HmlA7hSACCJBmjNombXsdSLxNs5JnF3BrFaYXPWYosg&s=WCuOo1niAkysc > QUKzIYmTuLvajFh0jn8MtmRmc6jjho&e= > > > > ores-06 > > > > > > > > A diff from the previous version is available at: > > > > https://urldefense.proofpoint.com/v2/url?u=https- > 3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dnetmod-2Drevised- > 2Ddatastores&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK- > ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m > =HmlA7hSACCJBmjNombXsdSLxNs5JnF3BrFaYXPWYosg&s=L7nQJMiX3M_yX > LSwPASZefUdW7YmA4ly9MiocXVGh40&e= > > > > -06 > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > > > submission until the htmlized version and diff are available at > tools.ietf.org<http://tools.ietf.org>. > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > https://urldefense.proofpoint.com/v2/url?u=ftp- > 3A__ftp.ietf.org_internet- > 2Ddrafts_&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK- > ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m > =HmlA7hSACCJBmjNombXsdSLxNs5JnF3BrFaYXPWYosg&s=e_mQeyXZbxETy > vr0-gcvkPeWqv4mScsFa5ueArTKoQQ&e= > > > > > > > > _______________________________________________ > > > > netmod mailing list > > > > [email protected]<mailto:[email protected]> > > > > https://urldefense.proofpoint.com/v2/url?u=https- > 3A__www.ietf.org_mailman_listinfo_netmod&d=DwIGaQ&c=HAkYuh63rsuh > r6Scbfh0UjBXeMK- > ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m > =HmlA7hSACCJBmjNombXsdSLxNs5JnF3BrFaYXPWYosg&s=L2xQyj_938aVcv4 > QyFMHlNwXkX9tT8L46M1PXc6Lnh4&e= > > > > . > > > > > > > > > > _______________________________________________ > > > netmod mailing list > > > [email protected]<mailto:[email protected]> > > > https://urldefense.proofpoint.com/v2/url?u=https- > 3A__www.ietf.org_mailman_listinfo_netmod&d=DwIGaQ&c=HAkYuh63rsuh > r6Scbfh0UjBXeMK- > ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m > =HmlA7hSACCJBmjNombXsdSLxNs5JnF3BrFaYXPWYosg&s=L2xQyj_938aVcv4 > QyFMHlNwXkX9tT8L46M1PXc6Lnh4&e= > > _______________________________________________ > netmod mailing list > [email protected]<mailto:[email protected]> > https://urldefense.proofpoint.com/v2/url?u=https- > 3A__www.ietf.org_mailman_listinfo_netmod&d=DwIGaQ&c=HAkYuh63rsuh > r6Scbfh0UjBXeMK- > ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m > =HmlA7hSACCJBmjNombXsdSLxNs5JnF3BrFaYXPWYosg&s=L2xQyj_938aVcv4 > QyFMHlNwXkX9tT8L46M1PXc6Lnh4&e= > _______________________________________________ netmod mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
