Minutes of the IETF 84 NETCONF WG Session July 30, 2012, 1540-1710 =================================================================== * Actors BW = Bert Wijnen ME = Mehmet Ersue KW = Kent Watsen MB = Martin Bjorklund JS = Juergen Schoenwaelder LL = Ladislav Lhothka BC = Benoit Claise WH = Wes Hardaker BL = Balazs Lengyel DR = Dan Romascanu TI = Tomoyuki Iijima * Agenda and WG Status ME gave the WG status and listed agenda items. * NETCONF over TLS No presentation, ready for WGLC according to chairs, but must be submitted BW: Accept as WG document then last call MB: Has comments on the YANG data model to be sent to the list, updates to YANG Modules are needed. KW: Since BEEP transport is going to become historic, requests to fix a reference to BEEP in the security considerations. BW: Room seems to have agreement to accept this document and move the revision to WG last call. * NETCONF Light KW presents his slides. AB: edit-config and delete-config are already optional if you do a read-only implementation (and you do not advertise say writable-running). Only locking and filtering are made optional now copy config is really ais kind of duplicate of get-config. MB: but if you want to support writes, copy config is needed AB: edit is not more complicated then copy MB: agrees AB: likes the intent, but thinks some of the items are already optional. BW: The question today is whether we as a WG accept this work item, not necessarily whether the set picked is right. AB: No problem accepting with work, for me even only get-config and close-session would be sufficient for a minimal base. MB: The document mentions DTLS, are you suggesting to write a DTLS transport? KW: I dont want it, he likes SSH, he does not want DTLS. BW: DTLS would be a separate document work item draft LL: Why do we need two separate versions of NETCONF? It seems the arguments are primarily political. Why not do instead NETCONF 1.2? BW: we already had this discussion KW: I agree with LADA, but he can live with a separate name "Lite" BW: We already had the debate, lets stick with having a new name BW: The proposal is to accept this document as a WG document and that we get chartered to do NETCONF Light, not discussing whether this should be called NETCONF 1.2 or so. Lets accept this as a WG item (depending on charter) Showing hands: 14 hands for Opposed 1 AB: I want to make sure that it does not take two SSH sessions to connect to a server. BW: good comment, but that can be done during the WG work BW: do we really want this on standard tracks BC: It could either be Proposed Standard or Experimental. Depends on its potential success. Will this be a base for the constrained devices draft. Propose experimental, later maybe standards track MB: Seems strange to have two competing protocol versions on the standards track. AB: standards track call it core JS: Based on implementation experience on really small devices, it is not at all clear that this is the right approach for really small constrained devices. Experimental KW: Devices are faking Netconf, this is something we already use it: standards track WH: 2 discussions: - many small devices, - do we have a problem that needs to be solved? Yes What should the goal be? Standards track, as experimental WH: I believe having modularity is a good think, no reason to be afraid. BL: different use cases: - old devices, no locking, - customers who like TLS might not wnt SSH mandatory BW: A poll shows some preference to have this standards track. Standards track 8 hands, Experimental 4 hands * YANG Module for Notifications AB presents his slides. AB: Extending standard notifications is done in practice. Already has propietary moduls for this. MB: YANG version of the streams would be needed and would become available for augmentation. AB: control for filtering on the input side of buffer, users don't use notification not good enough, I would. AB: Should we do this or leave RFC 5277 alone? JS: Are the problems users report fixable by revising RFC 5277 or are the problems so severe that we would end up creating a very different replacement for RFC 5277? AB: yang version of the content. revise later possible BL: We have experience that starting the notification delivery session from the manager side is causing us problems. about buffers, use multiple streams. customers, users hate starting multiple sessions from mgr. BW: Who is in favor of just yangifying RFC 5277? Who is in favor of also fixing other issues with RFC 5277? Show hands: Bis for now: 1 hand, Yangify: 1 hand JS: If we do it do a bis document MB: I prefer to do RFC 5277bis but it is not clear we have to do this now. AB: I am currently looking at sending notifications over SYSLOG. Being able to augment RFC 5277 definitions is not of high priority. BW: one option is to wait for more input and individual drafts MB: depends on the amount of work AB: I will go for syslog, as call-home is unworkable, to many sessions BW: we will not take this as a work * NETCONF over BEEP / NETCONF over SOAP to historic BW explains the situation. We agreed in Paris and the list. Bert has a small draft, lets make it a WG doc. BW: A poll leads to consensus in the room to accept this as a work item. Show hands: pro: 12 hands, against: zero * Operational State JS explains that operational state is a problem that needs a solution, a lack of proper protocol support has impact on the data modeling work in NETMOD. get operation gets both state and config, we would need an operation to give back ONLY operational data. BW: this would be a new rpc as a capability MB: agrees with the problem but the solution is unclear, possibly one new operation. KW: could be part of 1.2 MB: we don't open up base at the moment BW: This would be a capability. BW: Concensus: investigate the problem, but unsure about the solution and the workgroup add to the charter. Unsure about advancing the documents. BW: Describing the issue and a problem statement with an individual I-D would be good. * Implementation report BW: People in the room were in favor of doing the implementation and deployment report work needed to potentially advance RFC 6241 (does not imply we will do the advancement). Show hands: 8 persons are in favor, none opposed * Advancing Netconf standards AB: It is good to signal to the rest of the IETF by advancing the specification on the standards track is a good thing. AB: advance the documents. to state that we want yang modules, it is a statement towards the IETF BC: wait for the report Show hands: 7 in favor, none opposed BW: no one voted against advancing BW: People in the room were in favor of advancing the base specification on the standards track. BW: We will add this as a charter item to advance the RFC 6241 and 6242. * Charter Discussion The chairs will revise the charter proposal based on the outcome of the discussions DR: The sentence concerning COMAN should probably be removed. BC: We can not be sure that we are solving a problem in COMAN. DR: Take out Coman from charter, it doesnt effect our work anyway LL: This is not just about constrainned devices, its also about making netconf modular. Question whether people are in favor of the charter in concept as presented: 12 in favor, none opposed BW: There was agreement with the general direction, the chairs will followup with a revised charter text proposal on the mailing list. * NETCONF over WebSocket TI presents his slides. ME: Should this document be experimental or standards track? ME: Could this be run as an AD sponsored submission? DR: Speaking as a former AD, why not run this via the working group since this is where the experts are? BC: If the WG is not interested in this document (have not read the draft yet), why should I be interested in sponsoring this document? Bert: This might go against the REST API. We only have one implementation. We dont have many comments. We dont necessariliy want to spend cycles on it. ME: who will implement this? No hands shown. BW: Not much discussion on the mailing list, not clear how this relates to the YANG API work. KW: I am not sure what the real motivation for this work is. BW: Unless a significant number of people speak up in favor of this work on the list, we might not entertain this in the working group. Show hands: 2 in favor, 2 opposed, 3 abstains. BW: No interest seen, the WG has no consensus to do it, but if you do it as AD sponsored OK, we wont block it. * YANG-API AB presents his slides. BW: what do you want AB: for now, just want to start a discussion BW: avoid dont duplicate on two mailing lists AB: people are doing proprietay solutions BW: No time left for discussion, however we need to decide whether this is NETCONF or NETMOD work. No time left to discuss YANG conformance issues.