NETCONF Interim Meeting - December 13, 2017 7-9 a.m. PST. Etherpad: http://etherpad.tools.ietf.org:9000/p/netconf-interim-dec-2017 Draft: https://datatracker.ietf.org/doc/draft-ietf-netconf-rfc7895bis/ Slides: Chair Slides: https://datatracker.ietf.org/meeting/interim-2017-netconf-01/materials/slides-interim-2017-netconf-01-sessa-chair-slides/ YANG Library Options: https://datatracker.ietf.org/meeting/interim-2017-netconf-01/materials/slides-interim-2017-netconf-01-sessa-yang-library-options/ Recording: File size: 75.34MB Duration: 1 hour 46 minutes Streaming recording link: https://ietf.webex.com/ietf/ldr.php?RCID=cb1718375c9d972f3cfedbf14f6d2e03 Download recording link: https://ietf.webex.com/ietf/lsr.php?RCID=892d848081d0a17bd98394dc03fb085f Agenda: Review YANG Library proposals This presentation will also go over topics raised during the IETF 100 meeting including: - Licensing - Line card insertion/deletion - Semantic versioning LL: Ladislav Lhotka RW: Robert Wilton MB: Martin Björklund ME: Mehmet Ersue KW: Kent Watsen AB: Andy Bierman CB: Carsten Bormann EV: Erik Voit EN: Einar Nilsen-Nygaard IB: Igor Bryskin JT: Jeff Tantsura SM: Scott Mansfield XL: Xufeng Liu JS: Juergen Schoenwaelder AM: Ashesh Mishra SB: Stephen Banghard (?) MJ: Mahesh Jethanandani Martin presenting: Discussion: LL: Does the RFC 7950 section 5.6.5 requirement (one revision of a module in a server) apply to schema mount? RW: This would make constraints checking very hard. A device could change YANG library based on what linecards are plugged in, or alternative have a single schema that is a superset of all possible lincards. MB: Any comments on the different proposals (RPC, or YANG library as operational data, or one version of YANG library per datastore). LL: Likes the idea of using a RPC. MB: How would the RPC that work? LL: Single RPC that gets everything, (e.g. one of the structures that has been discussed). Same RPC in the form of an action could be used for schema mount. JS: Would need to execute the RPC/action for every mountpoint. MB: Actions are associated to data in , so how to obtain schema information for a mount point in a configuration datastore? Also how is the checksum handled? RPC would give you everything unless there are filter parameters on the RPC. MB: What about using separate meta-data datastores to provide the yang library information for other regular datastores? JS: This is expensive given the current set of protocol operations we have, requires N roundtrips for N datastores. MB: Anybody here to speak in favour of the meta-data datastore solution? [nobody did respond] Martin presenting on alternative 1: KW: What is the checksum for under the schema? MB: The checksum represents the checksum for a particular schema, so that if a module in particular schema changed then the checksum for that schema would change, along with the top level checksum. Top level checksum can get sent in the capabilities message. KW: What if the top level schema changes for another reason. MB: Then the top level checksum changes. IB: Do we always have one schema per datastore? MB: Yes. Martin presenting on alternative 2: LL: The client can use a checksum to see that nothing has changed. MB: Checksum can be used for all solutions. Have to code for the startup case. XL?: Where does the name of the module-set come from. MB: The server makes up the name for the module-set and the schema. KW: May be a downside, a schema could point to more than one module-set. How are conflicts handled. MB: Combining module-sets don't allow any conflicts, just one module. IB: How do you deal with modules that don't fit into module-sets? ... missed some of these questions ... MB: Two different schema can point to the same module sets. LL: Different solution of Y?L draft, a schema could point to another schema or just modules. E.g. allow schema to recurse rather than having module-sets. IB: Likes this option. Martin is presenting on alternative 3: (What is in current bis draft -02) MB: Harder for a client to get the data (extra level of indirection), list is perhaps a bit less obvious. LL: Instead the schema list, it could reference another schema. IB: Do we have to limit to only implementing a single module in a schema. MB: Server reports what it can do, and will onnly report a single revision if it is following the rules. IB: What about an older client? MB: The model is only reporting what the server is doing. JS: YANG update rules means that an old client can talk to a new server. Discussion on the different options: JS: Do we need to discuss licensing and sem-versioning? LL: ??? MB: Server has different license options, and a client can enable different licenses. MB: Alternative C doesn't really support the idea of a license representing a set of modues. XL: Module sets could have comflicting versions. MJ: Does that rule option 3 out? LL: Thinking about schema mount, different VMs could have different features enabled. KW: Nice if licenses lined up with just features, but questionable for vendors; similarly for modules. MJ: License is for a module or a set of modules. IB: Could this be done by a separate module? E.g. replicating the structure, and put it somewhere else. JS: You need extra information for licensing so would likely have a separate module, but still helpful to refer back to a module set. LL: Module-sets shouldn't be restricted to just referencing a single version of a module, that rule should perhaps be expressed in the protocol. AB: I do not like the yang library proposals because they allow a server to report something that is forbidden by MUSTs LL: Some of the flexibility is needed to support schema mount. AB: I do not think schema mount is the right solution for management virtualized systems. MB: A MUST applies regardless whether the MUST is enforced by a data model structure. Even simple models have situations where MUSTs are not always expressed in the data model. Poll results (http://www.polljunkie.com/poll/qeqywj/netconf-virtual-interim-poll/view) Which do you you prefer? 1.7 Alt B (ds -> schema -> module-set) 1.9 Alt A (ds -> schema) 2.7 Alt C (ds -> schema -> module-id) 4.0 Alt D ( rpc) 5.3 other 5.4 Alt E (yang-library per datastore?) AB: I voted for the order in which things were shown (A,B,C,D,E, other) but my vote is not in favor of any of these proposals. Should licensing be considered now? no 80% yes 20% Should h/w insertion/removal be considered now? no 80% yes 20% Should sem-ver be considered now? no 80% yes 20%