* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Netconf Status Pages

Network Configuration (Active WG)
Ops Area: Benoit Claise, Warren Kumari | 2003-Apr-30 —  
Chairs
 
 


IETF-100 netconf minutes

Session 2017-11-16 1550-1750: Collyer - Audio stream - netconf chatroom

Minutes

minutes-100-netconf-01 minutes



          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
          
          



Generated from PyHt script /wg/netconf/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -