Notes of the NETCONF session at IETF #90 Agenda, Note well, status of chartered WG items See http://www.ietf.org/proceedings/90/slides/slides-90-netconf-9.pdf Reverse Secure Shell (Reverse SSH) - K. Watsen (15 min.) http://tools.ietf.org/html/draft-ietf-netconf-reverse-ssh http://www.ietf.org/proceedings/90/slides/slides-90-netconf-0.pptx - three drafts with changes since IETF89 – 04, 05, 06 slide 6: Juergen Schoenwaelder (JS) – how does the identity thing work and interoperate? Kent Watsen (KW): The draft doesn't req X.509, if you use it, you will be able to extract that info from it, will clarify text Discussion on asymmetric document structure: Bert Wijnen (BW, as contributor): would that mean that 6242 does not change? No. 5539 will still to be updated for call home, but easier adaptation Humm: strong hum in favor, none against or abstain. WG members agree with the proposal to have a single call-home draft. NETCONF Over TLS update - RFC 5539bis - J. Schoenwaelder (10 min.) http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis http://www.ietf.org/proceedings/90/slides/slides-90-netconf-10.pdf - implementation led to a number of issues – proposed resolutions accepted with exceptions slide 5 client side configuration of call-home – unclear consensus - What to do? KW: we don't define models for clients, so my answer is no. Andy Bierman (AB): Big change because clients would be required to be servers as well, needs clients config => NO 3. NETCONF Server Configuration Model - K. Watsen (15 min.) http://tools.ietf.org/html/draft-ietf-netconf-server http://www.ietf.org/proceedings/90/slides/slides-90-netconf-2.pptx open issues (slide 8) Issue 1: replace with single list, Martin Bjφrklund (MB) agrees Issue 2: remove key – keep the recommendation – JS suggest to have a different key, cannot have ‘no key’. JS: You can't have no key. Balasz Lengyel (BL): with address problems with multiple servers, agree with proposed solution Issue 3: replace w/application – no comments Issue 4: use fingerprint instead? Or use instance-identifier? Or embed in config capabilities (in Netconf server model) Issue 5: add ability to config host key? JS: The hostkey is sensitive, has to be protected. We shouldn't replicate the key, should use hash instead of key replicas. SSH properties should be configured in SSH model. KW: But in call home you launch new SSH process. Action item – Kent will bring #4 and #5 to the list JS: This is only one implementation option. BW: Action on Kent, go to mailing list. Issue 6: how to configure keep-alive? MB: done by NMS, still needed? MB: You said keep alives should be initiated by the one who started connection, so it's not needed in call home. KW: because of symmetry. Agree, it's not important. BL: many times no notification server, how are they sent? How does the server do keepalives? KW: This is done in-band, doesn't need notifications. KW: Tom isn't here, let's take it to list. AB: What does Tom say? KW: That we should do both. Issue 7: JS: will also be valid for RESTCONF? Will make the change MB: Wouldn't this config be useful for RESTCONF? If so, it should be in system. KW: This raises another issue - call home in RESTCONF? RESTCONF Protocol - A. Bierman (15 min.) http://tools.ietf.org/html/draft-ietf-netconf-restconf seehttp://www.ietf.org/proceedings/90/slides/slides-90-netconf-3.pdf Open issues: Issue 1: Select parameter – mandatory to implement? MB: if optional how would the client know it’s implemented? Mailing list slide 4 KW: People perceive RESTCONF as Lite, basically everything should be optional. AB: In CoAP environment this is necessary, we need levels of capabilities. MB: If it's optional, how would the client know? AB: I will talk about capabability advertisements. We have to have some way. BM: select is just hint, the server may send more. AB: I will take it to the mailing list. Issue 2: Netconf-state monitoring support – all implementation ignore what the RFC says – ‘managed by the NETCONF’ meant to support all protocols, not only NETCONF – all sessions managed by RESTCONF can be in this table. slide 6 MB: likes the idea, but do we need 6022bis? Can do errata – AB: to send errata text to mail list. AB: We can (mis)use the unclear text - NETCONF server is not the same as NETCONF session. JS: What's the proposal? MB: We should re-use the leaf identifying the protocol. BW: Proposal has to be clarified. Issue 3: Secure transport – leave for later Issue 4: slide 8 KW: Should syntax for key values be changed? Use brackets as in XPath. AB: This consumes in one character in the URL, not two. JS: XPath expressions don't work in URLs because of the restricted character set. slide 9 KW: Should be optional. Ladislav Lhotka: Do all RESTCONF messages actually satisfy that I-JSON restriction that their contents must be JSON object or array? AB: They are always objects. Get-bulk query parameter – mandatory or optional? Lada – object or array sent? AB: object. KW: should be optional. -> to the maillist. Issue 5: Defaults-handling – JS: was defaults mandated? Confused? MB: useful for the client to know the defaults. Resolution – optional slide 10 JS: At some time RESTCONF was mandating specific handling of defaults. AB: We have the issue in NETCONF as well, we force the server to add nodes that are not not there. MB: It's useful for the client to know what the server supports. It should be optional. Issue 6: Protocol capability URIs? – yes slide 11 Consensus: advertisement of capabilities is needed. Issue 7: Target resource list keys required for GET – yes – change text slide 12 Resolution: allow GET to obtain all instances. YANG Patch Media Type - A. Bierman (10 min.) http://tools.ietf.org/html/draft-ietf-netconf-yang-patch seehttp://www.ietf.org/proceedings/90/slides/slides-90-netconf-4.pdf slide 4 Should YANG Patch be mandatory? – wat to go – do not make mandatory, add text with what will go wrong if not done. Lada – optional because of constrained environments Lada Lhotka (LL): YANG Patch should be optional because constrained platforms may not need its power - JSON Patch can suffice. Zero Touch Provisioning for NETCONF Call Home (ZeroTouch) - K. Watsen (20 min.) http://tools.ietf.org/html/draft-ietf-netconf-zerotouch seehttp://www.ietf.org/proceedings/90/slides/slides-90-netconf-5.pptx slide 11 AB: This creates a top-level mandatory node, it should be presence container. KW: This is the *configlet*, not configuration. Non-Chartered items: I2RS Requirements on NETCONF - Jeff Haas (10min.) See http://www.ietf.org/proceedings/90/slides/slides-90-netconf-8.pptx slide 1 AB: – what do you mean by full commit? When is the enforcement done? Jeff Haas (JH): full validation; AB: – done every edit? Jeff: yes; JH: Every edit. AB: – very slow. Jeff – not require many changes MB: What does EE mean? JH: Atomicity is required. MB: You probably don't need anything from NETCONF. The "full commit" has no meaning for state data. Bert – Dean Bogdanovi? (jabber) prefers RESTCONF rather than NETCONF with I2RS, which is per device BL: Do you mean a real datastore? Or just patches? JH: Open question. BL: if patches, new concept Mehmet Ersue(ME): What can we do for ensuring effective exchange of information between I2RS and NETCONF WG? Jeff – can write I-D, one I-D for reqs from NETMOD, NETCONF in different chapters ME: One I-D would be sufficient. JS: – timing? Jeff – before next IETF, maybe in a couple of weeks, as data store defined A NETCONF Extension for Data Fragmentation - G. Zheng (10 min.) http://tools.ietf.org/html/draft-liu-netconf-fragmentation seehttp://www.ietf.org/proceedings/90/slides/slides-90-netconf-6.ppt slide 7 KW: There was a draft to introduce pagination in RESTCONF that could be used in NETCONF. It is done similarly in NETCONF (your 3rd proposal). We might have issue in RESTCONF because we can iterate over outer list but not over inner list. AB: RPC reply needs to be a valid XML document, so arbitrary cutting the response would not work. Reply should be well-formed, and also valid. Client needs to know how to do the reassembly. MB: I think the draft addresses a real problem, we need to limit the depth, it is needed in NETCONF. Bert (as chair) – do we agree this is a problem? Hum – none. AB: – nice to have. Martin – it is a problem. Re-hum – now people think it’s something to talk about in the WG BW: We have lot of work items, AD might not accept new ones. We have to finish chartered items first. Benoit – you can work in the meantime ME interest of the WG noted, we need to rediscuss once WG items are completed. Multi-Instances Configuration Issue in NETCONF - G. Yan (10 min.) http://tools.ietf.org/html/draft-liu-netconf-multi-instances seehttp://www.ietf.org/proceedings/90/slides/slides-90-netconf-7.pptx slide 5 LL: This example isn't valid because routing-protocol is already a list and can thus accommodate multiple instances. In general, the problem arises only if multiple instances are not anticipated - the data model has a container where a list is needed. I think though the proposed solution is too simplistic: it may not be possible to encode the context in XML attributes. BW: not clear what we need to do in Netconf? Seems to do with data modelling. Gang Yan (GY): maybe separate drafts in Netconf and Netmod MB: It is a big difference if you use it in the data model or in the protocol. This is a different solution for the data model. Derek Man-Kit Yeung: You can make the model work for both one and multiple instances. put in different instances and allow for leaf instances to be a union JH: IN SNMP, multiple instances was a horrible hack. Push back on actual models. JS: Supports JH. KW supports the work BW: do we see this as a problem? In I2RS looks at some of these issues – Gang may look at the work in I2RS AB: phrase multiple agents is incorrect, different architecture than multiple instances of a table