On Wed, Dec 14, 2016 at 6:42 AM, Robert Wilton <[email protected]> wrote:
> > > On 14/12/2016 14:09, Andy Bierman wrote: > > > > On Wed, Dec 14, 2016 at 3:07 AM, Martin Bjorklund <[email protected]> wrote: > >> Andy Bierman <[email protected]> wrote: >> > On Tue, Dec 13, 2016 at 1:41 PM, Mehmet Ersue <[email protected]> wrote: >> > >> > > Hi Andy, >> > > >> > > >> > > >> > > > This architectural change needs to be implemented in various >> protocols. >> > > >> > > > I am not sure a 6241bis is the best approach because it is not clear >> > > which >> > > >> > > > servers really need to implement the revised datastores. >> > > >> > > >> > > >> > > I agree fully. This is the reason why I wrote in my mail: >> > > >> > > >> > > >> > > >> - a new protocol- and language-independent standard document (RFC >> XYZ) >> > > defining the generic datastore concept and framework and describing >> its use >> > > (based on and following the DT solution draft), >> > > >> > > >> - a RFC6241bis draft removing the current datasore concept >> > > specification, and getting rid of well-known issues e.g. with the >> <get> >> > > operation, >> > > >> > > >> > I do not agree with the text you wrote. >> > I do not want to remove candidate, running, and startup from RFC 6241. >> > IMO the new datastores can be defined in a new document that does not >> > redefine the existing datastores. >> > >> > I also do not want to get rid of <get>, It works as intended. >> > It is not a problem on small devices. >> >> Andy, the problem with <get> has nothing to do with the size of the >> device. The problem is that <get> returns two things (running config >> + operational state) in one merged output document. This forces >> people to split data models so that config and state are mutually >> exclusive (/interfaces and /interfaces-state). This draft proposes a >> fix for this, which makes <get> less useful. >> >> > This "problem" exists for some new overloaded use of <get> that did not > exist before. > The <get> operation only mixes config=true and config=false. It never had > anything > to do with intended vs. applied. IMO your proposed solution is not very > backward compatible > with simple systems that do not have delays between intended and applied. > > > I've been informed (repeatedly ;-) that <running> has always only ever > meant intended configuration. I.e. that it is reasonable behaviour for a > system to accept config into <running> and then fail to apply that > configuration for some reason (daemon is unavailable, linecards is down, > resources have been exceeded, programming error, etc). If this > interpretation is correct then the NETCONF <get> operation is poorly > defined because it is mixing "intended configuration of the system" along > with "actual running state". > > What NETCONF <get> should really be providing is "actual configuration in > use by the system" along with "actual running state". Of course this is > effectively what the new operational state datastore is defined as > containing. > > If I understand it correctly, I think that Andy's point is that for lots > of systems "intended configuration of the system" and "actual configuration > of the system" are effectively one and the same thing. If this is the case > then it should be easy for clients/servers to migrate from an existing > <get> request to a <get-data> request that just returns the data from the > operational state datastore. It sounds like the actual data returned in > both cases should be the same? > > I do not understand the new solution because it has not been well-defined. In the old solution, I have 2 leafs /foo and /foo-state. I can retrieve both of these leafs at once with <get>. I can decide if /foo and /foo-state are the values I expect. But if I overload /foo such that it represents different semantics in different datastores, now a retrieval operation can only get 1 at a time. If I set /foo, then get-state(/foo), how do I know the config value for /foo has not changed in the meantime? If the server returns 2 /foo leafs in the same message body, then it is no longer YANG schema-valid (only 1 /foo node is allowed) The <get> operation does not overload objects with different semantics. Only a new server that eliminates /foo-state is overloading the semantics of /foo. The ability to retrieve /foo-state is lost for a client that only knows <get> (and not <get-state). This does not mean <get> is broken. It just means the ability to access /foo-state is removed. Thanks, > Rob > > Andy > > > > >> >> /martin >> > > > Andy > > >> >> >> >> > It is not a problem on large devices >> > if >> > sufficient filtering is used. It does not differentiate between >> intended >> > and applied config >> > or understand different types of config=false nodes. Use a new >> operation to >> > add these features. >> > >> > >> > >> > >> > >> > >> > > Mehmet >> > > >> > >> > >> > Andy >> > >> > >> > >> > > >> > > >> > > *From:* Andy Bierman [mailto:[email protected]] >> > > *Sent:* Dienstag, 13. Dezember 2016 18:38 >> > > *To:* Eric Voit (evoit) <[email protected]> >> > > *Cc:* Ladislav Lhotka <[email protected]>; MehmetErsue <[email protected] >> >; >> > > NetMod WG Chairs <[email protected]>; NetConf WG Chairs < >> > > [email protected]>; NetMod WG <[email protected]>; Netconf < >> > > [email protected]> >> > > *Subject:* Re: [netmod] [Netconf] WG adoption poll >> > > draft-nmdsdt-netmod-revised-datastores-00 >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > On Tue, Dec 13, 2016 at 5:37 AM, Eric Voit (evoit) <[email protected]> >> > > wrote: >> > > >> > > I support adoption, and like Mehmet's thinking as well. >> > > >> > > Also worth focusing on is transport protocol independent yang >> filtering. >> > > So along with how to frame get operations against one of the >> datastores, >> > > how do you know which subtrees/nodes should be included/excluded. >> > > >> > > >> > > >> > > >> > > >> > > This architectural change needs to be implemented in various >> protocols. >> > > >> > > I am not sure a 6241bis is the best approach because it is not clear >> which >> > > >> > > servers really need to implement the revised datastores. Since RD is >> > > purely optional >> > > >> > > to implement, it should not obsolete 6241 in any way. It should be >> > > possible >> > > >> > > to add new operations and/or new parameters to existing operations >> without >> > > >> > > needing to redefine what is already there. >> > > >> > > >> > > >> > > The new protocol features need to explain how to include/exclude >> subtrees. >> > > >> > > IMO we should only support YANG defined data. This allows the >> solutions >> > > >> > > to be generalized and reusable across protocols (e.g., using YANG >> > > extensions). >> > > >> > > >> > > >> > > >> > > >> > > Eric >> > > >> > > >> > > >> > > >> > > >> > > Andy >> > > >> > > >> > > >> > > >> > > > From: Netconf, December 9, 2016 7:49 AM >> > > > >> > > > Hi Mehmet, >> > > > >> > > > I think I could just sign your text at the bottom. >> > > > >> > > > Lada >> > > > >> > > > > On 9 Dec 2016, at 13:25, MehmetErsue <[email protected]> wrote: >> > > > > >> > > > > Hi All, >> > > > > >> > > > > I think the adoption of the DT draft is fine. We agreed in IETF >> 97 to >> > > adopt and >> > > > finalize the DT draft in NETMOD WG, which I still support. >> > > > > >> > > > > I believe the bigger issue is to agree on a plan concerning the >> > > related work >> > > > and the re-organization of existing standards. As a matter of fact >> this >> > > plan will >> > > > lead to updating the charter of two WGs and the work we are going to >> > > start. >> > > > > >> > > > > I see the DT document as a datastore solution proposal. There are >> > > different >> > > > gaps and issues which still need to be addressed and the solution >> > > proposal >> > > > needs yet to be discussed and finalized. The document is providing >> > > information >> > > > on the history, explaining the need for a generic solution as well >> as is >> > > discussing >> > > > different scenarios. As such I believe the datastore solution >> proposal >> > > from the >> > > > DT should be published with the intended status Informational RFC. >> > > > > >> > > > > Based on the finalized and agreed datastore solution we should do >> > > different >> > > > updates to existing documents in NETCONF and NETMOD WGs. With this >> > > > action we can also fix well-known issues. >> > > > > >> > > > > Concerning the NETCONF WG I would see it as valuable if we >> develop: >> > > > > - a RFC6241bis draft removing the current datasore concept >> > > > > specification, and getting rid of well-known issues e.g. with the >> > > > > <get> operation, >> > > > > - a new protocol- and language-independent standard document (RFC >> XYZ) >> > > > > defining the generic datastore concept and framework and >> describing >> > > > > its use (based on and following the DT solution draft), >> > > > > - adding potential extensions to RFC6241bis (following the DT >> draft >> > > > > and with a normative reference to RFC XYZ), >> > > > > - adding potential extensions to a RESTCONF-bis RFC (following >> the DT >> > > > > draft and with a normative reference to RFC XYZ), >> > > > > >> > > > > Concerning the NETMOD WG I would see it as valuable if we develop: >> > > > > - RFC7950bis deleting protocol-dependent details and specifying >> the >> > > > > datastore usage with YANG on a generic level (with a normative >> > > > > reference to RFC XYZ), >> > > > > - adding potential extensions to RFC7950bis, e.g. concerning the >> > > > > proposed <notification> element, >> > > > > - possibly an RFC 6244bis to describe architectural aspects. >> However >> > > RFC6244 >> > > > is Informational and a RFC6244bis would be still Informational. I'm >> not >> > > sure >> > > > whether this is really necessary. The DT proposal does already >> describe >> > > such a >> > > > solution and can be seen as an update to RFC 6244. >> > > > > - RFC6087bis giving guidelines on how to use YANG with the new >> > > datastore >> > > > concept. >> > > > > >> > > > > Referring to Lada's proposal concerning the spin off document from >> > > > > RFC7950 ("Adapting NETCONF for use with YANG"), I think this can >> be >> > > > provided in the corresponding protocol RFCs, i.e. >> > > > > for NETCONF a section on "Using NETCONF with YANG" in RFC6241bis >> and >> > > > for RESTCONF "Using RESTCONF with YANG" in RESTCONF-bis RFC. >> > > > > >> > > > > Hope this helps as a starting point on the way to a good plan. >> > > > > >> > > > > PS: As Benoit suggested some time ago we might also consider to >> rename >> > > > NETCONF WG as it is not only on NETCONF protocol anymore. >> > > > > >> > > > > Regards, >> > > > > Mehmet >> > > > > >> > > > > On Mon, Dec 5, 2016 at 6:19 PM Andy Bierman <[email protected]> >> > > > wrote: >> > > > > On Mon, Dec 5, 2016 at 4:02 AM, Juergen Schoenwaelder >> > > > <[email protected]> wrote: >> > > > > On Mon, Dec 05, 2016 at 11:36:11AM +0100, Ladislav Lhotka wrote: >> > > > > > >> > > > > > > >> > > > > > > I disagree that the datastore model is a protocol specific >> aspect. >> > > > > > > I consider datastores an architectural component binding data >> > > > > > > models and protocols together. In fact, the 'traditional' >> > > > > > > datastore model >> > > > > > >> > > > > > I would agree with this if datastores were a general concept in >> > > YANG, but >> > > > the revised-datastores draft explicitly introduces the "intended" >> and >> > > "applied" >> > > > datastores that may be irrelevant to other protocols using YANG, >> and even >> > > > needn't be used in all NETCONF implementations. I wouldn't call >> this "an >> > > > architectural component" of YANG. >> > > > > > >> > > > > >> > > > > An architectural component of this new management framework (that >> does >> > > > > not have a name). The fact that not all protocols may expose all >> > > > > datastores is IMHO not a reason that the datastore model is not an >> > > > > architectural framework. >> > > > > >> > > > > > If you are saying that it will have nontrivial impact on YANG, I >> > > would like to >> > > > see it explained in sec. 6.3. Without this information I am quite >> > > reluctant to >> > > > agree with the adoption. >> > > > > >> > > > > An operational state datastore has implications how one writes >> data >> > > > > models. It may not directly affect YANG itself but surely the >> usage of >> > > > > YANG. >> > > > > >> > > > > > See above - architectural aspects need to be relevant to all >> > > protocols. >> > > > > >> > > > > Yes, but relevant to all protocols does not mean every protocol >> needs >> > > > > to expose say all datastores. But every protocol should be clear >> about >> > > > > how what it exposes relates to the architectural framework. >> > > > > >> > > > > >> > > > > >> > > > > There is a "current solution" consisting of hard-wired object >> > > > > semantics (e.g., ifAdminStatus and ifOperStatus). This solution >> does >> > > > > not require special protocols or datastores, but it is being >> replaced >> > > by a >> > > > generic solution. >> > > > > >> > > > > If the "generic" solution requires special procedures which >> differ on >> > > > > each protocol, then it might end up be worse than the hard-wired >> > > solution >> > > > that works on every protocol. >> > > > > So I agree with Juergen that this is primarily an architectural >> issue. >> > > > > >> > > > > >> > > > > /js >> > > > > >> > > > > Andy >> > > > > >> > > > > >> > > > > >> > > > > -- >> > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH >> > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | >> Germany >> > > > > Fax: +49 421 200 3103 <http://www.jacobs-university.de/ >> > >> > > > > >> > > > > _______________________________________________ >> > > > > netmod mailing list >> > > > > [email protected] >> > > > > https://www.ietf.org/mailman/listinfo/netmod >> > > > > -- >> > > > > Cheers, >> > > > > Mehmet >> > > > >> > > > -- >> > > > Ladislav Lhotka, CZ.NIC Labs >> > > > PGP Key ID: E74E8C0C >> > > > >> > > > >> > > > >> > > > >> > > > _______________________________________________ >> > > > Netconf mailing list >> > > > [email protected] >> > > > https://www.ietf.org/mailman/listinfo/netconf >> > > >> > > _______________________________________________ >> > > netmod mailing list >> > > [email protected] >> > > https://www.ietf.org/mailman/listinfo/netmod >> > > >> > > >> > > >> > > > > _______________________________________________ > netmod mailing [email protected]https://www.ietf.org/mailman/listinfo/netmod > > >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
