Donald organized a conference call to focus on management and api issues. He suggested that I send around my notes, to give folks some overview of the discussion. I don't have a full attendee list, I'm sorry to say. And of course, if I've misrepresented something that someone said, please feel free to correct "the record"... * 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