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, Mehmet From: Andy Bierman [mailto:a...@yumaworks.com] Sent: Dienstag, 13. Dezember 2016 18:38 To: Eric Voit (evoit) <ev...@cisco.com> Cc: Ladislav Lhotka <lho...@nic.cz>; MehmetErsue <mer...@gmail.com>; NetMod WG Chairs <netmod-cha...@ietf.org>; NetConf WG Chairs <netconf-cha...@ietf.org>; NetMod WG <netmod@ietf.org>; Netconf <netc...@ietf.org> 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) <ev...@cisco.com <mailto:ev...@cisco.com> > 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 <mer...@gmail.com > > <mailto:mer...@gmail.com> > 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 <a...@yumaworks.com > > <mailto:a...@yumaworks.com> > > wrote: > > On Mon, Dec 5, 2016 at 4:02 AM, Juergen Schoenwaelder > <j.schoenwael...@jacobs-university.de > <mailto:j.schoenwael...@jacobs-university.de> > 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 > > netmod@ietf.org <mailto:netmod@ietf.org> > > https://www.ietf.org/mailman/listinfo/netmod > > -- > > Cheers, > > Mehmet > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > Netconf mailing list > netc...@ietf.org <mailto:netc...@ietf.org> > https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ netmod mailing list netmod@ietf.org <mailto:netmod@ietf.org> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
