Kent Watsen <kwat...@juniper.net> writes: >> Then you probably already know what the solution is going to be. I don't. > > It’s not that I know the exact solution. It’s that I see this > approach offering good options for graceful migration to an opstate > compliant solution (for which I’m on the design team alias), without > incurring any modelling cost, other than there being an additional > module. I additionally see this approach as more flexible in that, as > you said, it would allow one module to be updated without disturbing > the other.
The data modelling cost of splitting config and state data into separate modules IMO is that it weakens the concept of system- and user-controlled objects. I understand that some folks don't like it but I am still not convinced that anything better is readily available. And then of course another cost is that all modules depending on ietf-routing need to be updated accordingly. So IMO we should think twice before making this change. I would appreciate more opinions on it. Lada > > >> Anyway, if the consensus was to split config and state data into separate >> modules, we would have to tell all module developers who build upon the core >> routing model to split their augments into config and state parts as well, >> because otherwise the change to ietf-routing would be useless. > > Yes, indeed, this would be the primary consequence. > > >> Lada > > Kent > > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
