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

Minutes of the Netconf WG Session in IETF 92 [2015-03-24 Tue]
=============================================================

**** Andy Bierman (AB) - RESTCONF
***** slide 5
      - Juergen Schoenwaelder (JS): what happens with YANG 1.1 anydata?
      - AB: If we have a standard notion of layers, it will be the the
        same. It has to be defined depending on how it is defined. I
        see no reason to mention YANG 1.1.
***** slide 6
      - JS: Unified datastore persistence not defined, that's a problem.
      - AB: NETCONF has no concept of persistence. It is a performance issue.
***** slide 7
      - Dean Bogdanovic (DB): Giving the NV option is confusing. It should
        be always persistent.
      - AB: This exposes the option of NV-storing or not. It makes a
        difference for performace-sensitive apps.
***** slide 8
      - Martin Bjorklund MB): Mixing two things - URL can stay.
      - AB: YANG Patch will change and this issue will go away.
      - JS: Concerned about making some proto spec action that's
        really not so.
      - AB: We should make an effort to remove all RESTCONF-specific
        stuff.
      - Phil Shafer (PS): Why do you expect that not all models will be
        available.
      - AB: YANG modules have a lot of RPCs that are tied to sessions,
        these are not supported.
      - PS: RESTCONF and NETCONF should be able to get to the same
        data.
      - AB: That could be implementation restriction - business &
        marketing decision.
***** slide 9
      - Peter van Horne (PvH): It should be mandatory.
      - Chairs: Take it mailing list.
***** slide 10
      - JS: I2RS distinction ephemeral v. config. Unified datastore
        doesn't solve this.
      - Mehmet Ersue (ME): We should start WGLC ASAP.
      - PS: Can you answer the q about scope?
      - ME: This has to be discussed in ML
**** Andy - YANG Patch
***** slide 4
     - PS: NETCONF ops not specified - should it be clarified in YANG 1.1.
     - MB: It is NETCONF issue.
***** slide 6
     - JS: YANG Patch is RESTCONF patch, it is part of scope
       discussion. Is the server expected to translate a RESTCONF op
       -> NETCONF?
     - MB: Why not make it avaliable in NETCONF as well?
     - AB: Pointless to use edit-config in two ways.
     - PJ: You can ask the same q for unified datastore.
     - I wish we used unif. datastore in NETCONF.
***** slide 14
     - Kent Watsen (KW): I support using these features in NETCONF as well.
     - JS: What you are doing is a new RPC, should work.
     - PS: We should maximize the NC/RC overlap.
**** Andy - YANG Library
***** slide 4
      - Lada Lhotka (LL): Why is the conformance leaf needed? Modules that
        are used only for typedefs and groupings needn't be in YANG
        library.
      - Conformance should be changed to enumeration. Specially, as it relates to
        'import by revision'.
      - AB: YANG library contains all modules that the server
        implements.
      - LL: The dependence on yang-json can mean that RESTCONF and
        other docs will have to wait on YANG 1.1 because of the
        decision of the NETMOD WG to address anydata in yang-json.
      - JS: YANG Patch is a client of anydata.
**** Andy RESTCONF Collection Resource
      - Not much work done on the draft.
**** Kent - Call Home
      - KW will send -05 version in couple of weeks.
      - Chairs: May need a second LC.
**** Kent - server model
      - 13 issues.
***** slide 10
      - AB: Prefer just seconds.
      - PS: Complexity breeds bugs.
***** slide 11
      - MB: Is it obvious it is needed?
***** slide 15
      - Mikael Abrahamsson: Why not using TCP keepalives?
      - KW: Not encrypted, can be spoofed.
      - PS: Is it necessary.
      - KW: Usual approach in similar application.
      - Jeff Hass (JH): SSH may think it is up but the application on top
        of it in fact isn't. That's why keepalives are done in the app.
      - ME: Is it really needed to move the whole section to CH draft?
      - KW: This is about how to implement keepalives.
***** slide 16
      - MB: An option would be to say MAY.
***** slide 17
      - PS: Dependence on Y1.1 is not a problem.
      - KW: It came from Honolulu, now it may be reasonable to use
        Y1.1 features.
      - 16 Y and 1 N for including YANG 1.1 features.
      - ME: Rough consensus to include Y1.1 features despite possible
        delays.
**** Kent - Zero Touch
***** slide 13
      - ME: ANIMA requirements should be brought in as written text.
      - ANIMA chair: We don't have official requirements towards NETCONF
      - Michael Behringer (MB): IN ANIMA, nodes can talk to each other. We
        can merge the two requirements.
**** Jeff Haas - I2RS requirements
***** slide 8
      - Sue Hares (SH): we need help with ephemeral state
      - Benoit Claise (BC): This is an individual draft, how is it related to
        I2RS architecture?
      - JH: This is arch doc translated to YANG terms. Need help with defining
        ephemeral state. What it means is not clear.
      - SH: Traceability and pub-sub are requiremebts, too, but we
        aren't asking for help there. Would rather have a discussion that send
        a set of requirements.
      - Dan B, Martin, Ken and Andy to help with ephemeral state.
      - ME: Propose to have a conference call in a few weeks.
      - JH, SH: Support.
**** Eric Voit - pub/sub
     - ME: Schedule for this work?
     - EV: Not decided yet.
     - JH: It has a priority.
**** Alex Clemm (AC) - Subscribing to push updates
     - ME: Who read the draft? Not many. Please read the draft.
     - ME: Does this draft address the pub/sub reqs fully?
     - AC: It doesn't allow for alternative transport.
     - ME: Should NETCONF address this? 12 yes and no no’s. Support was indicated.
**** Liu Bing - Processing multiple requests
     - ME: Who read it? 5. All of them support working on this topic.
       ME: Authors please seek for support on mailing list.
**** Time Stamp in NETCONF
     - Ran out of time.
     - ME: Authors please seek for support on mailing list.