IETF67 OPS-NM Area NETCONF WG November 6, 2006 Minutes by Andy Bierman Documents: A) draft-ietf-netconf-notification-04.txt Minutes: 1) WG Status The base NETCONF documents are in auth48 state and will be published soon. The document numbers are RFC 4741 - RFC 4744. The WG is trying to finish the Notifications draft and get to WGLC before the next IETF. Straw poll: How many people have read the Notifications draft? A: Over half the approx. 40 participants present. 2) Notification Issues The remainder of the meeting was spent discussing technical issues related to the Notifications draft. Simon started with an issues list. (See slides.) This section has been organized by issue, not temporal order. Before the technical issues were addressed, Simon pointed out that we need more participation in the form of document reviews, in order to complete the Notifications work. It was suggested that we try to simplify the document as much as possible, in order to finish sooner. Additional features can be added in the future, as needed. 2.1) StreamList Design The group discussed the StreamsList construct introduced in the -04 draft. This is a list of 1 to N stream names that should be combined by the agent to produce the notification output for a particular session. cardinality of streams in Balasz: we don't specify anything about event streams Balasz: default NETCONF stream Could we specify that this contains all notifications understandable in a NETCONF format? [see later discussion] DaveH: We should not assume that an agent can multiplex several notification streams together Eliot: Only way out is to mandate that multiple streams belong to the same XSD to be multiplexed Pros: - increases configuration flexibility for the manager - reduces the TCP connection and NETCONF session overhead if multiple streams are desired, and cannot be configured on the agent. Cons: - Streams can have different data formats, and some combinations may not make sense, or the agent may not be capable of combining them (i.e., the reason streams exist in the first place.) - There is no simple way for the manager to know which combinations are permitted - The agent can have configured streams, but there is no standard data model for this purpose yet. - The same system event can be conveyed in different ways, across multiple streams. Manager-selected combinations of streams would either create duplicate notifications or require complex duplicate suppression - The manager can simply open another session to receive multiple non-configurable streams. * Straw poll Q: Should the streams list be changed to a single stream? A: ACCEPT: Remove streamList and use a single Stream name instead Rough consensus for limiting ourselves to a single event stream 2.2) RPC - different ways to configure the same thing (profiles and filters) - Balayz: want choice of filter or profile but not both - combining filters and profiles - don't need this feature - change to choice (1 or the other) - Stopping the notification stream "mechanisms outside the scope of this document" DaveH: This seems to add ambiguity - remove that phrase! No objections to removing it. - remove statement about kill session outside the scope 2.3) Normative References - lot of data modeling : creates a normative reference - using template and minAccess/maxAccess - Remove normative reference to Datamodel draft 2.4) Notification Replay - no tail -f mode This removes a gap between the recorded and the new notifications that may occur during the . The design in the current draft could be achieved with the operation and a notification monitoring data model. James Balestriere: The client can just try: w/stream, start- and end-time Server can return an error if this replay is not supported. - Should replay be a capability in the hello message or a characteristic of each stream? - not needed; just get an error back - could have field in the getStreams to indicate logging is available A: Should not be a capability because it may not apply to every stream. Use an indicator in the data model instead (such as ). Should a stopTime be supported? A: Yes. Add stopTime (not just startTime) - Is endOfReplay notification needed James: This can also be necessary when stop-time is specified - take to list - When a replay ends, what happens? - Does the session end or what? - take to list - What happens if an RPC command is received during a notification stream? Does the agent have to respond to it? - take to list; interim discussion determined the agent does not have to respond to any requests after . 2.5) Monitoring Data Model - a general session monitoring module might be more useful - BW: can we move this to another document? - Straw poll: ACCEPT: Move monitoring data model work out of this document. It will not be part of the '1.0' standardization effort for NETCONF Notifications. 2.6) Transport Mappings - Transport mappings == keep text in this document - SSH talks about RPC in the document. - BW: Don't put any text we don't need like about SSH - BEEP (Eliot to provide text) - SOAP (any volunteers) - DH: remove the transport mappings from the document - DH: notifications over SSH may require new text ISMS has VACM to deal with JS: not a security problem in NETCONF because the receiver establishes the notification channel Andy: should say as little as possible about specific transports In particular, the examples should go away. Eliot: This creates a nightmare. Should be specified *in* the notifications document. !! Action on Eliot to help with the BEEP section [document] ?? Who could do the SOAP mapping?? SSH mapping seems easy (but at present always talks about "RPCs") Bert: May be an issue if/when transports get deprecated DaveH: Wants transports split off from this document. Suggests there will be issues with SSH transport as seen in ISMS Eliot: Those issues seems to be specific to SNMP's (access control) DaveH: At least have to provide a mapping from transport to principal ID to be used for access control DavidP channeling Juergen Schoenwaelder: Doesn't see the issue Wes: Seem to be side-tracking here Rough consensus to separate them out (Eliot opposed) - Straw Poll: ACCEPT: Move transport mappings out of this document - The Notifications draft will be written such that it does not block on any external reference that does not currently exist. This includes extensions to the SOAP transport for notification support. 2.7) Security Considerations - Security considerations: point out the base protocol covers the threats we have. Identity will be different for notification vs. get. What has to go in this section? DaveH: Security ADs will look for threats and ways that these are addressed/mitigated. Wes: Haven't read the document yet. Two comments: Some people want different AC for notifications vs. monitoring (), like it's done in SNMP VACM Dan: This needs to be run by security advisor (Wes) or by the SAAG before submission Effect of notification traffic (DoS?) 2.8) Default NETCONF Stream The purpose and expected implementation requirements of the default stream were discussed. - Does it have the NETCONF content, or all content? A: Streams are coupled to content: not needed because namespace URI identifies the content - okay if content is unspecified - STRAW POLL: Should the Netconf stream be the default for the parameter? A: YES - STRAW POLL: What should the content on this stream be? - outside this doc - anything in netconf format - only the netconf specific notifications A: --> define the content in this document A: --> SHOULD BE ALL NETCONF CONTENT 2.9) Readability Andy: Need more explanatory text around the schema definitions - increase documentation about data models, not just inside the XSD