Skip to main content

Minutes for NETCONF at IETF-89
minutes-89-netconf-1

Meeting Minutes Network Configuration (netconf) WG
Date and time 2014-03-03 13:00
Title Minutes for NETCONF at IETF-89
State Active
Other versions plain text
Last updated 2014-03-17

minutes-89-netconf-1
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.