Minutes of the NETCONF Virtual Meeting on October 20, 2014 Attendees: JS = Juergen Schoenwaelder MB = Martin Bjorklund AB = Andy Bierman ME = Mehmet Ersue MJ = Mahesh Jethanandani LL = Lada Lhotka AL = Alan Luchuk JT = JF Tremblay KW = Kent Watsen AI = Action Item Agenda of the virtual interim meeting on October 20, 2014 1700-1900 UTC ----------------------------------------------------------------------- - 5 min chair intro - recording the meeting?, scribe, agenda bashing The tool Etherpad has been used for notetaking. - 10 min rfc5539bis and X.509 certificate authentication (Juergen) JS: certificate based auth is already there. We should remain consistent with the usage in SNMP. AI: JS to ask Tom Petch what he is missing. MB: Consistent set of document is probably what Tom is missing. Server model can be updated to state that these are now consistent. KW: 5539bis should be self-standing without normative reference to server model draft. AI: Mehmet will ask Kent to update. - 45 min restconf open issues (Andy) See https://github.com/netconf-wg/restconf/issues RESTCONF #3: add collection resource https://github.com/netconf-wg/restconf/issues/3 http://www.ietf.org/mail-archive/web/netconf/current/msg09365.html Conclusion in Github: The original plan to add a basic collection resource will be done in the next release (if possible). Only basic pagination (offset + limit) will be supported. Future work may extend the basic features. AI: Martin will attempt to add a basic collection resource in time for IETF #91 RESTCONF #12: target resource list or leaf-list keys required for GET https://github.com/netconf-wg/restconf/issues/12 Not on the tracker yet: - ietf-yang-library.yang in RESTCONF-02: Should this be in a separate RFC? JS: One way of discovering models for Restconf and Netconf. Where this is defined is 2nd prio - ietf-restconf-monitoring.yang in RESTCONF-02: Is this complete for release 1? MB: Why don't we introduce an ID for Restconf? Will there be different streams for rest- and netconf? It'll be the same stream. AB: We need an agreement on what it means they are colocated. One more issue concerning add collection resource To be returned (currently) when doing a GET on a URL that points to the list, w/o any keys. Should support offset / limit query parameters. LL: invalidity of the reply any concern for JSON. Conclusion in Github: This issue is related to #13, which has been opened now. The basic collection resource support should resolve this issue Conclusion for issue #13: The ietf-yang-library contains YANG module information that may be applicable to NETCONF or other protocols that use YANG modules. Should this module be in a separate RFC? Current consensus is no, leave it in RESTCONF RFC. - 35 min netconf-server model open issues (Kent) see: https://github.com/netconf-wg/server-model/issues Issue #4: How to configure NETCONF server's SSH host-keys or TLS certificates Conclusion in Github: There was consensus for the proposal to add top-level "netconf-server/ssh" and "netconf-server/tls" containers to, in part, list out the (config false) system's SSH host-keys and TLS certificates. This so that these keys can then be referenced by both the listen and call-home configurations. Additionally, Kent explained that configuring said keys has turned out to be more difficult than first thought, due to the wide array of algorithms and key-generation/signing strategies involved. Perhaps RFC 7210 (mentioned by Mahesh above) should be looked at. Issue #8: what other server config knobs are needed? Conlusion: AI for MB to provide parameters their server supports. Then KW will try to find the common parameters between the three servers. Issue #13: enable indirect Issuer authentications? Conclusion: There was general consensus that this was the way to go. AI: Take to the maillist. Issue #15: Should the "listen" and "call-home" lists have parent containers? Turns out that there is no best-practice around use of parent containers for lists. There wasn't even consensus that a single module need be self-consistent. In the end, it was decided that it was purely a modeler's discretion and that this is essentially a non-issue. AI: Take to the maillist. - 20 min netconf-call-home open issues (Kent) https://github.com/netconf-wg/call-home/issues Issue #3: Extend to support RESTCONF as well? KW explained that the config model for NETCONF call-home using TLS was essentially identical to what would be needed for RESTCONF call-home using TLS (HTTPS). And further that the concern for HTTP sessions was unwarranted if RESTCONF requires HTTP/1.1 (which defaults to persistent connections) and recommends setting http server timeouts to something reasonable like 5 minutes. MB questioned if the need for call-home existed. That is, if RESTCONF is used primarily for off-box applications/controllers - do they need to call home too? Kent agreed that applications/controllers would likely not need to call-home, but that we should't dismiss RESTCONF being deployed instead of NETCONF on a NE, in which case RESTCONF call home would be important. The discussion went further into why RESTCONF wasn't deemed suitable for production, to which it landed on not having a confirmed-commit equivalent. Martin said that he tried once, but couldn't find a simple solution. Kent and Martin to sync up offline. Conclusion: MB and KW agreed that, if we do support RESTCONF call-home (or even not), it would be best for draft-ietf-netconf-server-model to have another top-level module (e.g., ietf-restconf-server) that shared groupings with the existing ietf-netconf-server module. Issue #4: Have a call-home port? KW explained that with RESTCONF call home, the number of ports requested from IANA would then be three, which ratchets up the potential need to define a single port. And that since now we have a single call-home draft for all transports, it would be much simpler to do than before. AI: KW to provide a proposal and ask the maillist for feedback. - 5 min AOB other topics The next virtual interim meeting on November 3, 2014 just before IETF #91 meeting has been canceled.