On Wed, Aug 26, 2015 at 6:34 AM, Nadeau Thomas <[email protected]> wrote:
> > > On Aug 26, 2015:9:09 AM, at 9:09 AM, Acee Lindem (acee) <[email protected]> > wrote: > > > > > > > > On 8/26/15, 8:09 AM, "Martin Bjorklund" <[email protected]> wrote: > > > >> Nadeau Thomas <[email protected]> wrote: > >>> > >>>> On Aug 26, 2015:6:26 AM, at 6:26 AM, Martin Bjorklund <[email protected] > > > >>>> wrote: > >>>> > >>>> "Acee Lindem (acee)" <[email protected]> wrote: > >>>>> > >>>>> > >>>>> On 8/26/15, 2:40 AM, "Juergen Schoenwaelder" > >>>>> <[email protected]> wrote: > >>>>> > >>>>>> On Tue, Aug 25, 2015 at 10:53:55PM -0400, Lou Berger wrote: > >>>>>> > >>>>>>>> Hopefully, a decision to change all existing models (including > >>> vendor > >>>>>>>> models!) will be based on something more technical than the fact > >>> that > >>>>>>>> a group of people "really like it" some other way. > >>>>>>> > >>>>>>> I'm equally unsure that having an argument of "I got there first" > >>> is a > >>>>>>> compelling argument given the number of folks (including vendors) > >>> who > >>>>>>> have stated willingness (or even support) for change. I think > >>> having > >>>>>>> a > >>>>>>> major class of users stand up and say this is important should > >>> garner > >>>>>>> some notice. > >>>>>> > >>>>>> Please keep in mind that we are talking about several published > >>>>>> proposed standards that have been implemented and deployed. I think > >>>>>> there must be convincing technical reasons to declare them broken > >>> and > >>>>>> to redo them. > >>>>> > >>>>> Other than adding /device at the top, we are not obsoleting RFC > >>>>> 7223. > >>>> > This shows a rather diminished understanding of how YANG works. YANG defines data at a specified location /some/path/from/root. Protocols like HTTP can deal with moved resources (e.g., 301). > >>>> This doesn't make sense. The YANG model is the contract. You are > >>>> proposing changing the contract. The fact is that you will be > >>>> obsoleting 7223 (and the other RFCs). Existing devices and > >>>> applications will have to change in order to handle this new top-level > >>>> node (which will be in some other namespace I presume, unless your > >>>> proposal is one gigantic monolithic model). > >>>> > >>>> > >>>> /martin > >>> > >>> Again I will ask: why is this bad? > >> > >> My point above was in reply to the statement that "we are not > >> obsoleting RFC 7223" [because the change is so small?] - you would in > >> fact be obsoleting the model in 7223. > > > > There have been other mechanisms discussed to relocate YANG models. > > Perhaps, one of these could be employed in lieu of obsoleting the > existing > > models. > > > > Thanks, > > Acee > > This is exactly what I want to get on the table. If we can agree > on a mechanism/s to do relocate modules, then this might alleviate the > resistance to evolve models. The current issue aside, if you step back and > look > at the wider IETF situation around all the Yang models being created and > are RFCs, and the dependency graph that is created. You can then > imagine a time after that point when others come along that evolve > parts or entire modules. We currently refer to this as “obsoleting” > all of the modules that it depends on, which is a very big problem using > the current RFC process. Not only does it require a revision of all those > RFCs (due to obsoleting the previous ones) - and thus all the > procedural/management > overhead that will incur - but the time lag from start to finish. And > this might happen for any new module. This is not scaleable going forward. > > So we would just need to retrofit all the clients and servers with complicated code to relocate YANG modules and adjust all the validation tests? Another approach is to not rely so heavily on one giant uber-tree that MUST be correct on the first try and never change. Resource directories and other flexible approaches have been developed for this purpose. > —Tom > > > Andy > > > > > > >> > >> > >> /martin > > > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
