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.