*** NETCONF meeting [2013-11-04 Mon] **** NETCONF over TLS (Jürgen) http://www.ietf.org/proceedings/88/slides/slides-88-netconf-0.pdf ***** slide 3 Kent: it could be a deployment specific-port, so it needn't be registered, it also has no impact on zerootuch configuration. Kent: Maybe option without a new port. The device is already configured with address/FQDN address, why not configure a port as well? Martin B: That works. But this is not the same service as Netconf. Separate port needed Mikael Abrahamsson: quickest way to have port included in the draft and leave it to other WG to decide MAbrmson: Should be discussed in TLS/SSH WGs. Wants this quickly include port, if thats not good go to other WG. Mehmet: We are not changing TLS, so it needs be discussed here Andy: agree w Mikael, it's not an operator's choice but rather the vendor's Andy: We are not TLS experts. Are there any standard protocols without a port assignment. Port will be a vendor choice, not an operator choice. I dont see a point not to chose a port Juergen: NETCONF protocol starts only after all auth etc. is done, and cannot change anything. Juergen: Netconf can not establish the port. Mehmet: To have a secure solution Lisa Huang: agree w Andy Lisa Huang: Should be vendor Diego Lopez: Is there a way for discovery announcement? You have to start a different transport mechanism - is it discovery or negotiation? ??: PCP inside TLS similar situation. You don't need a fix port if you have this in a directory mechanism. If you don’t have that fix port is good. Benoit: support allocation; as A-D: we should discuss it with Joe Touch. Benoit: cleaner to have a port. This is callhome only for Netconf, not a generic. Is Joe a contributor or expert reviewer We should discuss with Joe, but I believe have a new port Mehmet: mailing list wanted new port, as this is just for Netconf Question: who wants new port: yes ca. 30, 0 against Sense of the room: allocate a new port ***** slide 4 Kent: in Reverse Ssh it's a list of applications that comes first, within each there is a list of servers, reconnect strategy, sticky connection Strategy, always first server, or always last connected server Mikael: Is it implicitly TCP? Jürgen: Yes. Mikael: So it should be mentioned. michael: put in transport, as later sctp, etc. migh come Martin: Did you consider unifying the data model with rev ssh? This would be useful. Martin B: did you consider same structre, but also use the exact same list. Why have it separately Jürgen: We could actually extract it out and make call home independent of transport. Jurgen: there could be differences, having a common module would need to split it out into a separate draft. Do we want to do it? Kent: It would be nice to have just one document: call home Jürgen: That would actually be much easier for readers. Jurgen: transport specific separate documents is a good idea Andy: agree with Martin, similar objects, no need for separate modules, special objects can be augmented. Andy: use groupins to avoid copy paste. Separate documents with references enough. Put the stuff into the netconf tree Mehmet: separate documents or one doc with the module? Mehmet: Yang module in separate document better then dependencies Martin: support 2 docs for TLS and SSH, extra doc for the module. Martin: YANG module in separate document ***** slide 5 Kent: reminds me of conditional enablement kent: enable button. this follows the conditional enabblement draft Martin: there is already "enable" button in rev ssh? Martin: agree with kent, enable is needed all over the space Mrtin: prefers conditional enablement, but accepts button kent: is it too late for conditional enablement, thinks no Jürgen: I'd like to have it done rather than wait on a new doc. Jurgen: timing issue, doesnt want to wait Jurgen: Reconnect is it OK Martin: same reconnect strategy - it could be simple but extensible. Kent: we have round-robin strategy, assumes persistent connection strategy. Kent: what we need to configure - NMS public key, NMS has to authenticate the server first. Provisioning server is one set of credentials, the other server may need another set of credentials. kent: this is what we use at juniper, operational experince says this is OK. details on reconnect strategy Martin: strategies need a better explanation Jurgen: What to configre Kent: SSH public key is configure per application per server Michael: yes key needs configured. Strict checking of server needed. Hostkey might be communicated out-of-band. it could be multiple certs on the device, this needs to be extensible. This is complex. I could help Kent: for SSH, after you get past tunnel establishment, it's username and pw, it could also be hash password, or public key can be used. Kent: standard TLS crypto setup. For SSH authentication credentials: public key RSA X.509, hashed password, etc. **** Reverse SSH (Kent) http://www.ietf.org/proceedings/88/slides/slides-88-netconf-1.pptx ***** slide 9 Mehmet: pay attention to the IPR statement Mehmet: IPR seems to use standard licensing terms. Andy: one issue - does it cover entire spec or only portions? Andy: is the RAND o ly valid for the mandatory perts or does it cover the entire spec. Kent: entire spec, AFAIK Kent: Juniper document does not differentiate between mandatory and optional parts. Dan R. You should ask your legal department Wes Hardaker: What is actually covered by the patent? Dan R. Dont discuss patents in IETF meetings Kent: patent cover reserve SSH. Cleartext messae sent about identity, covered by HMAC. It is for reserve SSH, but not exactly this solution Patent number is in IPR. K: TCP connection is established, then a cleartext exchange takes place. David Lamparter: it must cover the whole thing. ???: IPR text mentions "what is needed for spec"... Martin: is this really applicable Kent: believe yes, read IPR Dan R. Should not discuss content of patents here. Read patent. Disclosure happened. Karl Moberg: Would Juniper revoke the patent if needed? Kent never heard about such thing Kent: we have implementation. It goes through opensource and legal review, hopes to post it under apache license for reading or reusing. Mehmet: next steps? Kent: some clarifications, then work with Juergen on a common YANG module Kent: One comment plus extracting the common YANG module. **** Zerotouch Provisioning (Kent) http://www.ietf.org/proceedings/88/slides/slides-88-netconf-1.pptx ***** slide 8 Andy: access control list needed. you want to block malicios attempts. kent: we want to support the usecase where the connection comes from outside Andy: in order to block normal netconf requests while allowing call home, we need a separate port Andy: this is why I asked about access control list, the service provider may not want to have that traffic Kent: agree Diego: Certificate can be an option, but not the only option. ??: checking that the device authorized. Is this the only way to authorizing the device Kent: Any unique identifier will work, serial numbers are ubiquitous. Kent: identity we recomend erial number, but any universal unique ID would work, but serial number is intuitive Diego: I am just questioning the precondition of security chip. ??: I am just asking if other mechanisms could also be used. This is one possibility Kent: Devices may be allowed to use another identifier. Kent: the choice of identifier=serialno is vendor specific as long as NMS agrees. But Others could be used. I will still recomend serialno. ***** slide 9 Kent: ipersonate DNS is sketc Russ Mundy: private DNSSEC will work. ??: role over time is not specified any spec. It should work Michael: Private net will not have the public signing keys. So you need to provide the other keys. Do we need all this in one dratf? This is a big topic. If the device is on the shelf too long, DNSsec keys may role over Michael: Should this be one draft or multiple drafts? We have different mechanisms. Kent: In OPS there was another draft outlining the diff solutions. We'd like to have a universal solution. Kent: opsarea there was a draft to outline many solution, but people did not realize why it was good? Here we are going for a specific solution. Michael Behringer: What's the name of the ops draft? Kent: Don't remember, will send to the list. Jurgen: I will send it to the mailing list Rüdiger Volk: proposing DT(?) cards Ian Farrel: [ missed his point ] ??: Why do you want to put tyour credentials into the device? Why not just plugin? Offers flexibility, same ease of use, better security, as Kent: fair question. Flash drive or near field radio may be used. We could use an HTTP server. ??: problem that this depend of vendor. Vendors might collapse, they effectively control the operator network to some degree Martin: does not have to be the vendor, any 3rd party can be Martin: DNSSEC - it needn't be the vendor who provides DNSSEC Kent: the server can be someone else, but the vendor manufactures the needed parts Wes: even if the vendor dies, the device is usable, just no zero conf works Mehmet: what's being proposed - adopt or clarify open issues first? Kent: Joe Clarke, plus comments here should be included. But we want to check interest Mikael: support the problem description, even willing to work on this. Dan: Do you mean an alternative proposal? Michael: yes, we are willing to provide an DHCP approach. I am not against it. Mikael: Yes, have an alternative solution via DHCP. Kent: We did DHCP, too, but found it insufficient. Kent: we also have a DHCP approach, but as it does not work in some cases we went for this Martin: Both solutions are complementary. Kent: DHCP is an laternative even in this document, but I fear this opens up an attack possibilities Mehmet: Go to mailing list, there is interest. **** RESTCONF (Andy) http://www.ietf.org/proceedings/88/slides/slides-88-netconf-3.pdf ***** slide 14 Carl: You define all sorts of new things on 75 pages, some features are arguably not RESTful, so I can't see the purported benefit of reusing existing technologies. KarlM: Restconf is already 75 pages over http/libcurl. Andy: this is what rest is missing. schema language KarlM: do you want to fix it here? Andy: This is a specific solution for YANG and Rest combination. Customers like it. KarlM: Libcl or JSON tools dont understand YANG Andy: its OK. libcrl does not need that KarlM. Lacking precise definition of what we try to do Andy: dont agree. provide rest access to YANG server KarlM with a lot of extensions Andy not many stuff KarlM: this is not that easy. 75 pages to learn. Andy: You can use simple patch instead of yangpatch Needs cross area review DanR: Why here? Why in this WG? This will slow down netconf adaptation. This is a different protocol. You have a lot of experrtise, but a lot of resstance Andy: has been DanR: Wny not new WG Andy Area directors/WG chairs sad do it here, to have this aligned Unified management means one model not one protocol. Naming and semantics should be the same. protocols will always be different. YANG is the key. Maybe it should be in the same WG DanR: another WG would be better Mehmet: History: a new WG and a BOF was proposed. It is different from Netconf, but based on Netconf. Keep them aligned. Second option for Netconf. Dan: Does this work belong to this WG or another? Lada: It is actually valuable to combine REST concepts with the YANG model schema. But in order to make the RESTCONF document shorter, the definition of Yang Patch should be in a separate document. Lhotka: I like it. YANG as a base is good. Andy: Without YANG modules, management does nto work. Vendors are doing fancy stuff with YANG already. Lhotka: Maybe we can use JSON patch Andy: JSON patch not schema based Jan Medved: Support it, we implemented in OpenDaylight. We need it, we have done it anyway, so we are have to have it, many proprietary solutions will appear otherwise. Scott Bright: agree with this. One data model is not realistic. Scott Whyte: there is no single schema, vendors have their extensions. Andy: I don’t mean one yang model, everyone defines it. One per device, augmented standard. Naming is a problem. that's why we have the augment statement, one model means one model per server, consisting of multiple YANG modules. Scott: different formats. Andy: same data on cli, netconf, webui, restconf. Any protocol changes the same Lianshu Zheng (?): support chinese ??: we are implementing this. We like it. Andy: people dont want to use netconf for notificatios as it keeps the connections up, as restconf. Kent: Juniper supports this and implements this. mehmet closes the line Do you want this adopted Andy: I want this adopted. I want to see the consensus. Who wants this in Netconf WG aligned: 25 No one against Mehmet: I see a lot of interest. People want it to do in the Netconf WG. Benoit, will you support it in the charter? Benoit: alignment is important, new charter needed. Opendaylight requires it that is important as a customer. Mehmet: New charter ??: do it fast as multiple implementation might branch Lhotka: draft is dependent on the JSON draft. Lhotka: this draft should go together with the JSON draft. Andy: the JSON encoding must follow Lada's draft Kent: Juniper is also looking into this. Tina Tsou: Can somebody present RESTCONF at ONF NBI summit? **** NETCONF Efficiency Extensions (Andy) http://www.ietf.org/proceedings/88/slides/slides-88-netconf-4.pdf ??: like it, are notifications in scope? Scott Whyte: You don't address notifications. Andy: Customers want an SNMP type notification. Customers don’t even need security always. Mehmet: Discuss case by case or as a package. ANdy: mailing list debate Martin: support this. This is not just efficiency. It is usability as well. Who supports 15, Against: 0 Andy: this does not breaks anything, backwards compatibility. Mehmet: raise discusssion on mailing list. **** NETCONF DHCPv6 Options (Mikael) http://www.ietf.org/proceedings/88/slides/slides-88-netconf-5.pdf Want to use it for all types of boxes Dan: Should this be in NETCONF or DHCP WG? Mikael: This is about bootstrapping NETCONF, so it belongs to this WG, but should also be reviewed by DHCP WG. Mehmet: Who wants it: 10, against 1 Andy: This should be combined with Kent's work. Kent: +1 **** Update on OpenDaylight (Jan Medved) http://www.ietf.org/proceedings/88/slides/slides-88-netconf-6.pptx YANG models used in adaptation layer. RestConf is automatically redering APIs. Zero touch This looks like an NMS, handles the full network not just one ME. access control to data Need RstConf JSON encoding binary encoding optimisation Query language, a more precise query possibility I2RS (maybe netconf) YANG ODL extensions (request touring, JavaApiGeneration, remoteMounting) YANG programing language bindings, how to create APIs from YANG (Java, Pyton) Possible remote library Standard service models: VPN, DDOS, QoS, Topology, IP, ACL, RIB WADL/RSDL from YANG? for RestConf clients YANG as an interface description language Carl: Any special protocol in mind for the API generation? KarlM. What protocol for the language bindings Jan M: We dont care about protocol KarlM. The protocol will show up in the API JanM Netconf or RestConf Jan: Essentially NETCONF. Ole : What about locking? ??: Distributed locking needs to be solved JanM: Both, it is in the codebase Jan: Locking is really a nightmare in a distributed syastem. Benoit: Restconf NBI or SBI? Benoit: Will RESTCONF be implemented? Jan: Yes. JanM: Both, it is in the codebase Edward Crabbe: Are your suggestions future action items for NETCONF of YANG groups? ??: Who should standardize it? Which WG? Jan: General models should be done ny NETMOD, the rest probably by OpenDaylight. JanM Netconf, Netmod? Zhen Cao: In the diagram, are the applications aware of which network element a request is directed to? Jan: No, on purpose. DanR: We encourage other areas to develop their own models JanM: extensions and program bindings Netmod/Netconf ??: Are the NBI transprent to the SBI JanM: yes, the NBI user does not know which SBI used DanR: This is a lot of work. We need to identify elements that are for this WG, YANG WG, but other elements (models) might go to routing area. Dan: We have to identify elements that are important for this WG. JanM: we need Restconf/Json?Binary encoding Efficiency is also wanted. Extensions to Netmod Martin: are you asking for more complicated quesries or better filtering Martin: What do you mean by queries? Jan: Queries that are more complicated that XPath, mainly for filtering. JanM Both Mehmet: Are you available for additional discussion? Jan: Absolutely. JanM available for additional discussions.