1) Ability to ingest and consume configuration 2) daemons have no concept of whom they are receiving configuration from Everything ultimately goes through a common interface 3) Singular internal data model Ability to template Ability to do ranges 4) Configuration transactions validation input validation Correctness of input( mtu is a valid usable value ) operational validation commit rollback Native support for configuration reloads ( bye bye frr-reload.py) Minimially disruptive. Only change the items that we have to. 5) The way FRR thinks about configuration currently should drive the data modeling We should not be limited by the modeling language We should not be constrained by non FRR data models 6) Performance should be sufficient at scale with 100k’s of lines of configuration Better than vtysh -n 7) Operational data should be presented via this model 8) Support for Event Notifications 9) Don’t build support for clients that operator is not interested in using 10) Ability to choose who can configure and who can gather operational data 11) Backwards compatible with current configuration configurationhttps://docs.google.com/document/d/1l9oDRTEuVDOKG9yuxd8cFTmBaYZ2CJdy8EIZcuOJ...