Schema Mount Virtual Interim Monday, May 22nd from 1pm to 3pm EST. Tracker: https://datatracker.ietf.org/meeting/interim-2017-netmod-01/session/netmod WebEx: https://ietf.webex.com/ietf/j.php?MTID=m87b080addaf71be419f67f2a893cfe94 Etherpad: http://etherpad.tools.ietf.org:9000/p/notes-2017-may-interim-netmod Attendees: Kent Watsen Lou Berger Lada Lhotka Martin Bjorklund Andy Bierman Acee Lindem Balazs Lengyel Joe White Xufeng Liu Igor (B?) Robert Varga Agenda: Schema Mount Draft: https://tools.ietf.org/html/draft-ietf-netmod-schema-mount-05 New Slides: https://www.ietf.org/proceedings/interim-2017-netmod-01/slides/slides-interim-2017-netmod-01-sessa-yang-schema-mount-00.pdf Slides from Chicago: https://www.ietf.org/proceedings/98/slides/slides-98-netmod-sessb-schema-mount-00.pdf Lada presents new slides Andy B: How does augment work in child with parent-references? Can a model be both mounted and use parent reference. Lada: This is a corner case, and should just work. All x-path references will expand to the union of the parent and child trees. It all is based on the x-path expansion. So should have no concerns with augments. Martin: A child augment doesn't augment the parent tree. Note the child "version" is not a copy. Lou: Augment would need to be at parent level Lou: is a mount and parent-reference allowed Martin: This could work, i.e., provide a union of nodes. We could make this illegal. Note this is based on server implementation: Balazs Lengyel to everyone: If you have both local and parent references, how do we guarantee key uniqueness? Martin: You wouldn't - it would be a union Balazs Lengyel: What happens if have same leaf/list name in both Lada: X-path expression evaluation will make this clear Martin: maybe make this illegal Lada: perhaps just advise this Martin: will look at language to restrict this. Lou: in document parent-reference is witin use-schema Andy: it's better to have it associated with mount point rather than a use-schema Lou: how do you support parent-reference for a particular NI instance, e.g., NI="red" Lou: perhaps put parent-reference in mount point extension, and then can have leaf-ref to specific instance value, e..g., NI=red Martin: idea of placing parent reference in mount point is worth thinking about Kent: in the case without parent-reference, use-schema indicates the full list of modules instantiated under the mount point Lada: correct Kent: how does inline work Lada: inline builds a self contained model using its own instance if yang library Lou: key difference in inline vs use-schema is when schema is available - inline is when specific mount-point is instantiated; use-schema is when server is available Kent: perhaps make implicit based on import statement Lada: imports really don't do anything other identify namespaces Kent: why use namespace, and not specify full path in parent-reference Joe white: namespace is just a short hand Lada: yes Martin: is needed by x-path Andy: this now a 3rd source for namespace definitions Andy: I don't see why not follow restconf approach of using module name, but this is okay too Kent: yang-library bis is using module-name as well Martin: using such an implied expansion is worth considering Joe White (posted in chat window): Could you mount ietf-network-instance twice to /if:interfaces? I assume you could and you would call them for example "ietf-network-instance-A" and "ietf-network-instance-B" and that the scoping to get to each would use the module name in the mount-point declaration as the container name for the mounted schema. Lou: this would be two mount point instances (in LNE) Martin: the mount point would exist just once, and then the mount point is either inline or use schema Lada: for inline, every mount point instance can have a different schema Lou: issue 2 - we (RTG area YANG DT) though there was value in having extension in it's own module. as contributor: - not a major point - if no one else thinks this is important we can move on Robert: having two modules has a lot of value from the implementation standpoint, i.e., just specifying that mount point is present in module is sufficient Lada: 2 modules has value, and finished almost immediately while use-schema Martin: would be opposed to separating Robert: inline works fine Martin: trying to solve both Lou: if we have the extension in two modules would support implementations that only do inline Martin: can be solved by schema-mount module with no use-schemas identified Robert: that's okay if can get standardized in a timely manner Robert: not sure config=false is useful, better to do in runtime session / data itself - in the context of the mount point --> resolution for both issues to accept dropping, i.e., no change needed in -05 Issue 1: Andy: with keyless lists, can use any name as they should be ignored Lada: will propose text to match, and see if it works for all Issue 2: move to tree definition to new tree-diagrams draft Lou: (as participant) first use case could be the use-schema itself (with library) Martin/Lada: this is unnecessary complexity at this time, and would like to defer Lou: Okay, is reasonable to defer to the future Balazs Lengyel: We DO NEED a way to have a method of dcumenting/retrieving the full set of mounts without reading anything from a live server Lada/Lou Berger: can provide a prebuilt / prepopulated schema-mount module Kent: could use more examples in draft Balazs: could use more explanation of design time vs implementation time