Last Modified: 2005-01-21
Done | Working Group formed | |
Done | Submit initial Netconf Protocol draft | |
Done | Submit initial Netconf over (transport-TBD) draft | |
Done | Begin Working Group Last Call for the Netconf Protocol draft | |
Done | Begin Working Group Last Call for the Netconf over (transport-TBD) draft | |
Jan 05 | Submit final version of the Netconf Protocol draft to the IESG | |
Jan 05 | Submit final version of the Netconf over (transport-TBD) draft to the IESG |
NETCONF meeting IETF 62, Minneapolis Chairs: Andy Bierman, Simon Leinen WG Last Call statusAll 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.txtMargaret 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.txtEliot 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:
Discussion of XML and Schema Definition IssuesSchema Strictness RequirementsWes 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 ReviewBert 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.txtRob Enns decided not to show slides about the protocol draft because they are boring. Changes from last to current revision:
Work is required in the following areas:
Secure-Transport RequirementJohn 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 SessionsJohn 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.txtTed 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 NotificationsEliot 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 DiscussionSharon 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. NETMODPasses 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 RemarksDocument 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. |