Minutes IETF100: netconf
minutes-100-netconf-01

IETF 100, Singapore, November 13-17, 2017
Thursday, November 16, 2017
Afternoon Session II (15:50-17:50)
Collyer Conference Room

Audio stream:   http://ietf100streaming.dnsalias.net/ietf/ietf1003.m3u
Etherpad:       http://etherpad.tools.ietf.org:9000/p/notes-ietf-100-netconf
Meetecho:       http://www.meetecho.com/ietf100/netconf
Jabber:         xmpp:netconf@jabber.ietf.org?join

Available post session:
  Recording:    https://www.ietf.org/audio/ietf100/
  YouTube:      https://www.youtube.com/user/ietf/playlists

WG Chairs:      Mahesh Jethanandani and Kent Watsen

Ledgend:
Kent: Kent Watsen
Rob: Robert Wilton
Mahesh: Mahesh Jethanandani
Benoit: Benoit Claise
Martin: Martin Bjorklund
Juergen: Juergen Schoenwaelder
Guangying Zheng
Qin Wu
Tim: Tim Cary
Walid: Walid Ebokl
Balazs: Balazs Lengyel
Eric: Eriv Voit
Alex: Alex Clemm
Frank: Frank Xialing
Zhengguangying (Walker)
Xufeng

Agenda bashing (5 min)
WG status review (10 min)

Mahesh: rfc6536bis is going through wordsmithing on the last set of changes.
Once agreed,
        will send the draft back to Benoit for publication. YANG Push suite of
        drafts will be discussed today, and their status will be discussed
        after the presentation by the authors.

Chartered items (80 min)

1.2.3 NETCONF, NETCONF, YANG Library Update to support the NMDA (30 min)
   https://tools.ietf.org/html/draft-ietf-netconf-nmda-netconf
   https://tools.ietf.org/html/draft-ietf-netconf-nmda-restconf
   https://tools.ietf.org/html/draft-ietf-netconf-rfc7895bis
   Rob Wilton  (start: 16:15)

   Andy:  would like an explicit NMDA capability rather than relying on
   a get-data request against the new YANG library.  Authors do not think that
   this is required. Any comments from the room?  None.

   Presenting slide #13 (YANG Library - Proposed):
   Lada: Is the structure extensible enough for other datastores that may have
   significantly
         different schema than these NMDA datastores?
   Rob: This is a tradeoff, having a more simple list restricts what you can do
   with it,
        considering spliting the "not-implemented-in" into a choice statement of
        "implemented-in" vs "not-implemented-in".
   Lada: In the version that you are going to show next, where there is a list
   of schema,
         it would be easily possible to have the NMDA schema alongside other
         schema that can be assigned to other datastores.
   Rob: Yes.
   Benoit: Will the module have the capability to support modules that are
   dependent on
           things like license or presence of line cards. How to export from a
           server all potential modules? E.g. licensing might allow for
           additional modules
   Rob: No, this is not possible with the current version but the next version,
   about
        to be presented, would be capable of doing this.
   Kent: Refering to yesterday's discussion in NETMOD, would it be possible to
   support
         sem-ver (semantic versioning).  don't want to hold up this work, but
         thinking of flexibity for the future.
   Rob: Unclear even with semantic versioning whether a device is allowed to
   report
        multiple revisions of a module.
   Balazs; Each sem-ver version should have one date based version,
   so that sem-ver
           would be just an additional leaf in here in addition to the version
           field (date).

   Presenting slide #14 (YANG Library - Proposed with schema mount support):
   Rob: Any comments on whether this is better, simpler?
   Lada: I would support this last version, not only support merger with
   schema-mount YAM,
         but its more future proof as well, since it is hard to change a
         container into a list.  Also could be used for different sets of
         licenses.
   Rob: Yes, agree.  If the I2RS datastore had a very different schema from
   conventional,
        then it might be better to define a separate schema for the I2RS
        modules and then reference that by the datastore.
   Martin: datastore should be outside the schema list
   Rob: Yes, that is a bug in the slides.
   WG LC aimed at this year

4. Zerotouch Bootstrapping (5 min)
   https://tools.ietf.org/html/draft-ietf-netconf-zerotouch
   Kent Watsen  (start: 16:35)
   Mahesh: do you believe draft is ready?
   Kent: yes, with editorial changes
   Mahesh: Asks the room: Can we move it past last call: no objection in the
   room


5. Keystore Model (5 min)
   https://tools.ietf.org/html/draft-ietf-netconf-keystore
   Kent Watsen  (start: 16:40)
   Kent: failed last call because the one review that was offered asked for
   substantial changes

6. SSH/TLS Client Server Models (5 min)
   https://tools.ietf.org/html/draft-ietf-netconf-ssh-client-server
   https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server
   Kent Watsen  (start: 16:45)

7. NETCONF/RESTCONF Client Server Models (5 min)
   https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server
   https://tools.ietf.org/html/draft-ietf-netconf-restconf-client-server
   Kent Watsen  (start: 16:50)

   Rob: Are the containers inside the groupings?
   Kent: No, containers are using the groupings
   Juergen: if the client container is useless, remove it
   Kent: follow up on the list
   No questions.

8. Subscribing for Notifications (5 min)
   https://tools.ietf.org/html/draft-ietf-netconf-subscribed-notifications
   Alex Clemm / Eric Voit  (start: 16:55)

   Eric on the full set of drafts
   Eric: Hackaton demo was held, received award as part of joint work with SACM
   & CoRE WG.
         DTN and I2NSF WG also expressed need for Yang push during their
         sessions

                Issue SN#4: Can the transport vary for different receivers of a
                subscription? Rob: keep simple, no benfit for complex solution
                Guangying Zheng(From Huawei): Have reviewed all these drafts
                and discuss the
                    comments on mailing list, and all issues were confirmed.
                Walid Elbokl (Nokia): Keep it simple
                Martin (Jabber): okay with varying by receiver, but transport
                and encoding
                    should go toghether (i.e. keep it simple)
                Room: nobody wants the more complicated models for SN#4 .  A
                single transport
                    per subscription is desired.


                Issue SN#5: How to represent VRF ?
   Rob: wants a new option 3. Use a leafref to VRF under a feature statement
   (the feature
       itself should be defined in network-instance module), and thus not have
       a dependency on schema-mount directly.
   Eric: We can't influence network instance model, can be a problem
   Qin Wu (from Huawei): I like to offer option 4. In nat-yang-model, we are
   using identity
       to represent VRF because we felt that network instance is not stable
       reference.
   Eric: We dont see the network-instance stable. String is flexible
   Rob: are there other models with the same problem?
   Eric: dont know
   Kent: many modules in routing area are using network-instance
   Eric: routing models in rtwg are more complex than that from other groups,
   and hence more
         likely comfortable with leafrefs
   Mahesh: if using string, how would the string value be validated, would it
   use a must statement? Eric: yes that's the issue Mahesh: MUST use
   a 'must' statement? Eric: that brings the same problems  (effectively the
   same as a 'leafref')

   Martin: agrees with Rob's proposal (option #3)
   Rob: even if they don't do it, next best is to put feature in this model
   Eric: dependency still remains with a feature due to import
   Eric: we might end up with many features
   Kent: too many options, go to the mailing list
   Balazs: would like to separate the questions using a feature and
   string/leafref Juergen: what is the cost to running code? Martin: that fact
   that there *is* a dependency if you need the VRF Lou, just walking into the
   room: how about putting the leafref under a feature
        (i.e., like the room had just been discussing)
   Lou: If you are building a box and you want to support network instances,
   you want to
        have support for it and be able to reference the NI model. If you are a
        box that does not use VRFs, you will not support that feature, which
        thus has no impact on your implementation.
   Eric: That is the proposal that Rob makes, let us take it to the list.
   Lou: It does really make sense. That if you are supporting a VRF, a module
   whose sole
        purpose is that, to define a feature that does not support that. It
        seems really foolish. Why would you allow something that does not
        support the main function.
   Eric: Just want to make sure that there is guidance.
   Lou: You are breaking ground with this, it should be a feature, and you
   should set
        that as a pattern.
   Eric: I will salute it.
   Martin: you can also augment the VRF leaf from  a separate small module to
   avoid import. Juergen: the code is irrelvant for the IoT device. Martin: I
   agree with the compile time comments. It should not be a problem. Eric:
   Sounds like we do feature, and a leafref and people are ok. Kent: What
   Martin was saying was use the augment instead of a feature, as another
   option.
         That is the proposal we are using in SSH and TLS client/server drafts
   Eric: As an augment in a separate model, to begin with?
   Kent: We are not defining support for VRFs, initially, with the assumption
   that future
         drafts will add in the VRFs as needed.
   Eric: I would like to keep it there
   Alex: problem is we dont have if-feature on import
   Lou: like augment solution. I do not understand what is the problem. Seems
   like a
        development time, compilation check. Device does not have to implement
        schema mount.
   Eric: Based on the feedback, most people seem ok with an import of the
   network-instance,
         and the use of a vrf if-feature.  Will confirnm on the list

9. Subscribing to YANG datastore push updates (5 min)
   https://tools.ietf.org/html/draft-ietf-netconf-yang-push
   Alex Clemm / Eric Voit  (start: 17:00)

   Eric presenting YANG push.

   Kent: model must be nmda compliant
   Eric: we will do it

   Tim Carey: There will be a state version of this model, something we put in
   the appendix?
              Some will need it
   Mahesh: Only for drafts with existing impleentations
   Tim: modules that are not yet RFC? Are we saying that this draft will not
   have a -state version. Kent: Possibly, it's not mandatory, but we have to be
   mindful of market demand. It seems that we
         (draft-authors / YANG-designers) should define -state versions for new
         modules too, at least for some time.
   Tim: we want to adopt the feature, but nmda implementation might lag.
   So please create -state
        subtree as well
   Eric: we will have both versions

10. NETCONF Support for Event Notifications (5 min)
    https://tools.ietf.org/html/draft-ietf-netconf-netconf-event-notifications
    Alex Clemm / Eric Voit  (start: 17:05)

   Eric presenting NETCONF notifications.
   Walid Nokia: examples need further scrubbing.  Examples do not match the
   model. Balazs: Agree on working on three drafts.

11. RESTCONF & HTTP Transport for Event Notifications (5 min)
    https://tools.ietf.org/html/draft-ietf-netconf-restconf-notif
    Alex Clemm / Eric Voit  (start: 17:10)

    Eric presenting RESTCONF notifications.
    No comments.

12. Notification Message Headers and Bundles (5 min)
    https://tools.ietf.org/html/draft-ietf-netconf-notification-messages
    Alex Clemm / Eric Voit  (start: 17:15)

   Martin: what transports have been implemented?
   Eric: netconf in cisco (production, XE 16.6), JAVA and
   Python opensource subscriber,
         Huawei using netconf publisher

   Kent: post YANG-Push suite presentation poll:
   How many people in design team: a few
   How many read these 3 drafts : good number
   How many think these 3 drafts are ready for LC:  good number
   Eric: give two weeks for updates
   Kent: Discussion and resolutions need to be confirmed on the mailing list.

13. UDP based Publication Channel for Streaming Telemetry (5 min)
    https://tools.ietf.org/html/draft-ietf-netconf-udp-pub-channel
    Zhengguangying (Walker)  (start: 17:20)

    Walker presenting (via MeetEcho)
    Kent: asks about when Milestone for LC can be set?
    Walker: didn't understand the problem (likely MeetEcho issue)
    Kent: will take it offline.

Non-Chartered items: (25 min)

14. Subscription to Multiple Stream Originators (5 min)
    https://datatracker.ietf.org/doc/draft-zhou-netconf-multi-stream-originators
    Zhengguangying (Walker)  (start: 17:25)

    Kent: premature to ask for adoption
    Alex: was originally part of draft-ietf-netconf-udp-pub-channel

15. YANG PUSH Based Generalized Network Control Automation Problem Stmt. (5 min)
    https://datatracker.ietf.org/doc/draft-bryskin-netconf-automation-framework
    Igor Bryskin or Xufeng Liu  (start: 17:30)

    Frank Xia: existing work supa WG and xx WG. Do you have a connection?
    Xufeng: we know them and monitor it
    Frank: lets work together

16. Coap Transfer (5 min)
    https://tools.ietf.org/html/draft-birkholz-yang-push-coap-problemstatement
    Henk Birkholz  (start: 17:35)

    Xufeng presenting
    Mahesh: only telemetry or general solution?
    Xufeng: general, presented it to CORE WG
    Kent: What do you want here in the NETCONF?
    Alex: adoptation in Core WG, just presentation here


17. Smart filters for Push Updates - Problem Statement (5 min)
    https://datatracker.ietf.org/doc/draft-clemm-netconf-push-smart-filters-ps
    Alex Clemm  (start: 17:40)

    Balazs: connect with vallin-alarm draft. Send alarm based on thresholds
    Martin: Do you have any solution proposal, it would be interesting to see.
    Alex:

     Eric:extension for yang push.   Customers ask for thresholds for filters
     and objects Tim: is this tied to event-condition-action architecture?
     Alex: separate. They want to use this as one source for events Kent:
     Natural progression of yang push Kent: who is interested? good number

18. Discrepancy detection between NMDA datastores (5 min)
    https://tools.ietf.org/html/draft-clemm-netconf-nmda-diff-01
    Alex Clemm  (start: 17:45)

                 Rob: useful work
                 Kent: who is interested? good number
                 Mehmet: shouldnt it be in netmod?
                 Rob: No, as this extends existing NETCONF drafts