> On 5 Dec 2016, at 11:36, Ladislav Lhotka <[email protected]> wrote: > >> >> On 5 Dec 2016, at 10:38, Juergen Schoenwaelder >> <[email protected]> wrote: >> >> On Mon, Dec 05, 2016 at 10:18:32AM +0100, Ladislav Lhotka wrote: >>> >>>> On 2 Dec 2016, at 22:26, Lou Berger <[email protected]> wrote: >>>> >>>> All, >>>> >>>> This is start of a two week poll on making >>>> draft-nmdsdt-netmod-revised-datastores-00 a NetMod working group >>>> document. This document is unusual in that WG last call will be jointly >>>> held in both the NetConf and NetMod WGs, while adoption and day-to-day >>>> processing >>>> will take place in NetMod. >>> >>> There seems to be no impact on YANG syntax or semantics - the one mentioned >>> in sec. 6.3 is in fact protocol stuff that doesn't belong to the definition >>> of YANG the language. Therefore, this work has nothing to do with data >>> modelling and in fact belongs to the NETCONF WG. This would also solve the >>> indicated WG sch >> izophrenia that should IMO be avoided in any case. >> >> 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. > > 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. > >> together with the semantics of the <get/> operation caused us to write >> data models in a very specific way. Since the number of protocols > > Yes, to work around a flaw in the NETCONF protocol. > >> transporting YANG defined data is growing, it is crucial that >> architectural aspects are more clearly spelled out as such. (And the > > See above - architectural aspects need to be relevant to all protocols. > >> only architectural document we have so far was done in NETMOD. But at >> the end, I find the discussion which WG is responsible somewhat >> pointless, it is the same set of active technical contributors >> anyway.) > > Mehmet rightly argued in Seoul that this work should be done in NETMOD WG > because it will certainly have implications for the NETCONF
Sorry, of course I meant NETCONF WG. Lada > protocol. It is thus understandable that NETCONF chairs want to exercise > some control. > >> >>> A useful thing to do in the NETMOD WG would be to remove all >>> NETCONF-specific text from the YANG spec because whenever YANG is >>> used outside the NETCONF context (I2RS, CORE), that text is mostly >>> ignored anyway. >> >> If there is an opportunity to update all core documents together, we >> may clean up some of this; so far, we never had such an opportunity. > > I don't know what you mean by all core documents. In my view, it would be > sufficient to split RFC 7950 into two documents - the other one could be > something like "Adapting NETCONF for use with YANG". > > If we don't do this, it is difficult to propose YANG for use with other > protocols (as we did for I2RS) because we have to say: "You know, some parts > of the YANG spec appear mandatory but they are irrelevant for you, so just > ignore them". This was actually the case already for RESTCONF. > > Lada > >> >> /js >> >> -- >> 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/> > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > Netconf mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
