On Thu, Aug 27, 2015 at 12:48 PM, Rob Shakir <[email protected]> wrote: > Hi Andy, > > On August 27, 2015 at 14:48:58, Andy Bierman ([email protected]) 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: > > 1. 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. > 2. 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. > > this is a strawman. Just because some people don't agree that the existing modules should be moved doesn't mean the NETMOD WG wants every module to create its own top-level node.
Create some organization for the 194 new modules. I completely agree with you that these modules should be written with a coherent development plan in mind. > 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 > Given that CLIs are being driven by YANG, I completely agree that understanding of the command hierarchy is useful. I have no objections to the creation of a hierarchy or "node placement plan" or whatever. This is a non-issue. The issue I see is whether the existing 7 modules should be grandfathered or whether these RFCs have to be changed to Obsolete status and replaced with new RFCs. Andy > > 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 [email protected] https://www.ietf.org/mailman/listinfo/netmod
