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