I like the idea to step back and I actually only now found the time to read this thread, from its very start all the way to GDMO. (This is how my email client mutt sorted the thread for me. ;-)
I agree that we do have a big big data model coordination challenge in the IETF (and soon beyond as other SDOs start to extend IETF models). The sad truth is that addressing the challenge requires say 85% human brains (good early reviews paired with followup communication plus and some oversight and steering) and perhaps 10% better tools and likely only 5% conventions (if at all). This being the IETF, we seem to focus on the 10% and the 5% of the challenge first (probably because we know how hard it is to allocate the human resources needed to work on the 85% of the challenge). Things get somewhat interesting if well intended attempts to address the 2% of the challenge end up destabilizing data models that were written to form basic building blocks and that we have published (through a consensus process) and that have been implemented and deployed and that were also designed to provide a basis for other SDOs to extend them (I am talking about ietf-interfaces, obviously). Concerning the openconfig proposal that started this debate, I fail to see how good model design becomes significantly easier by having a rigid fixed plan where the models are to be rooted. Writing good extensible models is hard, and it will always be. A big part of the problem is (i) to identify a common model for a technology that can be implemented across multiple devices and (ii) to future prove the model such that extensions of the model can work easily (and predicting the future remains difficult for most of us). To me, it seems we have a software engineering challenge paired with the specifics of working in a volunteer organization that in addition has its own internal boundaries (called areas and working groups). We also witness the differences of opinion between people who believe small design teams for criticial pieces can help to solve the 85% challenge and people who believe more agile processes should be used (where you throw out rough ideas quickly and subsequently iteratively revise them to either become a good idea or to remove them if they did not fly). Unfortunately, the meta-debate between a more traditional approach and a more agile approach does not help with the 85% challenge, at least not in the near future. So in conclusion, I believe the key problem is a lack of skilled human resources that can help with the 85% of the challenge. So what can we do? Trying to increase the amount of skilled human resources involved in data model writing (training, mentoring, sharing of know-how - but this is a long-term process) and making sure that the skilled human resources we have stay productive by focusing work, by prioritizing work, and by maintaining a constructive atmosphere. Looking at the many things going on and the number of people deeply technically involved in those things, I am increasingly concerned that we loose focus and make no measurable progress on the things we want to achieve. /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 [email protected] https://www.ietf.org/mailman/listinfo/netmod
