> 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. > 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 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
