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. 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 list [email protected] https://www.ietf.org/mailman/listinfo/netmod
