IETF69 OPS-NM Area NETCONF WG July 24, 2007 Minutes by Andy Bierman from notes by Andy Bierman and David Partain Documents: A) draft-ietf-netconf-notification-08.txt Slides: a) http://www3.ietf.org/proceedings/07jul/slides/netconf-0.pdf Minutes: 1) WG Status The WG is trying to finish the Notifications draft and resolve all open issues identified in the recent WG Last Call. The NEE and XSDMI BoFs were held later in the week, which discussed NETCONF protocol extensions and standards for translating SMIv2 to XSD. Two open, ad-hoc meetings related to the document were held during the week. One was on issues related to notification replay, and the other was a document edit issues meeting. 2) Notification Issues 2.1) Schedule This work should be finished already, but we're Real Close Now. The final WG approved draft was supposed to be forwarded to the IESG in December 2006. Goal is to have the document ready for final WGLC by the end of this week. (Yeah right!) The real goal is to have the notification-09 draft published by Sept. 7, 2007. This draft is believed to resolve all known issues. 2.2) Requirements vs. Motivations The group decided to rewrite the Requirements bullet list (1.4) and move it to a Motivations section (1.2). Dan Romascanu volunteered to rewrite this text. 2.3) Capabilities: Extension vs. Restriction The group discussed the conceptual semantics of NETCONF capabilities, and how they inter-relate with each other. The following conclusions were reached. By design, these capabilities are independent of one another. Each capability represents a contract between the agent and the manager, for the functions (and parameters) the agent is going to support for some feature. A capability could identify a subset or even modify another capability, but the agent cannot advertise both of them at once. 2.4) Session Modes There is some concern with the different operational modes related to notification replay, that are indicated with the stopTime and startTime parameters for create-subscription. Some discussion: Sharon(?): We don't think the current text is clear, so this slide suggests text to clarify what should do it. This means that there must be a good reason to violate the recommendation, such as if both client and server understand that they are capable of interleaving. Simon: Some have said that we should develop the "interleaving capability" now, but we need to have text and it may not cause delay. If someone thinks they can do it, they need to do so now and send the text to the mailing list. Simon believes that the devil is in the details that would have to be worked out. Andy: What should happen if the create-subscription RPC keeps being called. Simon wonders if we should introduce the concept of "modes". Wes Hardaker: What problem are you trying to solve? Balazs Lengyel: Wants specific text on how long the client should not send additional RPCs. The group decided at the meeting (later revised): A client SHOULD NOT send requests while a notification subscripion is active, because the server MAY NOT process them. The agent must send notification in replay mode if active, before a manager can reliably send requests again. 2.5) Access to Stream Names Slide "Issue: Access to stream names ( on subtree)" Relegate access control to the security considerations section. WH has sent private mail with a suggestion for a security considerations section, and Simon will send a suggestion to the mailing list. Andy wants the access control to be stated straightforwardly that managers only get access to data for which they have access rights. Simon: Should this document make recommendations on these three documents? WH: Yes, you should say something. As long as you identify all the sensitive points and address them, you should be ok. Andy: could we do something like MIBs? WH: That's more operational guidance, not that VACM may not check access for those variables. The group decided not to specify how access control is performed, but the document will discuss the three operations where access control should be considered: - when the create-subscription operation is invoked - when the data is retrieved - then the element is generated 2.6) Clarifications Document consistency nits were discussed, and the new version will reflect consistent terminology usage and document conventions. Corrections and minor edits made on the mailing list will be considered by the co-authors for notification-09. 2.7) Applying Filters The usage of filters for notifications was discussed. Andy: Resolved one on the list - The text needs to say what it means to apply a filter. A filter means you send a notification, and no match means you drop it all. In addition , a notification filter will be applied to the contents of the element, not the document root, called the abstract notificationContent element in the XSD. These filters are not the same as or filters, which are applied to a specific configuration database. 3) Issue Tracker An issue tracker for the WG is overdue, and so David Partain and others have started an issue tracker for WG documents. Tracker WEB Page: http://www3.tools.ietf.org/wg/netconf/trac/report/1 Each document is represents a 'component' in the tracker system: - RFC4741 - RFC4742 - RFC4743 - RFC4744 - draft-ietf-netconf-notification Click on 'Get Passwd' in the upper left to get an account, then login and a tab called 'New Ticket' will be present. You do not need an account to see the 'View Reports' page. WG members are encouraged to enter review comments and bug reports directly into the issue tracker, instead of posting them on the WG mailing list. The tracker will generate an email. Followup comments may be made on the mailing list or entered into the issue tracker directly. When all the notification issues are closed, the document will be ready for submission to the IESG. Tickets entered against the published RFCs are for defects found in those RFCs, that need to be addressed in a future version of the document. 4) Open Issues The WG is busy resolving the final details with the notification design and document clarity. The inter-leaving of new RPC operations after notification delivery is the last open issue, and it is almost completely resolved. It is expected that the notification-09 draft will include new featured, discussed at the ad-hoc design meeting, which will provide an interoperable notification delivery mechanism, with some powerful replayed notification retrieval and filtering capabilities.