NETCONF meeting

IETF 62, Minneapolis
Tuesday 09.00-11.30 (actually 09.00-10.00)

Chairs: Andy Bierman, Simon Leinen
Minutes: Simon Leinen
Jabber scribe: Eliot Lear

WG Last Call status

All documents were in Working Group Last Call, lasting until Friday 18 March (the week after the meeting). As this was the second WG Last Call, participants didn't find too many problems with the drafts in this round. There have been comments from people trying to implement the protocol, which can be viewed as a good sign. The documents should be ripe for submission to the IESG soon. Discussion about individual drafts followed.

draft-ietf-netconf-ssh-03.txt

Margaret Wasserman, the editor, couldn't be at the meeting because of other conflicting IETF duties. The latest revision mainly removed the option of starting NETCONF from a normal shell session - it must now be started as a separate netconf SSH subsystem.

Wes Hardaker has thoroughly reviewed the draft and posted some issues to the mailing list. Margaret will address those issues in a forthcoming revision.

Simon Leinen had found a small bug in the examples, where the C: (client) and S: (server) headers were inverted. This should remind participants of the importance of reviewing the documents for these kinds of problems also.

draft-ietf-netconf-beep-03.txt

Eliot Lear mentions that Jürgen Schönwälder provided detailed comments on his BEEP mapping draft, and promised a new BEEP draft based on these. Required changes include:

• Adding some examples
• Adding some text on <hello>, which was missed due to draft skew between the core (-protocol) and -beep drafts
• Address an issue of Jürgen's on the SASL/TLS combination - after getting Jürgen to explain these in more detail
• Reconsider the "application protocol" terminology, which Jürgen dislikes. Eliot is looking for suggestions for better terms.
• Thorough review to make sure the BEEP mapping covers everything in the core protocol draft.

Discussion of XML and Schema Definition Issues

Schema Strictness Requirements

Wes asks whether the intent is that an implementor should be able to use the XSD definitions to do most of the validity checking of NETCONF requests.

Andy doubts that this is possible, in particular because XSDs cannot capture the variants related to capabilities.

XML Directorate Review

Bert Wijnen, our responsible Area Director, asked (over Jabber) whether the XML Directorate has been asked to reviewed the documents for correct XML usage.

Andy states that this has not yet been done, and noted that one of our authors (Phil Shafer) is on that directorate.

draft-ietf-netconf-prot-05.txt

Rob Enns decided not to show slides about the protocol draft because they are boring. Changes from last to current revision:

• The many requests for clarifications from the mailing list have been addressed.
• All of the closed issues that had come up in the WG Last Call have been addressed.
• The change log was simplified because it was getting too long.

Work is required in the following areas:

• Filtering (section 6) - Some people have asked to clarify the section that explains how filtering works. Rob would welcome contributions for improved text. Andy - who had written that section - suggests that examples would be particularily useful here, and offers Rob his help to make the text more understandable later this week.
• Examples in general - Past experience shows that implementors often use examples as a main guidance for implementations. Therefore, the examples should be given much care, in particular their correctness. Rob notes that all the examples in the protocol draft have been verified against the RelaxNG version of the NETCONF schema.
• Clarify error codes for lock operations - LOCK_FAILED should be used instead of IN_USE.

Secure-Transport Requirement

John Ng asked about the requirement for secure transports (section 2.2 in the protocol draft), in particular whether it would be possible to use something like unencrypted telnet in a "secure private network" environment, or in situations where cryptography cannot be used. Andy assumes that security experts would not let a NETCONF proposal pass without mandatory security. Bert notes that security is mandatory to implement, but not mandatory to use.

Detecting Dead Sessions

John Ng raises the issue of how an agent notices when a manager has gone away (so that locks can be released). Andy says this is currently indicated by loss of the underlying TCP connection. John points out that this fails to distinguish between a manager that has nothing to say and one that has silently gone away. Eliot expresses his hope that someone who is holding a lock wouldn't be idle [but does that really help here?]. Andy recalls that we had this discussion before and decided this was a non-problem - hung sessions can be broken using <kill-session>.

draft-ietf-netconf-soap-04.txt

Ted Goddard, the author, couldn't be at the meeting. He has prepared the current revision of the draft in the beginning of 2005 and explained the changes on the list.

Andy notes that it would be interesting to know which lower-layer mappings are actually supported by NETCONF implementors. Unfortunately we don't have any data on this.

"NETCONF 2.0"?

Since there were no further questions on the current drafts, Andy suggests to adjourn this part of the meeting to discuss data modeling issues. There have been discussions about "NETCONF 2.0" style work, but it would preferable to have specific drafts as a basis for discussion, rather than doing this "by committee" in rooms like this. Andy's suggestion was not followed, however:

Protocol Extensions such as Notifications

Eliot asks about the process for defining NETCONF extensions. A typical NETCONF extension - for instance, "notifications" - would require at least two drafts, one that defines the feature and others defining specific lower-layer mappings. Andy emphasizes that we should get over the current deadlock (with respect to notifications) that different lower layers suggest quite different approaches to an asynchronous "channel", and at least the SOAP one doesn't seem to support this at all. This looks like a tough decision - at one time we thought about only supporting notifications for specific underlying protocols (e.g. BEEP), but the WG had decided not to go down that path because of worries about fragmenting the protocol. It would be useful for someone to address this issue in a new draft.

Speaking for a group of NETCONF implementors, Jürgen Quittek relates that they feel the lack of notifications to be the most significant problem. They consider submitting a draft outlining possible methods to address notifications. The open question is whether to do them within or outside the NETCONF framework; that's probably the first decision to make.

Sharon Chisholm thinks that we now have a better idea on how notifications should be done than back when we decided to punt them for "NETCONF 1.0". It is important for people to document their approaches in drafts - ideally before the Paris meeting - so that we have a basis for discussion, rather than brainstorming here. A little discussion ensued between Andy's and Sharon's recollection of why notifications were postponed. Andy's view is that the driving factor was that participants felt they weren't worth the effort, and Sharon found that the reason was mainly tactical - to get the less contentious parts out first, although everybody eventually wanted notifications in NETCONF. Sharon doesn't think that we have thought about notifications enough to be able to say that they don't work on certain transports - she has seen proposals that have very little transport dependency.

Eliot tries to reformulate his question about the constraints for extensions and capabilities, again with notifications as the example. They could be implemented using another channel in both BEEP and SSH, but the current SSH mapping draft doesn't talk about the ability to use additional channels. Another approach would be to to notifications over a separate TCP connection - they could be encoded as a large RPC response that could be parsed in an intermediate ("streaming") fashion - this would work over all transports without modifications to the current mappings.

Remembering previous discussions about notifications, Andy talks about implementation difficulties with multiple channels, related to assumptions about locking. Multiple channels could solve the issue of mixing normal responses and asynchronous notifications, provided that there are separate code paths for those at each end. But at that point one could ask what this buys us that we cannot already do with SNMP traps [or notifications]? We didn't start out to replace SNMP notifications here - let's continue to use those until we figure NETCONF notifications out.

General NETCONF Scope Discussion

Sharon claims that notifications are just a subset of more general "asynchronous messaging" functionality for applications, many of which are related to configuration. Andy is worried about adding to the standard without clear requirements. Sharon points to a mailing list thread about such messages; "configuration change" notifications; and people looking at asynchronous messages from the monitoring perspective, as a mechanism for (performance) logging. To Andy, this sounds like reinventing IPFIX. Sending out accounting records is not a network configuration protocol's job. Sharon claims there are applications related to configuration, which will be shown in an upcoming draft.

Faye Li supports Sharon's point of view. For configuration, an audit trail must also be supported. Operators want to receive a record for every configuration change.

Dan Romascanu feels like a few years ago, when we were discussing whether to do configuration or a generic network management protocol. He disagrees with Sharon's and Faye's point of view. On the other hand, he thinks at one point we need a common framework for NETCONF and SNMP. Should check whether NETCONF plays nice with any security solutions that the ISMS WG might come up with.

Andy asks Sharon to issue a draft as a basis for discussion.

NETMOD

Passes to Sharon for her presentation on data modeling.

Discussion ended with the suggestion to produce drafts about data modeling before the Paris meeting, and discuss them there.

Closing Remarks

Document authors are expected to produce revised drafts, with the necessary modifications as discussed here, soon after the I-D queue opens up after the meeting.