> On 9 Jan 2017, at 21:51, Juergen Schoenwaelder > <j.schoenwael...@jacobs-university.de> wrote: > > On Mon, Jan 09, 2017 at 09:18:46PM +0100, Ladislav Lhotka wrote: >> >> I am more concerned about use cases that are not known so far, and so I am >> against standardizing this (or any other) workflow as the only one supported >> by NETCONF/RESTCONF and YANG. I believe both the protocols and YANG can work >> with any set of datastores, but their choice depends on the use case at >> hand. Why should IoT developers be exposed to the running-intended-applied >> complexity, even if they are allowed to lump all three into one? >> > > Please point me to the statement in the I-D that makes you believe an > implementation is required to support all datastores.
Sec. 6.3: "YANG currently describes validation in terms of the <running> configuration datastore while it really happens on the <intended> configuration datastore." This seems to indicate that <running> and <intended> are required, at least conceptually. The original datastore model (sec. 4) was hardwired into NETCONF and YANG specs but it was found insufficient for some use cases. So now we come up with another datastore model, and I am against doing the same mistake again. What if some future use cases again need something else? We could instead define the protocols and YANG in terms of reasonable abstractions (e.g. resource and data tree), and use a run-time specification of the datastore model (there could also be several standardized alternatives). To some extent, we do it already now by using capabilites such as "candidate", "startup" and "writable-running". > >>> There are no standard mechanisms that cause <running> to be >>> different from <intended>, so I would agree the intended datastore >>> needs a lot more standards support before it is useful. >>> >> >> The only difference seems to be the presence of templates but I don't know >> what they are. >> > > The I-D says: > > | // e.g., removal of 'inactive' > | // nodes, expansion of templates > > So it is not just templates. And yes, these are things several > real-world implementations can do but where the IETF did not yet > managed to standardize anything. The basic question is whether we want > a model that is (a) capable to match real-world implementation and > that allows for future standards of existing proprietary technology or > (b) we go with what we have today (either chartered or published) and > we keep revising the model as we move ahead. I think we need protocol and YANG specs that are not tied to any particular model and that are thus capable of matching unforeseen real-world implementations. This is no sci-fi, HTTP and XML schema languages work this way. 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: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
