Minutes of the Network Configuration WG Session at the IETF #73, Minneapolis, MN, USA MONDAY, November 17, 2008, 1740-1930 WG Chairs: Bert Wijnen Mehmet Ersue AD: Dan Romascanu Many Thanks to the minute takers: Simon Leinen, David Harrington and the jabber scribe: David Partain There were approx. 45 persons in the NETCONF session. WG status review has been given by Mehmet Ersue. Agenda and status slides: http://www3.ietf.org/proceedings/08nov/slides/netconf-6.ppt There were two last calls for the Partial Locking draft, pending some editorial changes. Can go to IESG? NETCONF over TLS in AD evaluation Last Call for netconf-monitoring will be done soon Not yet chartered: 4741bis: Martin Bjoerklund and Juergen Schoenwaelder have volunteered as editors with-defaults capability: Balasz Lengyel & Andy Bierman Notification content draft: Its focus and a possible charter update to be discussed in the session ---------------------------------------------------------------------- NETCONF Monitoring Schema (Mark Scott) draft-ietf-netconf-monitoring-schema-03 Slides: http://www3.ietf.org/proceedings/08nov/slides/netconf-7.ppt New version addresses action points from IETF 72 - clarified terminology - as well as incorporating many comments from mailing list Open issue: data types discussion is still ongoing, current I-D defines ipAddress and hostName Possible ways forward: A) delay work until netmod data type work completes - to align data types and to ensure the retrieval mechanism covers all netmod requirements (naming etc.) B) proceed with current definitions? Next steps: - review -03 (no feedback received so far) - continued discussion on data type issue. Bert Wijnen: Has been beating up on Mark to start offline discussion to come up with pros and cons of the various alternatives. Mark has taken some initiative, but otherwise there hasn't been much visible effort. We must have this discussion. Bert warns that it is not acceptable to just not react to calls for feedback. Mark's proposal for possible ways forward is an acceptable proposal. David Harrington has the impression that this discussion did happen. Mark agrees that the netconf-specific datatypes have been aligned with current netmod work on the mailing list. Bert asks Mark to document that discussion and its outcome and post that to the mailing list. David Harrington adds that the outcome was to not to try to do IETF-wide data types, only what's required for NETCONF. Balasz thinks there will have to be some small changes Juergen: The biggest issue is canonicalization of data types where multiple representations of a given value are allowed. Mark agrees. Martin Bjoerklund: What we publish now may be sufficient for monitoring, but not necessarily for configuration. Mark agrees. ipZddress in the draft is only used to identify connections. He could punt on this issue by changing to something like 'connectionId', but wanted to keep the address semantics. Martin: so the current scope may be even narrower than "netconf-specific". Bert: Should we defer generalization to netmod work? Mark: yes. All similar data type definition attempts would run into the same problem. Bert: We may need to add comment to all data models that they might change. Bert: Any objections? Consensus declared. ---------------------------------------------------------------------- Partial Lock RPC for NETCONF (Balazs Lengyel) draft-ietf-netconf-partial-lock-04 Slides: http://www3.ietf.org/proceedings/08nov/slides/netconf-1.ppt Got good comments from WGLC, mostly clarifications, improvements. Substantial changes: - added list of locked-nodes to the output of partial-lock to clarify what is actually locked as a result of somewhat complex XPath selection - allowed atomic locking (in one operation) of datastore parts in multiple datastores More recent comments from Phil Shafer, who cannot be in the session today. Editorial comments accepted, others need to be discussed with him. How should the YANG modules be named in the future? Should they have a prefix ietf-? Balasz thinks this should be just 'partial-locking'; everybody else can use prefix, ietf shouldn't need to. Proposal: Extend global operation rather than inventing new operation Balazs proposes to reject this: - global has some added semantics about locking candidate data stores that are undesirable here. Current xsd doesn't allow this. Semantics are different enough to warrant new operation name. - Should use new YANG "feature" construct to declare whether full XPath can be used, and which datastores(?) Balazs proposes to reject: avoid having many sub-features, existing "XPath" feature should cover this. Sharon Chisholm agrees with Balasz' proposed resolutions. David Harrington thinks having the 'ietf-' in front might be a good thing because other people might forget to put their enterprise name in front. Balasz doesn't have a strong opinion. We just need a decision. Bert argues on Dave H.'s side in order to avoid problems. Sharon: don't the YANG module have 'ietf' in their names by virtue of their URLs? Balasz: Only the namespace names, not the module names. Juergen also prefers to have the 'ietf-' prefix. Dan Romascanu asks why we have this discussion here. Balasz: This is because this is one of the first documents using YANG. Dan Romascanu suggests that the YANG documents should be enhanced to contain some guidance on this. Andy Bierman suggests to use the WG name rather than 'ietf-'. No support for this in the room. Show of hands about module name prefix issue: 18 in favor of the ietf- prefix, 3 for plain 'partial-locking'. Bert suggests a show of hands on who finds the remaining proposed resolutions acceptable. Upon Dave H.'s request, Balasz first explains the proposed (non-)changes in more detail. Discussion between Dave H., Balasz, and Martin Bjoerklund about the scope of the (full) XPath capability. Phil, channeled by Andy, channeled by David Partain: the current XPath capability only refers to and , nothing else! Bert: This looks like it needs more discussion. Balasz continues with another issue: the XML encoding of the request. Current proposal: can contain multiple elements. The alternative suggested by Phil: contains a single element, or a configuration store name as a string (could also be an enumeration of multiple targets?), and there can be multiple elements. Sharon and Dave H. express their preference for the first variant. Balasz has already sent a seven-page response to Phil's suggestions on the mailing list today. Bert: please jump in on the mailing list if you have issues with any of these proposals! would like to get this concluded soon, since we already had a Working Group Last Call. Andy clarifies that in terms of YANG, '(1) is an NP container of empty and (2) is a leaf-list of empty; don't care but (2) is more correct YANG' Balasz says that the current proposal (1) can also be specified in YANG - it already is specified in this way. ---------------------------------------------------------------------- NETCONF over TLS Document is in AD review by Dan. Mehmet will be shepherding this. Security ADs gave their feedback (Pasi Eronen). Multiple secdir members also reviewed the draft. AD Dan Romascanu understands that it isn't necessary to get additional security expert reviews. We should see this going to IETF last call shortly. ---------------------------------------------------------------------- Issues for 4741bis-draft - Martin Bjoerklund Slides: http://www3.ietf.org/proceedings/08nov/slides/netconf-3.pdf Martin and Juergen Schoenwaelder have kindly volunteered to work on this. Should just do bug fixes and clarifications. This is not supposed to be NETCONF V2.0. Issues based on implementation experience, mailing list feedback, and interoperability testing. Martin asks who implements inline configuration validation. Andy Bierman (via jabber) says he implements it, as operating on a complete configuration. Sharon asks why :startup and :candidate should be mutually exclusive? Martin thinks they shouldn't, but some people argue that they shouldn't be allowed together. Bert reminds people that we don't have to resolve all these issues in this session; this is more to give an impression what the scope of this 4741bis work is. Bert: Do you have a timeline for the doument? Martin: No we have not addressed timeline yet. Just collecting issues. Mehmet: For a charter update we need a timeline for the document development though. We need to define a timeline next week. Sharon reminds people that at some point, the transport mapping documents will have to be edited to support notification transport. Dave Harrington asks how it would be possible to get a startup configuration that is different from any current configuration. Martin says that this is currently not possible; if desired, the text would have to be changed. Discussion about the issue that the xsd disallows some extensions through optional capabilities. Sharon thinks such extensions would typically not be a problem in that they only add additional request attributes, and cannot in the server returning content that could be unexpected by the client. Andy: the XML preamble is not optional. don't break rfc4741-compliant clients that expect it. [name inaudible]: also recommends to leave the header mandatory, because it also specified the encoding. Missing encoding information is a frequent source of interoperability problems. Dan Romascanu: Is your list of issues somehow sorted? Martin: No, just compiled a list of issues. Need feedback. Dan Romascanu: You said this is not NETCONF 2.0 (more like NETCONF 1.1), so only bug fixes and clarifications. But during the presentation I had the feeling that it may not be possible to ensure backwards compatibility in all cases, viz. the handling of the startup configuration(?). Martin: This is something to have to look into: For each change, how will it affect clients, is it necessary to introduce new capabilities? Juergen via jabber: Implementations currently behave differently, and the goal is to define what the desired behavior is. Dave Harrington: Have you considered taking this to draft standard? That would actually allow you to no longer be completely backward compatible. Martin: That would depend on what the working group wants. Dave Harrington: Has anything been published on the interoperability testing? Martin: Juergen is preparing something. Bert: Thanks Martin for compiling this list. We'll come back to this in the charter discussion later on. ---------------------------------------------------------------------- 'with-defaults' capability for NETCONF - Balasz Lengyel, work with Andy Bierman Slides: http://www3.ietf.org/proceedings/08nov/slides/netconf-4.ppt Motivated mostly by netmod discussions. Questions: - Is this important? - Should this be a wg item? - Can this be solved? Sharon thinks this is a really important problem to solve, have spent a lot of time in their organization thinking about this. Mostly following the CLI. Default values come in different forms, not all of which easily specifiable in a data model. Sometimes defaults depend on the specific device, or even the specific software release. Sharon: It is important to distinguish between values set explicitly to the same as the default, and values left at the default. Balasz agrees, but notes that some devices cannot easily represent it in their current configuration model. David Partain: Yes, this is important, yes, this is the right place to handle this. Two separate shows of hands confirm that (1) there is wide consensus in the room that this is an important issue: a lot of hands (2) that such work should be done within this WG: 21 hands Bert: Do you have any doubts that it can be solved? Balasz: No, and I think my draft goes a long way to solving it. Lada: Specify, can it be solved in a way that satisfies everybody? Bert: It should be possible to achieve rough consensus - there can still be non-interoperable implementations. ---------------------------------------------------------------------- NETCONF Notification Content - Bert Wijnen Slides: http://www3.ietf.org/proceedings/08nov/slides/netconf-5.ppt Bert: The feeling the WG chairs got from last ietf meeting: We do not want to define extensive notification content now. Only content for such notifications that we need in the short time, in particular related to the NETCONF protocol. Other notification content can be defined once netmod comes up with usable mechanisms for doing so. Sharon: The document has two parts. One is about notification 'headers'. The other is specific types of notifications. We probably want to have those headers defined soon. Bert: It seems reasonable to stick to as little content as we can get away with. Sharon: We can provisionally use plain english to describe this information. By the time we will get done, netmod/YANG may be in a mature enough state to use it. Bert: Note that this is work that still has to be chartered. Show of hands who agrees with bert's assessment of priorities. Nine agree, [discussion before the 'disagree' position could be tallied] Dave Harrington: Use a standard language to define notifications now, then move to yang once it is ready. You could do syslog notifications now. It will be difficult to limit yourself to the 'essential' notifications. Andy prefers to wait for netmod to be done before worrying about this. Sharon: The current document defines a few fields, it uses XML Schema because that's available. Doesn't mind moving to YANG. There are many people defining notification content now, and they don't use a standard header. Lada: It is ok to use any existing specification language such as XML Schema or RelaxNG to define the basic XML 'blob' for notifications. Bert: If we can limit ourselves to one or two notifications, then that would be no problem. David Partain: We can use multiple specification languages for notifications, one normative and one not. Then when netmod is done, can reconsider what to do about YANG specification of these notification types. Dan Romascanu: What does 'wait for netmod' mean? Bert: Should be done by september 2009 officially. But I have been in the IETF long enough to not count on that. That's why we should limit ourself to a minimal set of notifications. We can use XSD or whatever. I'm not in favor of 'let's wait for netmod'. Dan Romascanu: Window of opportunity is closing, but still there. Bert: As WG co-chair, wants a good feeling about feasibility before chartering this work. Balasz: We don't need to wait for a complete YANG draft before starting with this. Lada: YANG would be ideal for this, but XSD Or RelaxNG seem sufficient, and they are unlikely to change soon. Bert: A snapshot of YANG could be used, and XSD or RelaxNG generated from that. The question is what should be normative. David Partain takes issue with the notion that YANG is a moving target that cannot be relied upon. It is actually quite usable now. Bert: And in case there are changes, we can still declare the XSD as normative. David Harrington: Co-chairs both netmod and syslog. A year ago we had a syslog model draft and thought it was stable. Took a year to go through IESG review. IESG review can greatly change what a specification looks like. Show of hands who agrees with Bert's assessment of priorities. After discussion, no objections. Bert: Consensus call on urgent now - 20 for; 0 disagree ---------------------------------------------------------------------- WG Charter Updates 1/3 4741bis as presented by Martin - bug fixes, clarifications, NO EXTENSIONS (not doing netconf V2.0) - show of hands shows wide support and no objections. Dan Romascanu asks about backward compatibility requirements Juergen: We need to fix contradictions, this will make some existing implementations non-compliant. Andy prefers a 1.1 that is not necessarily backward compatible. What value is a new rfc with just bug fixes? Not worth the effort. ???Show of hands shows wide support and no objections. 2/3 "with-defaults capability" as presented by Balasz and Andy Bert's suggestion: - small stand-alone document - use draft-bierman-netconf-with-defaults-01.txt as base for a WG document Show of hands shows wide support and no objections to do the work wiht a stand-alone document Consensus: Should this work be based on draft-bierman-netconf-with-defaults as a base? 16 in favor, 2 against 3/3 Notification content (very limited set of content) Bert's suggestion: - Draft-chisholm-netconf-not-content-00.txt cannot be used as a base. - To start from because it is too extensive. Cutting stuff out requires too many cycles. Prefer new document and editors can cut-and-paste from Sharon's document as desired. - We need volunteers for writing an initial draft. It should be clear to those volunteers that we would like this done within, say, six months. Sharon finds it too strong to say that draft-chisholm cannot be base. Bert has no problems if the new -00 document copies selected content from draft-chisholm-netconf-not-content-00. Sharon: Surgery of the existing document to fit the new requirements shouldn't be a problem, and I would volunteer to help with this. ---------------------------------------------------------------------- Bert & Mehmet thank everybody and close the meeting.