On Wed, Aug 26, 2015 at 6:17 AM, Nadeau Thomas <tnad...@lucidvision.com> wrote:
> > > On Aug 26, 2015:7:58 AM, at 7:58 AM, Martin Bjorklund <m...@tail-f.com> > wrote: > > > > Nadeau Thomas <tnad...@lucidvision.com> wrote: > >> [Speaking for myself] > >> > >> Is the resistance to this proposal because of the actual changes to > >> structure, or is it a resistance to churn/change? > > > > The former. IMO this is technically not a good proposal, as I have > > tried to explain several times. > > > >> And if we solved the > >> latter by say relaxing the rules around how we progress models to > PS, > >> would this alleviate the concerns for the former? The meta > question I > >> will ask is: is the existing RFC process adequate/sufficient for > us to > >> move forward on such a large scale with Yang models at the IETF? > >> Other organizations currently iterate on models using certain > revision > >> conventions (that are consistent with the rules we put out here) > yet > >> produce multiple versions of the same model within the same year. > As > >> a matter of fact, multiple versions are allowed to coexist within a > >> single implementation. In stark contrast, the M.O. at the IETF has > >> been to treat Yang models much like we did SNMP MIBs (or any other > >> document here) thereby assuming that once it becomes an RFC, that > it > >> is largely set in concrete for many years to come. > > > > In this specific case the change is cosmetic but has disastrous > > effects on other standard modules, other vendor-specific modules, > > existing server code and existing client code. I think people expect > > IETF standards to be a bit more stable than that. > > > > > > /martin > > Therein lies the salient part of question I am asking: is this > really > the case these days? The operators seem to be providing an answer that > contradicts > this age-old assumption. Other projects like ODL are too. Both have real > deployments too - these reference points are not science projects. I think > its > fair to bring this specific issue out in the open here to discuss because > its > a real issue we need to solve not just here in NETMOD, but at the IETF > in general. > > YANG modules are not relocatable. The issue should be really clear to anybody who has to support product in the field. If you make this change, the existing products stop working. It doesn't matter if you move the YANG objects a little or a lot. Since the proposed change ( / to /device ) adds no value whatsoever to a programmatic interface, the product in the field will be broken for no real reason. If vendors are expected to move all their YANG objects into some uber-tree that the IETF owns, then the disruption is total. I agree the NETMOD WG should think carefully about this change before agreeing to it, but it is the equipment vendors who will pay for it. > —Tom > > Andy > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
