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