NEE - BOF IETF-69 Co-chairs: Sharon Chisholm, David Partain Notetakers: Benoit Claise David B Harrington Martin Bjorklund All presentations are available in the proceedings. Sharon and Dave kicked off the meeting by explaining the goal of the BOF was to give all the drafts written defining NETCONF extensions a place to air as well as to discuss forming a working group to address some subset of the issues identified. Discussion of Partial Lock RPC for NETCONF (Balazs Lengyel) The mechanism is simplified by supporting only a subset of Xpath expressions. This is independent of whether full Xpath is supported for other purposes. Andy Bierman: Supports this draft, but is concerned about DOS attacks and thinks the interaction between global lock and partial lock is fuzzy. Balazs Lengyel: Handling this DOS attack is out of scope Andy Bierman: can you take global lock and downgrade to partial-lock? Bert Wijnen: Do not over-design as we did for SNMP (but doesn't see overdesign yet) Wes Hardaker: supports this draft, but wonders about this scenario: what happens if A and B have locks and someone does a commit? - must be stated in the document (i.e., partial-lock will block a global operation like commit). The document doesn't discuss ramifications of two people with overlapping locks or even non-overlapping locks that could impact running config. What happens if one person commits a partially locked changed config? Discussion of NETCONF XML Schema Query (Sharon Chisholm) Andy Bierman: We are making lots of decisions about data modeling in an ad-hoc manner. Data modeling issue - specialized function to get names of specialized functions? We can always get the whole tree. Knowing where the data is rooted is not hard. I don't see the justification for a specialized verb. Chicken and egg problem. => suggest use instead, which should be good enough. Sharon Chisholm: agrees. Andy Bierman: Pointed out that doesn't work, since it can't have version number and location. Balazs Lengyel: Agree with Andy Bierman. Suggestion: merge this with NETCONF monitoring draft. Balazs Lengyel: This is in XSD; we have not reached consensus on the data modelling language. Sharon Chisholm: Use XSD for now. Emile Stephane: We need to be able to learn a device's sw/hw version to be able to configure it properly. Sharon Chisholm: I want to move away from that paradigm (getting the "system group") and instead learn data model versions (schema). Discussion of ACL data model for NETCONF (Iijima Tomoyuki) Kaushik Narayan: What is the intended scope of this model, considering that there are other WG dealing with data model? There is no RFC yet, but submitted to the RADIUS extension WG. Don't want to have multiple models, one for RADIUS, one for NetConf; will the NETCONF WG align its work with other WGs? Sharon Chisholm: On any data model work, we would work closely with others. ? Sanchez (sorry, full name missing): RFC4849 data model for Diameter ACL filtering (traffic rule draft in Radext); about 90% of the functionality overlaps. Dan Romascanu: agrees work needs to be aligned with other work. Sharon Chisholm: NEE would only do access control for NETCONF itself. Dan Romascanu: agrees that this is out of scope for NEE. Thanks to the author because answered a call for data model. Question: any implementation and testing? Iijima Tomoyuki: prototype of VLAN and ACL data models is done. Malhar Shah: ACL. Do you make sure ACLs are entered in correct sequence? the order is significant. Andy Bierman: there hasn't been any agreement in SNMP or CLI on configuring ACLs. ACL _for_ NETCONF is much easier, but still difficult. Emile Stephan: 80% of config lines in core router is about ACL, so should be part of NETCONF. Sharon Chisholm's answer: if true (note: someone confirmed this in the audience: ACL of 7000 or 8000 lines), this sets a priority for this work. Balazs Lengyel: would like to know how the data model was deduced. Please put the XSD in draft. Emile Stephane: do we need to work more on the verbs or the data models? David Partain: We can't do data model for ACL until we know how to do data models. Sharon Chisholm: Disagrees. We can talk about ACL requirements. Discussion of NETCONF access control profile for XACML No speaker present, but Sharon Chisholm said a few words. Kaushik Narayan: XACML has multiple parts, including a data model and a SAML profile for authorization. For NETCONF, we need to discuss on-the-wire behaviours. David Partain: please provide feedback on mailing list. Andy Bierman: This approach trades flexibility for complexity. Wants to keep it simple. The experience of massive complexity in SNMP was not good. David Partain: When will discuss the charter, we will see if we are ready to accept this as working group item. Discussion of NETCONF over TLS (Dan Romascanu, for the author) Sharon Chisholm: initially not so excited about a fourth NETCONF transport. Only theoretical gain, or really a market value/real product? TLS uses small footprint, and thus can be an alternative for small boxes. is this the case? Dan Romascanu: don't know, but the author thinks so. Dave Harrington: many small boxes uses HTML for management. However, HTML difficult to work with when many devices. If wants small boxes more manageable, easier to add security to HTTP, as done in HTTPS RFC 2818. See some possible synergy there. Balazs Lengyel: How do you transfer the user identity when you set up TLS? Dave Harrington: Excellent question Dave Harrington: SNMP over TLS implementation. Juergen Schoenwaelder has done some research about SNMP with TLS versus SNMP over SSH. Apparently, some better performance with TLS, especially because of the session resume feature. It was discussed in ISMS in the past, so have a look. NETCONF Monitoring Schema (Sharon Chisholm) Andy Bierman: Previously the NETCONF community had said this sort of thing was just for debugging and that there were more interesting problems to work on. Glad to hear people are now more interested. But, how useful is this info? Just more bytes on the wire? I have counters in my implementation that might be of interest. Sharon Chisholm: For debugging. Found it useful. Nice to have a standard way of doing this, allows to know who has got the lock. David Harrington: more text + look at RFC b 4181 Guidelines for Authors and Reviewers of MIB Documents.b + some other comments Andy Bierman: Draft must add descriptive text. XSD is too difficult. David Harrington: Yes, needs text. Read the MIB document guidelines. Messages sent - is that RPC AND notifications? Sharon Chisholm: needs to be clarified. Wes Hardaker: important type of information, e.g., if I want to reboot, it's good to see which sessions exists, so support it. Be careful: getting right the first time is not easy. Call home in the future? Think about directionality. Things are missing: would be useful with transport and context per session. Think about use cases. Sharon Chisholm: Call home never went anywhere Balazs Lengyel: Good that for once, this is done within the NETCONF protocol itself. This is used for debugging of the implementation and setup. Normally statistics are provided over SNMP, this time over NETCONF. do we want that? Experience of implementing NETCONF over SOAP (Hideki Okita)) Andy Bierman: The draft has come up 3 times. Not really a job for a WG. Publish as an individual informational RFC. Sharon Chisholm: NETCONF server web-services capable, or just NETCONF-capable? If there is more about making the NETCONF server a web-services server, I would be interested in seeing further discussion, otherwise I agree Informational should be fine. Taking discussion offline. Emile Stephan: has been using SOAP, and it works. It is easy to map NETCONF operations and SOAP. A NETCONF Datamodel for Diff-Serv QoS Control Configuration (Hideki Okita) No comments. Charter discussion Sharon Chisholm: charter more narrow than the agenda Dan Romascanu: deadlines might be unrealistic; realistic deadlines are required for approval. I do believe as a contributor some of these are needed now. Balazs Lengyel: No draft is starting point for access control. Balazs Lengyel: There is additional work that should be done on NETCONF. There have been other issues brought up on the mailing list, a few updates on the basic protocol Bill Fenner: possible gap, about authentication and authorization. Operators are fine with SNMP read access, but ssh access for NETCONF? Not sure. Perception is that NETCONF ssh access gives full access to the box. Sharon Chisholm: Exactly what is this perception? Bert Wijnen: Completely in conflict with NETCONF requirements! Bill Fenner: Different operators have different concerns... David Partain: what should the WG do? Bill Fenner: TLS would help. Thinks we may need an authentication mechanism just for NETCONF. SSH sounds like you can login to the device which is scary. Kaushik Narayan: several proposals around access control. Do we expect one ore several proposals? More than one way to solve the problems. Don't want yet another access control model. Sharon Chisholm: that's why we want to do requirements first, not a solution. David Harrington: Access control should go from fine-grained like SNMP to something coarser, and locking is going from coarse to finer-grained; is it expected that granularity of locking and access control might be aligned? Course grain versus fine grain in access control and locking. Sharon Chisholm: Hopefully. maybe add something like that to charter? David Harrington: ISMS is doing access control, particularly with RADIUS. We should look at that. Chairs: Should we form a WG? Andy Bierman: Why do we have two alternatives, the charter or nothing? The charter is too big. Don't do everything in the charter. Schedule is not credible: lucky to finish any items in 2 years. Dan Romascanu (with AD hat on): must have realistic dates, otherwise not chartered. Dan Romascanu: any item that gets to be chartered must include 1) operational need, B wouldn't it be better to have more operational experience what we are missing before chartering a new WG, 2) do we have resources to do the work, including implementers (not necessarily multiple interoperable implementations yet, and 3) at least three committed reviewers for each piece of work that are not related to the work. Dan Romascanu: There have been additional contributions made during the session that also should be allowed to provide the above three justifications, and possibly be permitted WG considerations. Question: Why is this a new WG, and not in NETCONF. Dan Romascanu: we will sit with the chairs of NETCONF to decide if this should be done within the NETCONF WG, with a new charter and possibly with a set of new chairs. David Partain: protocol extension work - where can that be done? David Partain: These questions will be asked on the mailing list, but there was general consensus in the room is that people want to continue work on NETCONF-related issues either in a new working group or in the NETCONF working group.