--- April 12, 2008 --- Minutes of the Network Configuration WG Session at the IETF #71 MONDAY, March 10, 2008 1740-1950 Chairs: Bert Wijnen, Mehmet Ersue AD: Dan Romascanu Minute Takers: David Partain, Juergen Schoenwaelder Agenda and WG status slides: http://www.ietf.org/proceedings/08mar/slides/netconf-0.ppt Agenda bashing - Added Mark's presentation on schema advertisement work after current charter items. There were 50 persons in the NETCONF session. WG status review given by Mehmet Ersue. Notification draft finalized by WG with Bert Wijnen as the proto writeup. Current status is: "IESG Evaluation", will be discussed on IETF telechat March 27. The open mic session will allow people in the NETCONF working group to point out what they think the most important NETCONF Data Modeling requirements are. ------------------------------------------------------------- NETCONF over TLS (Charlie Kaufman on behalf of Mohamad Badra) Slides: http://www.ietf.org/proceedings/08mar/slides/netconf-1.ppt Disclaimer: Charlie's not that familiar with NETCONF but read and commented the TLS draft. PSK hashes ensures that credentials stored on a server can't be stolen. Three options for user authentication submitted to mailing lists: 1. is simple to do, much like much authentication that happens on the web all of the time. Server is authenticated (e.g., using a certificate) and thereafter the user logs in with a username and password. Might raise questions from the security ADs; technical detail is that NETCONF assumes the authentication is part of the transport not NETCONF. 2. Enhance TLS so that user authentication becomes part of TLS, won't fly in the TLS community 3. Running BEEP over TLS, looks complex for a solution, requires that all implementations do actually support BEEP Enhanced TLS: Ekr: no way. BEEP discussion: Q: Is TLS over BEEP not redundant? Charlie: The BEEP transport for RFC 4744 already talks about the possibility to use the TLS and SASL profiles of BEEP; so the BEEP over TLS option seems to not really be an option as it is already defined. Bert Wijnen - Would this require a BEEP implementation on the clients. Answer: Yes. Bert: so this conflicts with the goal of NETCONF over TLS since we don't want to require something additional. Juergen S: My understanding is that BEEP already runs over TLS if you want. Isn't the problem thereby already solved? Charlie: don't really know. only works for plaintext passwords, but it's possible to introduce SASL, but this hasn't been discussed on the mailing list. A few people in the room thought that merging this work with the BEEP document was not a good idea. No one knew who had advocated this. Q: Is the requirement to reuse the same port for a TLS mapping coming from the security area? Charlie takes an action item to figure this out. Q: Is it not a requirement that we can hook into existing authentication infrastructures? Charlie: We need to figure out whether there is a requirement to have password authentication or whether TLS certificate authentication is good enough for our needs David Nelson asks about requirements about backend databases you expect to use this with. Worried about requirements that will mean that we can't use legacy authentication systems such as RADIUS. Charlie: yes, the way this is designed will mean that you cannot use this with these alternatives. There was a brief discussion about how the SSH transport works. Name??: should SSH transport be the one you have to use if you want plaintext passwords and TLS could be used when you want mutual authentication with certificates and the like. Phil Shafer: What is the motivation of the TLS work? Bert: There are cases where TLS is deployed widely but SSH is not. We might to have this in mind when we check the password authentication requirement. So, this is just another transport. Phil: So there are places where they don't implement our standard transport, so how much sympathy do we have? Later in the meeting we checked on implementation plans (see below) and it seems no one in the audience was planning to implement Netconf over TLS. So the question to be asked is: Does it make sense to standardize. Specifically given all the (yet unresolved) issues as per above presentation/discussion. We will check this on the mailing list. ------------------------------------------------------------- Partial locking (Balazs Lengyel) Slides: http://www.ietf.org/proceedings/08mar/slides/netconf-2.ppt With respect to first slide, Sharon Chisholm: we have to support pre-configuration. Are we making that impossible? Balazs: no, you have to define the top-level node and lock it. Randy Presuhn: Not explicit in the document that locking the node got all of its subnodes. If you delete some sub-tree that's locked, can someone then alter it? Balazs: No, and since it's not clear in the draft we'll make sure we update it. Wrt to what to have as normative for models: Bert - shouldn't the normative model be XSD since that's what we have done so far? Both are non-normative today. Mehmet: one of them needs to be normative. Dan Romascanu: Use the XSD since that's what's we've used so far, put YANG in as informative. Andy Bierman: What would be the point of removing the XSD? This is since Balazs suggested the English text should be normative. Andy objects and thinks that XSD should be normative since that's what we have. Balazs: That's what I'll do. With respect to Multi-Datastore lock: David Harrington: I sent the question because the document says it locks one or more datastores. Balazs: I will remove this from the open issues and change it to "one operation locks one datastore". Security slide: David Partain: Is more security considerations text needed? Who suggested it needs to be more? Balazs: David Harrington and Mehmet were mentioned. Bert: isn't pointing at 4741 ok? David Harrington: there are cases that don't seem to be covered since this is not a global lock. Partial locking is different. Balazs: Lock expression is evaluated when the lock is created not when an edit expression is executed. Will add some text. Wes Hardaker: Document differentiates between a global lock and partial locks for the security considerations sections. For example, what happens if you copy candidate to running while a partial lock is held? Locking gives the impression that locking gives exclusive power and access, so we need to document how NETCONF operations are affected. Bert: This seems to be a good exercise. Could you post some of these concerns to the mailing list? Wes: Sure. We need a matrix that covers the various operations and their interaction. Access control slide: Bert: I'm happy with how you worded it. I think that's good enough. If someone disagrees with this, please send text. We don't want to block this document by waiting for access control. David Harrington: at one point, the document said you have to have read rights. Balazs: I believe it says "some rights". Sharon: it should say "you can lock if you have sufficient privileges". We should make as few assumptions as possible about access control when writing this document. Andy Bierman: just like you might take out a global lock to get a consistent read, you might want to do so for partial locking. Andy Bierman again: I don't understand why the security issues are different for this and global locks. Bert: Wes has already agreed to send some mail to discuss this. ------------------------------------------------------------- NETCONF Monitoring Schema (Mark Scott) Slides: http://www.ietf.org/proceedings/08mar/slides/netconf-5.ppt Should we have a specialized (inband) get-schema ? Some seem to want it, need to figure out whether there is WG consensus. Sharon Chisholm: If we define this as part of the data model, then retrieving the whole contents of the datastore will also get this, whereas a specialized verb would allow us to scope. So that, you retrieve the schema definition there, but it does not show up as part of your operational and configuration data. Mark: Yes, I thought we don't need to keep the references to the schema in the normalized monitoring model. The schema might become large, I don't know whether someone wants to get all of them. David Harrington: Why do we have to be able to do this with NETCONF rather than something like ftp? Mark: Originally I proposed this but a few people in the last neeting and on the mailist who wanted to be able to do so. Bert: Do the people have an opinion on that? I know that a few people asked this. The question is, do we have consensus on this? Emile Stefan? France Telecom: Regarding operational needs what we need is the capability of how to get the list of the schemas of a device and having the version of various schemas which are currently implemented on the device. Mark: That's currently there, you can do basically a get on monitoring data and return a list identifiers, which are basically the schema names and version and a location (which is an ftp or a URI) Phil Shafer: I want to be able to retrieve it using NETCONF. We're reinventing stuff, but I want it. Bert: So, you see the bad side, but you still want it. We need to get consensus on the list. Mark: We'd only be able to respond with plaintext XML, which can be quite verbose. We may want to be able to get it in another format, i.e ASCII version. Wes Hardaker: One of the complaints about SNMP is that you cannot get the information about capabilities. As many people said this is one of miserable failures where SMI dealt with stuff like this, the agent capabilities and referral didn't work. If the device would just return it's abilities that would be a good thing. That's certainly something to do. That being said if you do publish the schema and you don't do it with a separate command, make sure it is published in a standardized pattern or tree, so you can consistently block or allow access to it. Balazs Lengyel: Will you include partial locking? Mark: I have to figure out how to include locking first, I have noted to include partial locking absolutely. It opens the same discussion as with access control. Similarly, you might want not to return lock information for which you don't have the visibility. We have to sort that out. Balazs Lengyel: You have a statement that the capability should include minimally what went in "hallo exchange". Why is this different from schema retrieval, why not exactly the same set? Mark: We have an example where we don't want to put everything in the capabilities exchange because based on the configuration of the box during the session the schema that is relevant can change. E.g. if I enable a particular type of interface I will now advertise it's schema as being supported on the box. Q: Do you report state about partial locks? Mark: Yes. Q: What is the set of minimally announced capabilities? Mark: It might be useful... Q: Lots of detailed questions out there since the document is sometimes vague? Mark: We have to work through them. Q: Can the file: URN not be used to report a locally stored schema? Mark: Might be workable. Q: Is schema advertisement mandatory? Is the storage of schemas on NETCONF devices going to be a requirement? Mark: Needs to be worked out, clearly some devices may not want to do this. Andy Bierman: really doesn't want to require devices to store their schema. Wants to make sure that it's optional. Mark believes that the optionality is there. Q: Do we prefer over a ? Mark: Some seem to want , need to figure out whether there is WG consensus; ensures that people do not accidentally retrieve voluminous schemas. If we go without , make sure the schemas are easy to filter out. ------------------------------------------------------------- Implementation discussion: Martin Bjorklund: I've implemented partial locking, not the TLS stuff, and planning to do the monitoring draft when it's stable. Bert: Who will implement partial locking? 3 independent implementations. Monitoring document? Same 3, plus one extra from Nortel. TLS document? No hands. Mehmet: We don't know what Badra is doing. Bert: Who will implement the notification document? 3-4 independent implementations Dan Romascanu: Ask all the questions on the mailing list, please. Bert: Is the WG interested in an interoperability event? Either on these documents or on the published RFCs or both. Ajay Kachrani: How many implementations of NETCONF are there in general and how widely is it deployed? Bert: There were something like 5 implementations when the last interop was done. No figures about how widely it is deployed. Bert: Who is interested in an interoperability event? No hands. ------------------------------------------------------------- SOAP implementation presentation (Tomoyuki Iijima) Slides: http://www.ietf.org/proceedings/08mar/slides/netconf-4.ppt Bert: This document is in the hands of the IESG, so we don't have to do anything else with it, correct? Dan: The document went to the IETF LC, has been revised, will now go to the IESG review, if more folks would read and comment to improve the quality, they are always welcome. Please forward them to me or copy the NETCONF maillist as well. Will be in a few weeks on the agenda of the IESG. Bert: And I believe this document goes for Informational, right? Dan: Yes. ------------------------------------------------------------- Any other business: Access control: Bert: Who is interested to work on access control? Andy Bierman and David Harrington would be willing to put some cycles into working on access control. Bert: who would contribute other than the authors? Sharon: I wonder about the urgency of this work. I'd like to wait another cycle. Andy: I'd be happy with that. Martin Bjorklund: I think it should be deferred as well. Andy Bierman: I'd be more interested in implementing the notification stuff if there were interesting information being sent. Who is willing to review documents? no hands Given the number of things NETCONF related things going on, access control does not seem to be high priority at the moment. Notification draft: (now in the hands of the IESG) Who will be implementing the notification draft. 4 implementations, 3 of them from Nortel. Notification content: Phil Shafer: any plan to standardize content for the notifications? Bert: Andy's already said it's not interesting work without it, so I'm willing to entertain the possibility. Phil: What would be the basis of that work? SNMP traps? Syslog? Sharon: none of the above. Phil: So, would that be NETCONF-specific new work? Bert: we should decide that. Will there be people to review IDs for notification content? 5-6 hands were raised Who would be interested to review if a document would come out for SNMP or SYSLOG notifications? 4-5 hands were raised Will this be IETF standards-track SYSLOG or deployed SYSLOG? Ideally, this would cover the standards-track SYSLOG protocol. Dan: Let's write some internet drafts. There seemed to be sufficient interest in content that if someone would write an ID (for NETCONF-related), people would look at it. Same is true of the syslog-related work. Bert suggests that those interested publish drafts and take it from there from the next IETF. ------------- Open mic topic NETCONF modeling requirements: What DML requirements are important from a NETCONF point of view? Are there any NETCONF specific requirements? Dan Romascanu: what would be a good scenario of what happens at the CANMOD BOF? Bert: Doesn't seem appropriate for the NETCONF. If there are requirements we think are very important, and we don't think we have similar viewpoints, then discussing them here is appropriate. Randy Presuhn: We have a non-agreed requirement and we want to know if it's even possible in NETCONF. Martin agreed that it is not possible. Subtree filtering doesn't work with deep keys. Andy Bierman: this is a known limitation of subtree filtering. XPath took care of that, and we didn't want to reinvent that. Bert: Are we willing to give up subtree filtering now? Andy: No, that's not what we're saying. I don't think we should hold up data modeling at this point for that. Phil Shafer: motivation of subtree filtering is to avoid the cost of implementing xpath on a device. That consideration is still there. Andy: How out of date is our xpath 1.0 now and in two or three years? We use the out of date xpath. Phil Shafer: how much restrictions are we willing to do in order to get a data modeling language? Juergen Schoenwaelder: how many people understand this? About 10 people raise their hands. Requested that this be written up for the CANMOD BOF. Randy: it's already in the requirements draft. Andy: deep keys are complicated and I don't think it's worth it at this point. Randy Presuhn: Since we have implementors here, what have people done with respect to internationalization and localization of error messages. Some of these were agreed requirements. Phil Shafer: we don't do anything right now because the cost is prohibitive. Balazs: Internationalization is very expensive to get it right. Andy Bierman: If there were libraries that allowed me to do this, I'd probably support it, but I don't have anything right now. Bert: Maybe current customers are ok with English, but perhaps other customers won't be as we grow. Phil Shafer: There are multiple problems involved. To go all the way, the expense is simply too high. Balazs Lengyel: I agree with Phil. Bert: does this help? Randy: Don't know, but it's more information. Randy: "notification get" was also not an agreed requirement. Bert: how does this fit into data modeling? Why is this a data modeling language requirement? Sharon: The concept is that a chunk of definition that could be used to retrieve information could be used as the payload of a notification or vice versa. The question is whether (config) data can be used for notifications and vice versa. Randy: Do people see a value of that level of reuse? Probably any of the solutions is going to be able to support this, so it doesn't really help us to determine which one we should use. Does this impact the choice of the language? Bert: Reuse is good. Phil Shafer: I thought I understood, but I'm getting multiple answers. This requirement does not help to decide between languages. Martin does not think it means that you reuse a complex type. He thinks it means that this part of the tree can be tagged that it may be part of a notification. It is about the use of (config) instance data in notifications. Bert: Does that mean that when you define data, you say that it will be available for read, for notifications, etc? Sharon: yes. Andy: this doesn't seem that hard to me. Like SNMP, when you declare a notification macro, it's build into the definition, you send a copy, it's understood it's not the real one, it's a copy. Why would we need the same thing, it's a mechanism in your language, which says, I'm sending a copy of that. It doesn't have to be the name of the leaf. Bert: Phil you have the final word. Phil: How cool. My question is what if the thing you tag is being part of the notification belongs under the hierarchy and without the hierarchy it does not make sense. If I say, here is my MTU and if I throw my MTU into the notification you have no idea what it means. The chairs: Allright, thank you all, we are at the end or our session and I guess many of you we will see at the next IETF PLEASE do bring up the various items on the mailing list (as discussed/agreed above). PLEASE do submit Internet-Drafts for work that you feel needs to be considered.