Minutes of the Network Configuration WG Session at the IETF #72, Dublin, Ireland TUESDAY, July 29, 2008 1850-1950 WG Chairs: Bert Wijnen Mehmet Ersue AD: Dan Romascanu Security AD: Tim Polk Thank you to the minute takers: Juergen Schoenwaelder, David Harrington and the jabber scribe: Sharon Chisholm Agenda and WG status slides: http://www3.ietf.org/proceedings/08jul/slides/netconf-0.ppt There were 35 persons in the NETCONF session. Bert Wijnen takes care of the administrivia. WG status review given by Mehmet Ersue. NETCONF Notification draft has been published as RFC 5277. ------------------------------------------------------------- NETCONF Monitoring Schema (Mark Scott ) Slides: http://www3.ietf.org/proceedings/08jul/slides/netconf-1.ppt Mark Scott presents the monitoring slides Issue #1: Which terminology should be used? schema or model or data model ...? Dave Harrington: we used to make a distinction between data models and information models David Partain: in YANG, we call things data models or modules Sharon Chisholm: in XML world, people use the term schema Phil Shafer: since this is not XSD only, why not use data model Dave: RFC 3444 should be checked whether it applies David P: prefer data model Martin Bjorklund: What about the get-schema RPC? Bert: Thats consistent with the NETCONF documents and we should conitnue with that right? Bert: I think this has not been discussed on the maillist yet. We'll try to reach consensus on the maillist on that. => put up on the mailing list to see where there is consensus Issue #2: lack of agreed XSD definitions for data types to use. Mark: How does this discussion impact current work to standardize content? Dave: OPSAWG works on SMIv2 translations to XSD. If you want to discuss this work, this can be done in that workgroup. Mark: For those that are already being covered in Bob's work we can use those as is but in case we want a different data type or an enhanced data type that's not covered by Bob's work. There are still complex data types which we need. Are we defining them now and use? David P: Bob Natale, Jürgen Schönwälder, Mark should sit down and figure out a good way forward and propose it to the list, cross-post to OPS area workgroup. Mark: Is that because we have agreed that we must have intrinsicly the same data types as defined in Bob's work? Bert: We did not agree but we know there is similar work, speak with those people and try to come up with one solution. Dave: OPSAWG is different from what you are doing here, it is only dealing with SMIv2-> XSD translation. This is not the same work it has a different fokus Mark: Arguably more data types might come up as we define more content. When someone defines NETCONF content are we at least within the NETCONF context going to use it. Jürgen: With YANG/NETCONF, we have a chicken and egg problem. We can only solve this by making a best guess and go ahead; more general question is what happens if you do different SMIv2 translations. SMIv2->...->XSD issue is not a problem to be solved in this WG Bert: Before WGLC we should think on these issues. => The issue will be brought to the mailing list. Partial Lock RPC for NETCONF (Balazs Lengyel) Slides: http://www3.ietf.org/proceedings/08jul/slides/netconf-3.ppt Balazs Lengyel presents the locking draft Issue #1: remove empty locks? Balazs: proposal to keep empty locks for consistency reasons. Issue #2: Need to add some clarifications that: Does the granular locking put requirements on other protocols that night lock the database? Balazs: My view is if something is locked let it as it is. Discussion of whether partial locks imposes behavioral differences on other protocols. Dave: how will a NETCONF lock impact SNMP? If you put a partial lock on NETCONF that covers underlying instrumentation. The lock might impact SNMP transactions and error codes. SNMP is not prepared to handle this kind of issues. Balazs: we already have this requirement for the global lock; there is nothing new. David P: You'll get a not writable or resource-unavailable error from SNMP Wes Hardacker: It's easy to check partial locks if the data model between various data model languages work well. If the approach to modeling is dissimilar between interfaces, this is difficult to do. For global locks, this is easy – if locked, prevent all sets. To do this for requiring anything may modify anything I suspect the result will be people won't follow it. But for partial locks, if interface models differently, it can be very expensive to implement. Checking partial locks across management interfaces will be difficult - how likely will this implemented correctly? Sharon: I think what we are talking about are fundamental requirements. This is a perfectly reasonable requirement to CLI that it respects partiall locks and we definitely keep those. Balazs: There are two levels of support for partial locking that we might require form CLI or SNMP. We require them as written that they must not modify stuff. We don't require them to do themselves partial locking. Wes: People did not follow the atomic set model because it was expensive. David P: A lot of people do SNMP atomic sets correctly. David P: This is an optional thing, it's a capability. If you choose to implement it it's gonna cost something. I think that we absolutely should do that. Bert: I suggest you go ahead what your plan was to do that other protocols need to honor the lock. For now, we keep the proposed resolution. WGLC might bring some comments, we'll deal with them as we see them. Keep also the empty locks as it is in the document. Bert: Is the document ready for WG last call? 8 in favor, no objections, plan for WGLC in August. NETCONF over TLS (Mohamad Badra) Slides: http://www3.ietf.org/proceedings/08jul/slides/netconf-2.ppt Mohamad Badra presents the TLS transport draft Security AD Tim Polk: In general we don't have any big problem using TLS as the security transport. Given the set of password based security transports already available for NETCONF, we don't understand what the TLS version is adding to the mix for NETCONF. Tim Polk: We see if you are using certificate-based mutual authentication this is something new and really important that you'd be able to do for NETCONF over TLS that's something really not have elsewhere. We understand why you do the non-standard handling of passwords, it is not clear what the actual value is given the fact that you can't use off the shelf TLS implementations anymore. Tim Polk: Are you simply adding confusion by adding another password based transport? We like the certificate based authentication. Tim Polk: To what extend is this aligned to the SYSLOG of TLS approach? Tim Polk: Using TLS as much as possible out of the box might has the most value. Bert: What value does TLS add as a transport? A number of people in Vancouver who actually supported, that this was a good addition. There are aparently environments where people have TLS in there systems and may not have, you know, some of the other protocols. Tim Polk: For those environments that have certificates deployed, a certificate based TLS transport makes sense. Badra: I am simply generating a pre-shared key PSK. Tim Polk: This is just early feedback from a quick review of the specs, the text probably is not clear enough yet. AD Dan Romascanu: Is there a TLS expert available to look at this document? Tim Polk: SSH already provides a good password-based secure transport, so it is not clear which value proposition password-based TLS has. We do not see something inherently broken so far from a high level review. Sec AD Pasi Eronen is likely to make more comments in the future. What is the motivation for doing this? Dave: Sees value in TLS. Once there is access control in NETCONF, we might need an authenticated user identity. Jürgen: Distinguish between cert-based TLS and password-based TLS in a WG last call. => Badra to take the comments of security ADs, perhaps more focus on certificate based authentication, check with the WG. NETCONF Notification Content (Sharon Chisholm) Slides: http://www3.ietf.org/proceedings/08jul/slides/netconf-4.ppt Sharon presents notification content slides Issue #1: configuration change events Issue #2: software change indication Sharon: Add this work to the charter as standards-track document? Mehmet: Why is this standards track document? Does it have to be? Sharon: We typically put MIB modules on standards track; this is similar Dan: I don't think we have something in the charter to cover this work. Bert: How is interest of doing some work on minimal notification content? 7-8 in favor, no objections Dan: I believe we need a recharter for this. It is adding extra functionality beyond the config function that is the basis of the protocol. David P: I need to see the charter text before I can be in favor or against it. Bert: It looks like we cannot accept as WG item now. It looks as if the WG is willing to consider work on some notification content, but that we first need to agree on new charter text that clearly spells out what we will or will not include. => Chairs will put this up on the mailing list and ask whether there is support to start work on netconf content.