Hi Andy, On August 27, 2015 at 14:48:58, Andy Bierman (a...@yumaworks.com) wrote:
Did you really think that just because we created a nice DML that somehow you would not need to know about the topic of your YANG module? I actually have heard this complaint from some people. Great. How does YANG help? I still have to be an expert in MPLS to write a YANG module that manages MPLS. Yep. That's right. Nothing in YANG helps you know more than you do now about specific networking technologies. No, I didn’t at all. So, I work operating networks, and the surrounding systems that we use to manage them. I could consider myself to have some knowledge in the various areas that I’m trying to model right now - and am even luckier to be able to work with a bunch of folk who have also operated different networks, such that we can figure out how things should be laid out. So, we’re writing these modules - and you’ll see them here: https://github.com/YangModels/yang/tree/master/experimental/openconfig What I am saying is that as the person looking at how to /actually use/ these modules, it is much, much easier for me if I can have some idea of where to find things that I know are related, and have some consistency in the approach. The group of people that are writing these modules noted the need for us to have some structure. However, the IETF is also writing a bunch of modules, which we figure it’d be super-neat if we can use. So we wrote some conventions, one is a structure; the other is an approach for how opstate is modelled. From your mail, I think that you are saying that you don’t care how we do this. If that’s the case we’ll head off and write our modules. However, there are two discrepancies: Lots of others in the IETF are writing models, and we’d like all these to combine to be usable. To do this, we need to agree on a structure. NETMOD looked like the place to do this based on the fact that draft-ietf-netmod-routing-cfg is a NETMOD draft. So we brought them here. Your objection is based on a specific subset of models that have already been created, that you assert will still need to exist. This is then counter to the fact that I can go and model things how I like. Again, it seems like raising the issues that we have with these models in context of a structure should be something raised with NETMOD, given that these documents are the output of NETMOD according to the data tracker. There are really two options: a) NETMOD does not care about how models fit together - because their contents are arbitrary. If this is the case, fine, I’ll talk with the area directors as to where we should propose these approaches such that the pan-IETF models end up working nicely together within the DML that this group has defined. b) NETMOD does care, and should try and define a structure because it is the custodian working group for YANG and YANG models. I think a lot of my problems are solved by having a defined structure for models, that has been worked through by folks with protocol knowledge, and knowledge of how these elements are used and managed. I would like it to be adopted by the IETF. My view is that b) is currently true - and hence it was brought to NETMOD. At the moment, I can’t reconcile the apparent disparities between your statements in this mail and your objections in other messages. Further to this, I still cannot see any alternative to the structure that we did define - so whilst I can remove /device from the start of the path, which ‘protects’ /interfaces [0] - this doesn’t actually help me progress anything. This is why “/device or not” is irrelevant. r. [0]: Note that actually, some work to refactor 7223 further to just its path has been done… https://github.com/YangModels/yang/tree/master/experimental/openconfig/interfaces
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
