Hi - >From: Juergen Schoenwaelder <[email protected]> >Sent: Dec 28, 2015 6:24 AM >To: Robert Wilton <[email protected]> >Cc: "[email protected]" <[email protected]> >Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01 > >On Wed, Dec 23, 2015 at 10:05:46PM +0000, Robert Wilton wrote: >> >> Personally, ignoring all the backwards compatibility issues, I would >> prefer that interfaces and interfaces-state were a combined single list >> (as proposed by OpenConfig). E.g. something along the lines of: >> - the system can still provide an operational list of discovered >> interfaces so that clients can know what is there. >> - but management agents would be expected to explicitly configure >> (i.e. create an entry for) all interfaces for which it wanted to >> retrieve data for. >> > >A clear separation of config from operational state is one of the >outcomes of the IAB workshop documented in RFC 3535 and it is one of >the key foundations of both NETCONF and YANG. Config and operational >state have different and _independent_ lifetimes - you can have config >for resources that are not present and you can have operational state >for resources that are present but not configured. In addition, the >data models for operational state are often not the same as the data >models for configuration. Merging all things back into a single list >with a single keying (naming) structure gets us back into the mess we >were in with SNMP.
This assumes that separation of config from operational state is best represented in naming. I think trying to get one's naming architecture to simultaneously and consistently encode too many aspects of whatever is being modelled brings some of the messiness that concerns you. Perhaps it's finally time to consider what the intended semantics of the NETCONF / YANG naming architecture really are, to stop trying to overload them further, and figure out what means are appropriate for all those other semantics folks have tried to foist onto naming. Randy _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
