On Tue, Oct 13, 2015 at 1:22 PM, Randy Presuhn <[email protected] > wrote:
> Hi - > > >From: Juergen Schoenwaelder <[email protected]> > >Sent: Oct 13, 2015 1:06 PM > >To: Randy Presuhn <[email protected]> > >Cc: [email protected] > >Subject: Re: [netmod] 6020bis more than one revision of a module > > > >On Tue, Oct 13, 2015 at 12:55:32PM -0700, Randy Presuhn wrote: > >> Hi - > >> > >> >From: David Reid <[email protected]> > >> >Sent: Oct 9, 2015 2:03 PM > >> >To: [email protected] > >> >Subject: [netmod] 6020bis more than one revision of a module > >> > > >> >I'm reviewing 6020bis since it is in working group last call. > >> >I see a new requirement that a server MUST NOT implement > >> >more than one revision of a module. I understand that supporting > >> >more than one revision can cause problems, but I expect that > >> >it will happen in practice. I know it happens sometimes with > >> >MIBs in SNMP. I think MUST NOT is too strong. > >> > >> I've encountered the same phenomenon in the SNMP universe, > >> so if I expected Netconf to used as a replacement for SNMP > >> I'd have the same concern. > >> > > > >Perhaps you can detail what it means to support multiple revisions of > >a module at the same time. Are you saying YANG needs a way to slice > >modules such that for example interface ethernet0 can support revision > >X of an Ethernet data model while interface ethernet1 supports > >revision Y of an Ethernet data model? > > This is a fairly typical situation. > > >If so, support for per resource > >data model revision is not really part of YANG nor is it really part > >of NETCONF I think. > > Yes. I continue to consider this a fundamental deficiency, but > recognize that there seems to be little interest in the WG in > doing anything about it. > > >(Note that YANG does support mechanisms such as > >features that allow to design data models in a way that they can be > >backwards compatible.) > > That's adequate for device management, particularly for > single-vendor closed boxes, but not for configuration management, > and especially not for configuration management of open systems. > Again, I recognize that I hold a minority viewpoint, and the WG > has chosen a different path. > > This is a common situation, but not really a feature. The foo-knob range is increased from 1 - 10 to 1 - 20. Some new cards support 1 - 20 and some other cards only support 1 - 10. There seems to be 3 solutions, none of which are very good: 1) document everything: return lots of instance-level conformance information and expect the client to sort it out 2) Advertise the newer version and let the client figure out that some instances only allow 1 - 10 3) Advertise the older version and let the client figure out that some instances allow 1 - 20. YANG says to do (3). This seems most correct to me. > Randy > Andy > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
