On Tue, Jan 26, 2016 at 03:36:17PM +0000, Robert Wilton wrote: > > >> > >Frankly, you either list all IP addresses of an interface in one place > >and then you need additional information to indicate where they are > >coming from (e.g., which config tweaks them) or you distribute the all > >IP addresses of an interface into multiple places of the schema (which > >I doubt operational people really want). > > > >To track the origin, you can create ip-address-origin, ip-route-origin, > >ip-foo-origin objects and stick them at appropriate places or you make > >this metadata which you do not have to define everywhere. > > > >This is my rather simple view of the world. > I'm not disagreeing with any of this other than to point out that the > opstate requirements drafts (either draft-ietf-netmod-opstate-reqs-04 or > draft-openconfig-netmod-opstate-01 that it was based on) are not asking > for a solution to this specific problem. They are asking for a solution > to relate the configuration and operational state nodes in the YANG schema. > > Specifying a common way to track these "origin" objects using meta-data > may well be worthwhile, but I think that it would be better achieved > outside the discussions related to the opstate requirements/solutions. >
All fine. I am just still confused what "relate the configuration and operational state nodes in the YANG schema" actually means. Does it mean that an IP address coming via DHCP should be reported next to the DHCP config? I guess not. So I am left puzzled. /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
