On Thu, Jun 25, 2015 at 12:40 AM, Juergen Schoenwaelder < [email protected]> wrote:
> On Thu, Jun 25, 2015 at 12:29:13AM -0700, Anees Shaikh wrote: > > hi Juergen, > > > > I don't believe it involves tracking anything beyond what you would need > to > > track however the model is structured. You would want to know when your > > static IP is applied and being used, or you would want to know what IP > > address was assigned by the DHCP server. Our approach collects this > > information in one consistent place (in terms of paths) independent of > how > > one wants to compose the models. I guess don't understand what you mean > > by it requires reporting and integrating state data from multiple places. > > > > I really don't see where the extra complexity and cost you mention is > > coming from. Is the addition of some nodes in the data model so costly? > > For whom? A model writer? I think the design pattern for writing models > > in this way actually is pretty straightforward (having written several > > reasonably complex models now). For a human model reader? Perhaps the > > disconnect is that our perspective is coming from trying to build > > operational software systems that consume the models without having to > > write unnecessary model-specific code that just propagates more > complexity > > into the NMS. > > The problem with your approach is that you are assigning semantics to > where information is located in the data model. You can only do this > once. While have N different locations where IP addresses are listed > might answer one operationally relevant question, it makes other > opertionally relevant questions harder. If you continue with your > approach, you will start replicating data multiple times to address > different operationally relevant question. And this simply does not > scale, clearly not with standards in mind. > > The data modeling language allows the designer to choose an arbitrary identifier for node names. Making clever little rules about what arbitrary names are allowed, where they allowed, etc. just adds complexity to the language. The only robust design is to assign semantics to statements with reserved keywords. It would be unwise to design code that ignores a deterministic first order language statement and relies on ad-hoc naming conventions instead. Naming conventions are fine -- we have interfaces, interface-state, etc. This helps readability but it is not a substitute for deterministic and fully machine-usable statements. The addition of extra layers is a big issue to me. It clutters the data model, the XPath expressions, and adds bytes to every payload that references that data. I understand that the use of NP containers is very subjective. Not all people think data should be organized the same way. The only purpose of an NP-container is to organize data. Each WG should decide the best way to organize its data. If "config" and "state" containers really make sense for the data, then use them. But we don't need a CLR forcing this on everybody. Andy I like to understand: > > - what are the additional semantics in the data model (e.g., machine > readable information that helps to understand static model > relationships) > > - what is the meta data you like to have and that you might want to > filter on in order to retrieve data in meaningful ways > > I am having a hard time to believe that encoding semantics in the > naming structure is a proper and workable solution. > > /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 >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
