Hi, Not sure I like the YANG module with all the datastore identities because it makes datastore discovery more complicated. I prefer the server advertise capabilities in the <hello> message.
More importantly, all the existing NETCONF operations use a container with a choice in it to select the source and target for various operations. It is trivial for a YANG module to simply augment these choices with new leafs, rather than forcing all client and server implementations to duplicate these operations with identifyref leafs for these parameters. Andy On Mon, Mar 20, 2017 at 10:09 AM, Kent Watsen <kwat...@juniper.net> wrote: > > > I believe this is the wrong direction, even if we rewrite the module > > in the revised datastores document and split it into multiple modules. > > A simple list of implemented datastores is cheap. It is flexible. It > > does not require explanations and rules how definitions must be split > > into modules that finally must be remembered and checked still in 5-10 > > years from now. I firmly believe that these types of 'optimizations' > > lead to creeping complexity down the road. Lets not create CLRs how > > modules must be structued, named, etc. > > That's a better answer. At least now I get the sense that you actually > understood what I was saying. > > As for your proposal, I agree with you that it would be best to have an > explicit list. I assume that this would be another proposed change to > YANG Library (i.e., Section D.2 in the revised-datastores draft). It > will be tricky to enforce the use of this version of YANG Library in > RESTCONF without a -bis document... > > K. > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
