Draft meeting minutes have been posted. https://www.ietf.org/proceedings/interim-2017-netmod-01/minutes/minutes-interim-2017-netmod-01-201705221300-00
Please send any corrections/clarifications to the list ASAP. Authors, please confirm decisions on the list. PS: regarding my comment at the very end about needing more examples, perhaps the examples are sufficient, but more needed are pointers throughout the text to parts of examples illustrating various points. Also, I think that the NI vs LNE distinction should be introduced in the Introduction; use of formal terms would help the document as a whole as well: NI, LNE, host-system. Thanks, Kent
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 <slide 2> 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" <discussion> 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 <Slide 3> <Lots of discussion issue #1> 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 <slide 4> 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 <Design time mounts> 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
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
