Minutes interim-2017-netmod-01: Mon 13:00
minutes-interim-2017-netmod-01-201705221300-00

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