Minutes for NETCONF at IETF-95
minutes-95-netconf-1

Note takers:
    - Ladislav Lhotka [LL]
    - Jason Sterne [JTS]

Jabber scribe:
    - Mikael Abrahamsson [MA]

Speakers:
    - Andy Bierman [AB]
    - Mehmet Ersue [ME]
    - Mahesh Jethanandani [MJ]
    - Kent Watsen [KW]
    - Rick Taylor [RT]
    - Jeff Haas [JH]
    - William Lupton [WL]
    - Martin Bjorklund on Jabber [MB]
    - mcharlesr on Jabber [MCR]
    - Guangying Zheng [GZ]
    - Tim Carey [TC]

Joining via Jabber:  23 people
Joining via Meetecho: 12 people

Agenda bashing (2 minutes)
WG status review (5 minutes)

Chartered items:
      1. Report from documents after WGLC: Restconf, Yang-patch, Yang-library -
      A. Bierman (10 min.)

      AB: 3 drafts are nearly ready.
          RESTCONF needs some updates based on comments from Tom Petch
      ME: Are you going to address all comments? Any controversy?
      AB: All the open issues are minor, it shouldn't be a problem.

      2. Subscribing to YANG datastore push updates - Eric Voit (15 min)
         https://tools.ietf.org/html/draft-ietf-netconf-yang-push-02

      KW: I recommend splitting control and transport.
      MJ: Does anyone oppose the concept of splitting transport from the data
      model / RPCs ?
          -> In the room:  Nobody was opposed.  Many were in agreement.
      KW: Subscription allows for periodical subscription, how about other
      filters (e.g. when a value is exceeded, or when a value changes by more
      than a standard deviation, etc) EV: TBD on how much to put in the base
      model (many types of filters are possible) RT: Request to look at what is
      being worked on in DTN (async. mgmnt concepts)

      3. NETCONF Server Configuration Model - K. Watsen (15 min.)
         http://tools.ietf.org/html/draft-ietf-netconf-server-model

      JH: Security people will likely want some additional security functions
      as "if-feature" options in the base draft WL: ?? Clarification question
      about the use of groupings MB (jabber): propose to keep the SSH config
      knobs to the minimum ME: for issue #5 in the slides -> I'd suggest
      Proposal #2. KW: Proposal #2 means we need to specify the client part
      immediately. MJ: is there a need for a common keychain model across WGs ?
      KW: routing keychain is fundamentally different than the one needed in
      this draft MJ: It currently relies on NETCONF security (SSH/TLS) to push
      keys. KW: some concerns that strength of key being exchanged is higher
      than strength of security on the channel/protocol being used to exchange
      the keys (known issue) ME: What are we defining for NETCONF WG? Is it
      something of interest to general security of just something for
      NETCONF/RESTCONF? ME: any objection to moving forward on a NETCONF
      keychain independantly of the routing keychain model ? RT: I undestand
      appeal of #1, but I don't understand how you can avoid dealing with
      clients. I propose to use #1. KW: would boxes be making outbound
      connections like SSH, NETCONF, etc ?  If so - proposal #2 is useful. JH:
      NETCONF/RESTCONF requirements overlap general reqs. MB (jabber): I
      support #2. KW: there seems to be a lot of support for #2.  Will take it
      to the list. MB (jabber): peer mount would use (? client side config ?)

      4. Zero Touch Provisioning for NETCONF Call Home (ZeroTouch) - K. Watsen
      (15 min.)
         http://tools.ietf.org/html/draft-ietf-netconf-zerotouch

      RT: I would go for option #3 (slide 10) - use edit-config or yang-patch.
      The configuration can be big. KW: maybe an another option is to use a top
      level enum instead of a flag to allow a 3rd choice (patch vs just replace
      or merge) KW: any thoughts on signature over the YANG data ? (slide 11)
                 JH: PKCS#9 is popular in the IETF. Canonicalization is going
                 to be arequirement. KW: Namespace issues, both XML/JSON has no
                 guaranteed order.
      JH: storage formats have changed immensely over the years.  Fixing them
      in the model will likely just make the model obselete quickly . Maybe a
      registry ? KW: What would be the motivation? MCR: Not that we define
      them, we should just refer to them. RT: what are we trying to achieve
      here ?  Just basic booting ?  or more ? KW: just trying to boot & be
      ready to be managed.  But the difference from previous approaches is that
      this is a *secure* approach.  In theory the config could be anything
      (huge full config) but it needs to be at least enough that the device can
      make a management connection for further management. ME: please propose a
      way to move forward on this draft KW: My hope is to have LC in one month
      and finish this work in 2016.

      5. NETCONF Event Notifications - Eric Voit (15 min.)
         https://tools.ietf.org/html/draft-gonzalez-netconf-5277bis-01

      AB: It would be good to consider the ability to do next gen filters
      (current ones have limitations)
                 EV: There has to be a base set and optional extensions.
      AB: Another dimension of complexity is the concept of a template for
      filters EV: We have case of XPath and 6241 filter. Filters are important.
      RT: some of the work within DTN may be reusable here (but may be a bit
      more than is required) EV: Filters is scary, we took existing ones.  This
      may be a space for vendor differentiation (at least at first) and then
      move more advanced filters into the standard at a later point ME: Can you
      report on discussion with former authors? EV: static subscriptions can be
      more complex (configure the receivers, origination comes from the
      source).  May need to think about call-home. ME: Is the recommendation to
      keep compatibility? ME: It is important to have Hector and Sharon as part
      of the review to ensure backwards compatilibity MJ: Is it a new work or
      5277bis? EV: I think we added items that are within the charter.  When
      does a bis become a new standard ? ME: If we keep existing functionality,
      it should be 5277bis. It is a chartered topic in any case. ME: Let's
      continue the discussion with orig authors, after a few weeks we can ask
      for adoption. EV: are notifications of interest in general ?
         -> show of hands of who read the draft ?  A few hands
         -> how many people have interest ?  many hands raised in the room
      GZ: we have some implementation of notifications and would want to sync
      up on the draft

Non-Chartered items:

      1. I2RS strawman proposal - S. Hares (15 min)
         https://tools.ietf.org/html/draft-hares-i2rs-protocol-strawman-00
        JTS: What is teh issue with CPU resources and memory:
        DB: I may want ro set a memory limit. Eg. a network topology poll, you
        may need to specify mem limit. JH: You may want to specify rate of
        notifications. JS: Specifying BW and memory in absolute terms is
        tricky. JH: It is just that some resource considerations are taken into
        account. JH: Discussions about mandatory transports.  There will be
        mandatory-to-implement transports, but also hooks in the initial base
        model to allow other future/optional transports & encoding.

      2. Restconf subscription and HTTP push for YANG datastores - Eric Voit
      (15 min)
         https://tools.ietf.org/html/draft-voit-restconf-yang-push-00

                ME: Comments about the name - it's not YANG Push
                KW: NETCONF Push for NC, RESTCONF Push for RC.  Proposed names
                for the 3 models:  netconf-push-transport,
                restconf-push-transport, and yang-push-model  (murmurs of
                assent in the room) KW: It's not a WG document. AB: Separate
                subscriber and receiver is interesting. There are 3 parts: 1 -
                data, 2 - interaction model, 3 - plumbing. I want to be able to
                conform to 1 part of it but use my own things for the others.
   RT: keep the specs modular.  We need to use as much "standard" parts as we
   can, but be able to use other transports/encodings.

      3. How many drafts for YANG push? - All (10 min)  Open
ME: There is interest, chrter doesn't make any difference between NC/RC Push,
we have to discuus what to do. Is it correct RC-YANG-Push is mainly transport?
MJ: there are 4 drafts (5277bis) ME: what does the group think ? TC: we've seen
this in other standards bodies - the need to separate the operations layer from
the transport/encoding layer of the protocols. ME: Misleading picture - why I
need NC if I want to use RC? ME: show of hands -> do we want 4 drafts ?  (yang
push, NC transport, RC transport, 5277bis).  Lot's of hands for "yes". None for
"no". ME: Adoption should happen within a few weeks. ME: We need co-authors
from other companies. EV: Agrees. ME: We may ask by name to co-author, e.g.
Juniper people. AOB