Minutes of the Netconf WG Ssssion in IETF 93 [2015-07-23 Thu] ============================================================= Note takers: Radec Krejci & Mike Leske ME - Mehmed Ersue MJ - Mahesh Jethanandani KW - Ken Watsen JS - Juergen Schoenwalder JH - Jeffrey Haas LL - Lada lhotka AB - Andy Bierman BL - Balazs Lengyel EV - Eric Voit BC - Benoit Claise SH - Susan Hares AA - Alia Atlas BS - Barbara Stark Chartered items: 1. WGLC Status: NETCONF Call Home - K. Watsen (5 min.) http://tools.ietf.org/html/draft-ietf-netconf-call-home No comment 2. NETCONF Server Configuration Model - K. Watsen (15 min.) http://tools.ietf.org/html/draft-ietf-netconf-server-model Issue #53: Request for "listen" container discussion postponed to list, no comment in room Issue #49: Combine trusted-ca-certs and trusted-client-certs for SSH/TLS 4 options presented slide 8 ME: how much time the work would take? KW: a year ME: then I'm against, it will delay this draft Chair rejects possible document delay for 1 year due to usage of keychain model JS: keychain is a needed work KW: JH: such a model could be reusable also in other RFCs, don't make RFC authors to reinvent the wheel but probably the proper place is another WG in security area, results can be used anywhere Jeff refers to RFC7210; recommends not re-inventing but coordinating works, work should be taken to security area Juergen agrees with Jeff: Home to be in Sec area Chair request feedback for 3 or 4: no comment ME: anyone for solution 2 or 3? (No) JH: is it possible to augment with security stuff 2 or 3 later? Jeff: Questions how augmentation can help KW: I'm not sure it is possible, with solution 4 it is possible Presenter: option 2 and 3 may not support augmentation Jeff: refers to work done for BFD model ME: Which group in security area? JH: KARP, recommendation to start with Sec Open area LL: it would be possible to get this part out of the model and prepare some interim solution and then push it to security area LL: Requests factoring area sec area from the draft and leave work to SEC ME: Kent, can you prepare some initial proposal Chair: Requests Ken to drive sorting out next steps and work split with SEC KW: it is already available as appendix to this draft ME: ok, but in this case we are not able to proceed to LC now 3. RESTCONF & Co. - A. Bierman (20 min.) RESTCONF Protocol http://tools.ietf.org/html/draft-ietf-netconf-restconf slide 3 - (#17) no objections on proposed solution slide 4 - (#18) KW: i don't like MAY in last sentence, it should be MUST AB: we wanted to keep filter working also in anyxml, what about SHOULD? KW: we should work with anyxml as it is a blob LL: what does mean "treat"? is XPATH the reason? AB: the situation is more theoretical LL: I feel that we loses time on minority things AB: I believe that even these odd things should be specified to make them clear JS: YANG 1.1 is not interoperable with anyxml AB: lets decide in mailing list slide 5 - #19 AB: I'll open this in list ME: lets do it here, who is for and who is against? Chair: Voting for solution on slide vs. Juergen's comment on interoperability result: 0 vs 2 KW: against, I would handle it as blob JS: leave it implementation specific, anyxml content is not interoperable LL: I agree with JS Issue #18 and #19 decision: Juergens counterproposal: "Usage of anyxml may lead to inconsistent behavior." Lada agrees AB: it is needed to distinct between schema and instance data trees anyxml is like leaf, is it ok? LL: yes, from the YANG point of view, from the implementation point of view lets allow them to do whatever they want including doing nothing and cutting it off so, implementation specific? AB: ok slide 6 #24 ME: lets separate these issue to the mailing list, consensus was to use XML Mehmet recommends discussion on list, "XML consensus still valid" LL: there was actually no consensus, it doesn't make sense to postpone it to the mailing list if the decision mechanism will be the same ME: closing line, time issue here slide 8 ME: we don't have to wait with LC for publishing Y1.1 ME: Last Call should not wait for public YANG 1.1 to not further delay draft Andy disagrees AB: yes, probably, but WG said we should wait for Y1.1 ME: yes, but we don't have to wait for publication, but finishing changes in 1.1 ME: JS, is it possible to use it, is it stable? JS: I miss anydata here, but I don't see a problem with processing it, technical things are solved in 1.1 JS: Issue #25 needs to cover anydata. Technical discussions closed for YANG 1.1 LL: there is also dependency on JSON encoding work Lada:Document should wait for YANG 1.1, but new features should already be included in this draft Chair/Andy: Agreement to change some text and go to last call. YANG Patch Media Type http://tools.ietf.org/html/draft-ietf-netconf-yang-patch Issue #2: Juergen: Document needs to be clear on unified storage (??) slide 3 #3 AB: any objections? JS: document should say how the NETCONF + RESTCONF implementation works when it is together AB: NETCONF is silent about this YANG Module Library http://tools.ietf.org/wg/netconf/draft-ietf-netconf-yang-library/ slide 4 #4 ME: anybody objects? JS: me and probably also MB are against, yang-library should tell which schema revision was selected JS: Not in agreement on proposed solution for #4 AB: it make sense to import without revision only when it is absolutely clear which version is selected, if the revision is explicitly needed for client, it is wrong already in YANG BL (Jabber): I want this information Discussion to be continued on the list RESTCONF Collection Resource http://tools.ietf.org/wg/netconf/draft-ietf-netconf-restconf-collection/ 4. Zero Touch Provisioning for NETCONF Call Home (ZeroTouch) - K. Watsen (15 min.) http://tools.ietf.org/html/draft-ietf-netconf-zerotouch slide9: ME: are ANIMA people here? (NO) Timeplan for ANIMA bootstrapping design team? ME: another step is needed to make cooperation between ANIMA and NETCONF working ??(ANIMA): presentation was on Monday, another will be this afternoon, you are invited no comment Non-Chartered items: 1. Meeting i2rs requirements using Subscribing to datastore push updates - A. Clemm (15 min.) https://tools.ietf.org/html/draft-clemm-netconf-yang-push 4: ME: from which source you've get info EV: there are many different docs ME: are those req. official EV: not officially provided, but will be official to publish in this document 14 JH: just observation, ??? EV: agree KW: what about different transport protocols besides NETCONF, what do you think? EV: HTTP2 ... ? MJ: is the use case part of the requirements? EV: it's another WG text, not mine ME: are these not yet targeted requirements or what kind is it? EV: ME: any comment to questions on last slide? JS: just a note or warning, don't overdo the number of features in the first version EV: yes, we don't want to scare people, it is split ME: last time there were huge support for this, I expect the same now ME: no one objects against adopting this as WG item, huge support Majority for adopting the document as WG item ME: we want to do it faster, but before adopting we want LC for RESTCONF AA: this is a key document for i2rs, we are waiting for this and we really need it, the signal of support is needed in community, so please adopt it, and say it on public AA: Stressed importance of adoption. People are waiting for i2rs implementations BC: I understand you want to finish open work, but you are playing ping-pong with i2rs, I feel frustration from different people, it should have more demand BC: Noticed frustration by WG waiting for each other. Suggests moving on with the draft. BS: I'm currently leading a project on an activity in BBF to figure out the evolution of TR-069 and CPE management. Restconf is on the table for consideration as a possible part of this evolution. But in managing CPE, "PubSub" type capability is critical. In considering IETF work, I only expect working group drafts to be considered, and not individual drafts. LL: I believe it can be done in parallel ME: ok, we will adopt it immediately JH: Persistency of config to be considered No topic from "worthy discussion list" found immediate attention -> list AD's recommend to start as WG item 2. Report from ANIMA design team - Verbal report (5 min.) -- ANIMA design team: meant to define bootstrap process for autonomic networks and hopefully others Ken will join afternoon session of ANIMA 3. I2RS requirements on NETCONF - tbd. (40 min.) slide 3 JH: MJ: LL: there is a gap in requirement document, it should describe what is exactly happening with different types of data in NETCONF/RESTCONF/i2rs Q about params in NETCONF part, is it possible to change it in ephemeral way, or NETCONF startup takes some role, or is it overlaid by ephemeral version JH: we are saying what we want to happen, but we are not NETCONF experts, your Q has several possible answers/implementations, we would like overlay approach but we don't insist on it AA: it must be said somewhere how it interact and work together, but in this we need a help from NETCONF experts JH: recommends to defer discussion on ephemeral state JH: Requirements are descriptive , not prescriptive. Overlay useful as an option AA: Asks the NETCONF community to decide best decision to handle input config and ephemeral state SH: e.g. BGP YANG model, BGP RIP (?) in - we have a specific use case of ephemeral, but we don't want to lose whole solution for a small thing JS: what does mean the "non-ephemeral state"? JS: requests clearance on "non-ephemeral state" in requirements documents KW: -> intended config (Comments part on slides) JH: can you specify it more? MJ: consumer will want both ephemeral and config, so there is union between them, sometime it could be useful to have them separate, but very often an app will need both types at once (complain about implementing using separate datastore) JH: There can be a union between ephemeral and persistent config and app should be able to retrieve it JH: existing Netconf GET read should allow this MJ: JH: it is too specific, more about implementation ME: solution should be discussed later Ephemeral config JH: where this come from MJ: mailing list? JH: this is not i2rs requirement JH: "Session close" slide, does not believe requirement came form I2RS Identity req. JH: second identity is for traceability JH: 2nd identity for traceability, not expected to persist, identity needs to persist JH: identity is for maintaining internal state, metadata are suggestions, ... we provide only recommendations and suggestions Jeff: identity necessary to maintain internal state, metadata implementation suggestion (no requirement) to find out identity of a given node read-only comment is a suggestion, implementation up to the group Priorities 1) JH: separate requirements JH: multi-headed control is separate from ephemeral, but have implication upon each other AA: priorities was the most simple thing we came with, giving as example dynamic LSP ...??? we are providing requirements separately, but they are related together AA: priority simplest mechanism to handle multi-headed control 2) JH: clients have priorities, it is connected with users db, that's reason for connection with NACM JH: (could not follow reply on NACM)