On Mon, Mar 20, 2017 at 02:28:53PM +0000, Kent Watsen wrote: > > > But this logic is already broken for the datastores defined in the > > revised datastores document. It defines an identity for startup but > > not all systems implement startup. End of proof. > > Ha ha, yes professor. But recall this started as a discussion regarding > what to do for the new dynamic datastores (not built-in datastores) and > then someone said maybe we should support other datastores too. I'm not > sure we need to do this but, if we did, then we could create modules for > them (i.e., ietf-startup). >
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. /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/> _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
