Minutes interim-2017-netconf-01: Wed 10:00
minutes-interim-2017-netconf-01-201712131000-00

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 <operational>,
    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 (<get-yang-library> 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%