Agenda for the NETCONF 107 WG Session ------------------------------------- Session: Monday April 6th PDT: 07:00-09:00 EDT: 10:00-12:00 UTC: 14:00-16:00 CST: 22:00-00:00 WG Chairs: Mahesh Jethanandani (mjethanandani at gmail dot com) Kent Watsen (kent plus ietf at watsen dot net) Available During Session: ICS: https://datatracker.ietf.org/meeting/interim-2020-netconf-01/sessions/netconf.ics Etherpad: https://etherpad.ietf.org/p/notes-ietf-107-netconf Slides: https://datatracker.ietf.org/meeting/interim-2020-netconf-01/session/netconf Jabber: xmpp:netconf@jabber.ietf.org?join JOIN BY WEBEX: URL: https://ietf.webex.com/ietf/j.php?MTID=m683e06fe29b0582d35985946f168a138 Meeting number (access code): 612 328 094 Meeting password: EUh3WeggW83 JOIN BY PHONE 1-877-668-4493 Call-in toll free number (US/Canada) Tap here to call (mobile phones only, hosts not supported): tel:1-877-668-4493,,*01*612328094%23%23*01* 1-650-479-3208 Call-in toll number (US/Canada) Tap here to call (mobile phones only, hosts not supported): tel:%2B1-650-479-3208,,*01*612328094%23%23*01* Toll-free calling restrictions https://www.webex.com/pdf/tollfree_restrictions.pdf JOIN FROM A VIDEO SYSTEM OR APPLICATION Dial sip:612328094@ietf.webex.com You can also dial 173.243.2.68 and enter your meeting number. Join using Microsoft Lync or Microsoft Skype for Business Dial sip:612328094.ietf@lync.webex.com Can't join the meeting? Contact support here: https://ietf.webex.com/ietf/mc Available After Session: Recording: WebEx recording be made available after the meeting. Jabber Logs: https://www.ietf.org/jabber/logs/netconf Etherpad: https://etherpad.ietf.org/p/notes-ietf-107-netconf Slides: https://datatracker.ietf.org/meeting/interim-2020-netconf-01/session/netconf Introduction Chairs (10 minutes, 00:00) Session Intro & WG Status Chartered items: Kent Watsen (20 min, 00:10) Status and Issues on Client-Server Suite of Drafts https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-14 https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors-09 https://tools.ietf.org/html/draft-ietf-netconf-keystore-16 https://tools.ietf.org/html/draft-ietf-netconf-tcp-client-server-04 https://tools.ietf.org/html/draft-ietf-netconf-ssh-client-server-18 https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server-18 https://tools.ietf.org/html/draft-ietf-netconf-http-client-server-02 https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server-18 https://tools.ietf.org/html/draft-ietf-netconf-restconf-client-server-18 Michael Richardson (in Jabber) writes: RSA for SSH might the same math as for TLS, but the format of the keys is not, and the security properties can be different, particularly when it comes to what is in the certificate. They are effectively different things. There are properties that might be in common, and maybe that's worth describing, but I'm not sure what the win would be. Rich + Rob + Jason (and Juergen via email after the call) prefer Options 2 and 3 over Option 1 Action: chair to poll WG for selection preference after meeting. Mahesh Jethanandani (10 min, 00:30) An HTTPS-based Transport for Configured Subscriptions https://tools.ietf.org/html/draft-ietf-netconf-https-notif-02 Rob Wilton: regarding mandatory encoding requirements, perhaps "no interoperability", let the market decide. Publisher uses out-of-band mechanism (e.g, via implementation or configuration) to choose which encoding to use. Mahesh: There are some subtleties about this, let's take it to the list. START SIDE CONVERSATION: Eric Voit.: "subscription-started" is a mandatory message in a configured subscription. It provides the configuration specifics as part of the initial subscription setup. This should be acknowledged with an 'ok' prior to event records being sent. This is a way to stop DDoS attacks, as a receiver MUST accept the subscription before records are sent. (see https://tools.ietf.org/html/rfc8639#section-2.7.1 ) Authors: "subscription-started" is a notification. Notification are one-way and hence do not have acknowledgments. There is no way for the receiver to acknowledge the publisher's notification. Hence this notification cannot help with encoding selection. Related to prior on-list discussion (Jan 27/28), hardcoding RFC5277 style for this notification doesn't change to fact that the notification cannot be acknowledged. END SIDE CONVERSATION Qin: could the capability exchange go the opposite direction (i.e., per Qin's other draft). Mahesh: Take it to the list. Thomas: why mandate any specific (XML, JSON) encodings, could CBOR be used? Mahesh: currently the draft supports XML/JSON with CBOR as possibly learned. Eric and Rob were in queue for comments, but said that they would take them to the list. Non-Chartered items: Jason Sterne (10 min, 00:40) YANG Module Version impact on the NETCONF/RESTCONF protocol (no draft) Kent: (As chair) the protocol work needs to be done in NETCONF (Mahesh and Rob agrees) Action: authors to factor out NETCONF WG parts into NETCOF I-Ds [note from Jason S] I think the decision during the discussion was to keep it in 1 draft for now (in the NETCONF WG), and decide later (i.e., at time of adoption) as the draft progresses how/if to split it Qin Wu (10 min, 00:50) Self-explanation Data Node Tag Capability https://tools.ietf.org/html/draft-tao-netconf-notif-node-tag-capabilities-01 Action: chairs to discuss possible creation of a design team. Peng Liu (10 min, 01:00) Bulk Subscription to YANG Event Notification https://tools.ietf.org/html/draft-wang-netconf-bulk-subscribed-notifications-01 Kent: great to see so much interest in telemetry data work...to what extent are these ideas prototyped? Qin: some ideas have been prototyped, e.g.,telemetry data tagging, adaptive subscription, bulk subscription and telemetry data export, in plan Kent: it would be good for the WG to get a feel for how much of all this work (not just this presentation) is being prototyped vs just an idea... Action: chairs to discuss possible creation of a design team. Peng Liu (10 min, 01:10) Telemetry Data Export Capability https://tools.ietf.org/html/draft-tao-netconf-data-export-capabilities-00 Mahesh: isn't the transport+security+ bundling already set by selecting the transport method. E.g. The HTTPS notification draft already decides the security and the bundling of messages used in sending the notification. So by deciding HTTPS way to send notification, are you not already deciding the security, bundling and compression methods? Peng: (response not clear) Rob: should we look at all the capabilities for completeness? e.g., the "transport" selection should be a "leaf-list" Peng: yes Kent: to Rob, are you suggesting the notification-capabiities draft should be put on hold? Rob: no, that should proceed Kent: wondering if there should be a DT and/or an overarching presentation for the collection of subscription-related presentations. The collection of presentations currently looks like disjoint work. Action: chairs to discuss possible creation of a design team. Qin Wu (10 min, 01:20) Adaptive Subscription to YANG Notification https://tools.ietf.org/html/draft-wang-netconf-adaptive-subscription-00 Kent: is there a way to vary the rate based on percentage variation, as opposed to absolute value? Qin: yes Pierre Francois (10 min, 01:30) Subscription to Multiple Stream Originators https://tools.ietf.org/html/draft-unyte-netconf-multi-stream-originators-00 Thomas Graf presenting. Mahesh: how is this related to previous draft with same name? Thomas: will go and look. Mahesh: How does this draft address the closed ecosystem issue raised during IETF 104 and 105 by Tim Carey and Kent? Also how does one discover if there are linecards in the system or not? Is all this in scope or out of scope for this draft. Thomas: It is in scope. Pierre Francois (10 min, 01:40) UDP based Publication Channel for Streaming Telemetry https://tools.ietf.org/html/draft-unyte-netconf-udp-pub-channel-00 Mahesh: please try to answer the questions that were raised in previous IETFs (104, 105) Peirre: okay. Benoit Claise (10 min, 01:50) Node Capabilities For Closed Loop Automation https://tools.ietf.org/html/draft-claise-netconf-metadata-for-collection-00 (Munish Nayyar presenting) Mahesh: It is great to see so much interest in node-tagging capability. Perhaps there should a design team that can be formed to looking at this problem holistically. Action: chairs to discuss possible creation of a design team. Bluesheet 41 in webex (at max) 10 in jabber (all also in webex} Name Affiliation ====================== ============================ 1. Kent Watsen Watsen Networks 2. Mahesh Jethanandani Kloud Services 3. Qin Wu Huawei 4. Balazs Lengyel Ericsson 5. Jan Lindblad Cisco 6. Susan Hares Huawei 7. Jason Sterne Nokia 8. Thomas Graf Swisscom 9. Warren Kumari Google 10. Rob Wilton Cisco 11. Pierre Francois INSA-Lyon 12. Michael Richardson Sandelman Software Works 13. Eric Voit Cisco 14. Joe Clarke Cisco 15. William Lupton Broadband Forum 16. Charles Eckel Cisco 17. Reshad Rahman Cisco 18. Yuji Tochio Fujitsu 19. Rich Salz Akamai 20. Tim Carey Nokia 21. Yoshifumi Atarashi Alaxala 22. Dieter Beller, Nokia 23. Michael Scharf Hochschule Esslingen - University of Applied Sciences 24. Gungying zheng Huawei 25. Gang Yan Huawei 26. Yunan Gu Huawei 27. Bo Wu Huawei 28. Maurice Angermann Siemens AG 29. Matthias Arnold Swisscom 30. Tianran Zhou Huawei 31. Munish Nayyar Cisco 32. Adithya Sesani Cisco 33. Éric Vyncke Cisco 34. Juergen Schoenwaelder Jacobs University 35. Andy Bierman. Yuma Works