* preso from 6Wind about their use of vty
** using xml transport between their own mgmt system and converting to vty
** command ordering an issue in cli/vty, as is feedback/validation
** planning to go forward with a yang-based schema, want api access,
   believe cli and api need to be converged as a single path

** Q from Donald: how do you handle shared objects, like route-map,
   acl, and prefix-list. "it's important that whatever solution we have
   understands that we have some shared/universal data"

** Renato W. gave a verbal overview of his 'northbound' proposal that has been mentioned on the regular dev call and in the yang slack channel; he will present slides and details soon

we tried to list a few higher-level points :

* attributes or objects? are we configuring individual attributes, or entire objects (or lists of objects)?
* validation/handling logic inside daemons: what do they need to be able to do internally to ensure correctness, and what can be done by model-level validation (a benefit of models)?
* sync  vs. async (for transport, and for interaction with the daemon code)
* shared/global objects (along the lines of Donald's point from earlier)
* locking (per-attr? per-object? per-transaction - whatever that is?) what are the sorts of needs and expectations as we see more multi-threading in frr?
* multi-admin (transactions concept): is this something that is a goal for frr, or is it the responsibility of external management systems?
* impact on code (cli, running/protocol code, opportunity to auto-generate some config handler code?)
* performance/mem - input of large config, paging of large data sets, e.g.
* error-handling, feedback
* multi-daemon, multi-process coordination (ease of daemon management,
  "it's really hard to set up mpls right now" [DS]
  ** behavior on restart among daemons, e.g.

we discussed a follow-on meeting to continue the discussion, time tbd...

Cheers,

Mark