Notes of the NETCONF session at IETF #89 Agenda 1. Admin, note well, agenda bashing Status from Vancouver – rechartered 2. Reverse SSH – Kent http://www.ietf.org/proceedings/89/slides/slides-89-netconf-0.pptx Draft 3 slide 6 Applicability statement added by security folks – use the port only by NETCOF Andy: there is just port number, not sure if the server is connecting to NETCONF Andy – how is this new text enforceable? Kent: no hard cut-off of the session, it's just against the spec Reference implementation – will be made public Chairs – ready for WGLC. Any issues? None – we’ll start WGLC at the end of the week Bert: start WGLC 3. NETCONF over TLS – Juergen http://www.ietf.org/proceedings/89/slides/slides-89-netconf-1.pdf YANG definitions moved Plans to implement – end of this month No questions? Do 4 weeks LC to receive feedback Bert: start WGLC 4. NETCONF Server model YANG Data Model of NETCONF Server Configuration (Kent) http://www.ietf.org/proceedings/89/slides/slides-89-netconf-4.pptx slide 9 Security considerations – Bert – vulnerability of objects should be described in the YANG document Bert: the object can be modified, so it presents a security issue, we should describe the vulnerabilities if someone unauth. gets access. Andy: we have guidelines for this. slide 12 IANA considerations – is one-or-many consideration OK? Andy: You can only have one port per IP address. Kent: normal approach is to have one port for all interfaces Martin – solution quite nice, use the default declaration Martin: same comment, I like the approach, another solution would be to have a key consisting of address and port. Bert: needs more work, should be discussed in ML Rethink persistent/periodic choice? Martin: What kind of keep-alive do you use for persistent connection? Kent – needs to be defined Martin: But this is not standardized, so what does this document in fact specify? Kent: Doing it for TLS can be tricky. Martin – transport-dependent? Martin: We can implement it in NETCONF. Dean Bogdanovic – application level Juergen will send the RFC number Balazs – any reason not to do it on the NETCONF level? Balazs: I'd prefer to do it in NETCONF - one implementation. Kent: good question, we can define a client keepalive capa Martin: no capability, just define an RPC. Kent: Talking about RPC, this should be define for the client. M. Abramsson: How about TCP keepalives. Kent: TCP keep-alives are outside crypto tunnels, is it a problem. Zheng: What if the devices are in different VPNs Quanjunq Zhen – how it works in the VPN scenario? Maybe specify VPNID David Lamparter – different forward instance than the router David Lamparter: you are talking about VRF, some way of spec. not only IP adress but also the VRF. Kent: will look into it. Bert – please post the requirement to the list Martin: persistent connections are a scalability issue. Is it a useful use case? Maybe only good for small networks. Kent – in these cases reduced latency important Kent: You can still support 64K device (enough file desc.) Andy: use case - notification listener, you need to keep the session. Kent: good point Martin: if the client subscribes to a notif. channel, it will keep the session open. Still not clear that persistent connections necessary Mehmet – make WG ID – change name to NETCONF Configuration Server Mehmet: you need to submit as WG work item draft 5. RESTCONF – Andy http://www.ietf.org/proceedings/89/slides/slides-89-netconf-2.pdf slide 3 Do we need a message-id? Martin: isn't it a generic HTTP problem? Andy: message-id is useful for debugging Dean – message queue Dean Bogdanovic: we need it for event notifications. Kent: server can reply in different order Kent – pipe-line protocol, may send more than one request Wes – all APIs do this for you, no need to add for them, will not look at it Wes: You need to define use case, it's not needed for HTTP, this context bit needn't go across the wire. Andy – on the management side useful to correlate requests and replies Andy: needs more discussion slide 4 Select parameter Different implementations defined differently Martin – XPath adds complexity to the implementation, optional in NETCONF Martin: I don't like it, we should be able to invent a one-liner expression. Andy: XPath in the server is tricky. We can come up with something. slide 5 Server support verification - with available tools? Kent: we use RESTeasy (?), and everything works. slide 7 Error media type – yes (Martin, no other opinions) Additional datastores – only running, an Issue? How will additional data stores be supported? Dean – one makes things easier Dean: Supports one datastore, better for I2RS. Andy: Location header has datastore in it. If we have multiple datastore, it could be a problem. Anton Tkachick – against one data-store – huge operational model Anton Tkacik: separate config true/false. Andy: Sometimes the persistence is not either/or. Persistence and R/W should be in the schema. App writers then have to look into the Location header. Martin: same problem with the Content query parameter - if you don't have it, it defaults to everything. If we had separate datastores, then other datastore would be easy to add. Solution on mailing list slide 8 PATCH media type discovery How does a client know which media types are supported by the server? Lada: Could OPTIONS method help? Andy: It only says that PATCH is supported. Martin: this should be a generic HTTP problem, we should ask about possible solutions. slide 9 Kent: This is mainly to ask about backward compatibility. Version discovery Kent – for each resource return the version, download new version if needed YANG to resource mapping What should be done about top data nodes that are not containers? slide 10 Kent: Choice needn't be a resource. Can a choice be a resources? Closed as decided on the list slide 11 Kent: It's not per every request. But do we want to hardcode "/api/restconf"? But it is probably sufficiently unique and safe. well-known usage issue by Kent not do it slide 13 self links for HATEOAS support Andy: self links make replies bigger. Kent: My company has concern about not supporting HATEOAS. Andy: We are REST-like, not RESTful. Kent – OK with the resolution slide 14 Netconf-state monitoring support Should long-term RESTCONF operation be considered sessions? Work on the list Dean: Call it monitoring stream rather than monitoring session. slide 15 Kent: can we support call-home for RESTCONF? Andy: have to look at it. Secure transport TLS to be defined Kent – need to support reverse-TLS? Because of the firewall issues Need to look in the issue Mail list issues – how keys are encoded in the URI Bert – new ID 6. PATCH issues YANG Patch (Andy) http://www.ietf.org/proceedings/89/slides/slides-89-netconf-3.pdf slide 4 OK to support PATCH? ? – reflect discussions from the list ? (Cisco): record the discussion in ML COAP does not support PATCH I2RS will need it Kent: PATCH is optional but we should promote it. Identification of YANG patch capabilities 6lo, 6tsch – too many capabilities, they do not support config either Protocol independence Location leaf slide 9 Operational operations Dean - Difference between remove and delete? Kent: This is not necessary, we have ETag if-match. Andy: ETag are optional. Martin: We shouldn't require ETags for every single resource Andy – probably not both needed slide 11 Bulk editing support Make the change, take it to the list Martin: why is the leaf-location needed? Andy: Target is pointing to a list, and you are pointing to a nested list. Not needed for YANG-based data. I may remove it. Mehmet: Again, submit as WG item. 7 .Zero Touch – Kent http://www.ietf.org/proceedings/89/slides/slides-89-netconf-5.pptx Use ‘configlets – almost complete re-write of the document slide 7 Martin: Why is it part of the draft? Kent: This is part of the boot sequence. Andy: It looked to me it's for firmware that's smart enough. Martin – what does the sequence before downloading config need to be configuered here? Dean – because the configuration needs to be checked Dean: Everytime you boot, you have to check the image version. Andy – different flavors of routers in the same image Wes – make sure that this is not a downgrade attack Kent: Agreed. Dean – what if you need it? Dean: Customer sometimes wants to downgrade. Wes – do it after the security sequence Wes: You don't want to downgrade to something having security hole. Ian Duncan – digital signature should be enough Ian Duncan: Downgrades are often very useful. You are just adding something that makes things more difficult. Andy – agrees with this comments, downgrades apply, may have loaded buggy version Kent: Move to maillist. slide 8 Physical presence Mikael Abrahamsson – authors do not agree about what physical presence means Michael Abramsson: Our use case needs something along these lines.