Minutes for NETCONF at IETF-96
minutes-96-netconf-2

NETCONF WG Session Minutes
IETF 96 – Berlin, Germany
WEDNESDAY, July 20, 2016

People who added Notes (Add you name here)
    - Eric Voit
    - Lada Lhotka
    - Jürgen Schönwälder

Actors
      AB = Andy Bierman
      ME = Mehmet Ersue
      BC = Benoit Claise
      SH = Susan Hares
      MJ = Mahesh Jethanandani
      RW = Rob Wilton
      KW = Kent Watsen
      EV = Eric Voit
      AC = Alex Clemm
      WE = Walid Elboki
      BL = Balazs Lengyel
      SB = Sergio Belloti
      MA = Mikael Abrahamsson
      LB = Lou Berger

Chartered items:
      1. Report from documents after WGLC: Restconf, Yang-patch - A.
Bierman (15 min.)
      8 reviews of YANG Patch
      AB: how to proceed?
      ME: Is there any issue from the reviews?
      AB: Use of terms.
      ME: Bring it to the ML immediately.
      BC: Evaluating date for IESG telechat.
      AB: I can update the current version.
      ME: Already in last call, go ahead and iterate as quickly as possible.
      Comments will not be lost BC: No need for another call for LC.

    slide 6
    ME: If there is no comment, we will proceed, so speak up now.

    slide 7:
    MJ: Will there be a new revision of YANG Patch?
    AB: Next week.

8. I2RS Requirements - Susan Hares
    SH: Was humm in I2RS saying requirements were sufficient for
    communications.  Need NETCONF response SH: Wants to see if we should review
    all requirements, no interest from the group in doing all RQTS.  Will focus
    on NETCONF specific SH: REQ 9/10 are relevant for NETCONF/RESTCONF (slide
    20) SH REQ-11 [Slide 21] contains multi-headed control needs.  Will add
    priority based on client to break ties. SH: REQ-13 & 14 - Don't specify how
    priority is accomplished, and do things deterministically SH: In 11:30 I2RS
    meeting, will be working alternative text for REQ-07

slide 18
    RW: Concerns with wording
    SH: You have priority as admin distance. It tells you what to do if you
    have repetition, who wins.
    RW: New wording is different.
    SH: Local config and ephemeral have priorities, we have to compare them.
    Please discuss it in the ML.
    ME: How come I2RS and NETCONF overlap?
    ME: Are the requrement covered in ephemeral draft?
    SH: Yes.
    ME: If any NETCONF WG member has comments, speak up now, we have to
    finalize the reqs. ME: Otherwise they will be seen as agreed. SH: We want
    to have a new rev very soon. Now it's time to raise comments. ME: RESTCONF
    not addressing these reqs. Do we have any table showing which draft will
    cover each req. SH: We didn't want to constrain the solutions. ME: Protocol
    strawman doc contains alternative solutions? SH: Feedback from NETCONF
    people - some of the reqs aren't implementable, the doc is my notes what I
    learned. ME: A table would be nice. If we don't know yet, we should decide
    how to do it. SH: If you send a request as NC chair, we will address it.
    ME: Could you provide a table as an overview of what is addressed in which
    draft? SH: Ok. KW: Q about priority and identity. Is it necessary for agent
    to discover the priority? SH: Yes. The server has to find the priority of
    the authenticated client. My implementation allows to query the data in the
    database. SH: Awaiting Open Source implementation for each of the I2RS
    requirements SH: We plan to provide open source implementation ASAP.

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

    EV: We have new contributors on board.
    ME: Number of authors is limited.
    EV: We needn't list all contributors as authors.
    ME: You can decide, I don't see much difference between authors and
    contributors. EV: The conversation is open, nobody is excluded. Need to see
    text from contributors to be made authors.

 3. Subscriptions for Event Notifications (RFC 5277bis) - Eric Voit (15 min)
     https://tools.ietf.org/html/draft-gonzalez-netconf-5277bis-02

    Alex Clemm is presenting.
    EV: How shall we proceed? Each draft individually or as a package?
    ME: As a package.
    ME: EN4 question. Is an integration with GPRC necessary?
    AC: Not necessary.
    EV: Transport should be independent of the subscription model.
    WE: Correlation of multiple subscriptions. Might be useful if you don't
    want to overload the server. EV: It is not in 5277bis, but it is in YANG
    Push - we have priorities there. AC: The notifications will carry
    identifiers, so you can find duplicates and optimize. WE: Is there
    mechanism to signal overload? AC: It is up to the receiver to modify
    subscription parameters. WE: Is there failure signalling mechanism? AC:
    Start time in the future - one of the messages indicates the subscription
    is starting. ME: EN5 and netconf-notif should be resolved, we need one
    document. ME: 5277bis should completely replace 5277.

4. NETCONF Transport for Event Notifications - Eric Voit (10 min)
   https://tools.ietf.org/html/draft-gonzalez-netconf-event-notifications-00

    MJ: Will new RPC replace old ones?
    EV: The old ones will stay.

5. RESTCONF & HTTP Transport for Event Notifications - Eric Voit (5 min)
   https://tools.ietf.org/html/draft-voit-netconf-restconf-notif-00

   slide 22
   AB: This draft started as "We don't need RESTCONF and use HTTP directly"
   EV: We hope the same mechanisms for configuring SSE are in HTTP and RESTCONF.
   ME: Should we have a mandatory transport?
   MA: What do you mean by transport?
   EV: RESTCONF or NETCONF.
   MA: Whatever you do, you exclude some implementation.
   KW: I don't have preference.
   BL: It is relevant even for dynamic subscription. I'd propose NETCONF to be
   mandatory. ME: Could you send a poll question to ML? EV: We also need to
   identify reasons for everybody's choice. BL: If you have NETCONF and YANG
   Push, you should support NETCONF transport. ME: Already agreed on doing this
   work, adoption postponed. Any objections to adopting all four drafts? No
   objections raised. ME: The drafts are now seen as adopted as WG item. The
   meeting agreement needs to be validated on the maillist. ME: Please upload
   the next version as draft-ietf and co-chairs will accept on the portal.

6. System Keychain Model - K. Watsen (10 min)
   https://tools.ietf.org/html/draft-ietf-netconf-system-keychain-00

   slide 6
   AB: IANA crypt hash already does it.
   KW: This is issue #5.

   KW: Issue #2 - too complex for discussion here.  Kent will take to the list.
   MJ: Do we understand the proposed solution from Martin?
   KW: No.

   Issue #3
   JS: The name should include info about what the scope is.
   KW: Agrees
   KW: Issue #4: user auth credential viablilty for other protocols will be
   determined in the future BL: Is it just a grouping? KW: No, it is
   protocol-accessible data nodes.
    AB: mechanisms for encrypting from clear-text is in a spec from IANA
    (leaf-type IANA crypt-hash) BL: It could be encoded in the password text.

7. SSH Client Server Model - K. Watsen (5 min)
   https://tools.ietf.org/html/draft-ietf-netconf-ssh-client-server-00
    KW: Updates made as described in slides, no known open issues

8. TLS Client Server Model - K. Watsen (5 min)
   https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server-00

9. NETCONF Client Server Model - K. Watsen (5 min.)
   https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server-00
   KW: New feaures added, open issue ssh-listen feature?
   AB: This lists what port you are on?
   KW: No. This is about just allowing call home as the only option (cases like
   BBF for example) KW: Will not make listen mandatory  (i.e., keep the
   ssh-listen feature)

   10. RESTCONF Client Server Model - K. Watsen (5 min.)
   https://tools.ietf.org/html/draft-ietf-netconf-restconf-client-server-00

   BC: How many modules depend on this series of drafts?
   KW: syslog and Chris Hopps' routing module
   BC: Isn't this then a bottleneck?
   KW: After splitting we can prioritize the drafts.
   BC: Be sure to get the priorities right.

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

    KW: many updates and open issues on draft, little commentary on mailing
    list.  Needs more interaction issue #12 AB: Many implementations treat some
    of these parameters as bootstrap. Changing them at runtime may break some
    implementations. Big architecture change inside the implementation. KW:
    Device comes up with factory configuration and the device then loads the
    config via call home, so it is in fact bootstrap config.

    PS: Is the difference between merge and replace important?
    KW: Some customers want it.
    AB: Agrees with Phil - treat it as copy-config. It just makes the file
    bigger. EV: I like how it is done here, you may get config from several
    places. KW: This is not the case of dealing with multiple sources. RW: If
    we have the choice, can some parameters be optional? KW: Yes.

    Issue #17:
    RW: My preference is NOT to do nothing. I support option #3 - encode both.
    KW: it is good not to have to worry about outdated security methods, hence
    option 1 is not a good idea. ME: If somebody has comments, please speak up
    on the ML, otherwise we will proceed.

Non-Chartered items:

2. Refined YANG datastores with Meta-data (10 min)
   https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-02

   slide 3
   PS: Isn't "persistent" a bad name? Some implementations have running
   non-persistent. AB: Use unique RPC names. AB: Protocol interaction issues
   are critical. I'd love to see an implementation. RW: OpenConfig is that
   example. WE: What does it mean in terms of YANG? KW: I2RS - some datastores
   can be annotated. WE: Effects of lock/unlock? EV: System-created - I'd like
   to have a complete solution. MA: Preconfiguration - is it in persistent? RW:
   Yes. RW: Preconfigurated things may not have data in operational state.

   slide 5
   : Intended config only for R/O part? Why is intended optional?
   RW: As a client you don not need this information.
   AB: Solution seems reasonable. I can have many layers of daemons - it's
   never been clear what "applied" means. RW: Then definition of "applied" is
   "applied as far as you can". KW: What is intended if it's not running? RW:
   Running is not well defined, so that's why I split is.

   JS: I want a solution for what the models should be, we have a session in
   the afternoon. AB: I prefer to keep the term "running", just clarify it.

   ME: This means changes to NETCONF, NETCONF WG should be involved.
   JS: The architecture work should be done in NETMOD, protocol stuff in
   NETCONF. BC: I don't care, do it jointly, if you can't agree I will make a
   decision. KW: Impact to NETCONF/RESTCONF should go through NETCONF. LB:
   Things that don't depend on protocols can be done in NETMOD. BC:
   Observation: name of the group? We are now doing more than NETCONF.