Hi Stephane, if we do any changes to the core routing module, then I am afraid all modules that depend on it will have to follow suit. In particular, if we put config and state data into separate modules, protocol modules should do the same.
I don't like the idea of putting the core routing model and all work that depends on it on hold until we reach a decision regarding opstate. So, *if* the separation of config and state data gives a reasonable guarantee that at least the config part will be compatible with the ultimate opstate solution (whatever it is), it IMO makes sense to do it. But I am not even sure that the premise holds. Lada > On 02 Sep 2016, at 10:16, <[email protected]> > <[email protected]> wrote: > > Hi, > > As this model is a base for multiple routing modules, it would be good to > align the op-state modeling between this model and the existing routing > related modules (so we can also close the work on multiple routing yang > models). > So if core routing model uses foo:/foo foo:/foo-state, do we keep this > modeling also for our protocol models and close the work ? > > Best Regards, > > Stephane > > > -----Original Message----- > From: netmod [mailto:[email protected]] On Behalf Of Juergen > Schoenwaelder > Sent: Wednesday, August 31, 2016 20:41 > To: Kent Watsen > Cc: [email protected] > Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-routing-cfg-23 > (until Sep 9, 2016) > > On Wed, Aug 31, 2016 at 06:11:14PM +0000, Kent Watsen wrote: >> [as a contributor] >> >> My only comment on this draft is that I’d prefer it if the “routing-state” >> tree were moved into another YANG module, so that it could be more easily >> deprecated when the opstate solution comes. I suggested this before, with >> regards to rfc6087bis Section 5.23, but that thread seemed to have petered >> out, but now here we are and my opinion remains the same. >> > > We already have foo:/foo /foo:foo-state modules and while we can now start a > series of foo:/foo and foo-state:/foo-state modules in the hope that this > will eventually 'easier' in the future, it might also be that we just create > more variation and confusion. > > /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 > [email protected] > https://www.ietf.org/mailman/listinfo/netmod > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
