Netconf notifications

From EECS

This page serves as a notepad for the [NETCONF] working group of the IETF in order to collect motivations and requirements for NETCONF notifications. Send email to the NETCONF mailing list and the editor of this page to get it updated.

1 Motivations
2 Requirements
3 Pending
4 Contributors

[edit]

Motivations

The list of motivations below has been collected from various postings on the NETCONF mailing list. Being listed here does not mean there is WG concensus - it just means the editor believes he understood what the motivation is all about.

notify about configuration changes [BL]
notify about state changes caused by configuration changes [DP]
notify about device state changes and transient events to detect unexpected consequences of configuration changes [DP]
notify about device changes (e.g. card insertion/removal) [BL]
notify about delayed results of long running RPCs [BL]
notify about alarms that require operator attention [BL]

[edit]

Requirements

The list of requirements below has been collected from various postings on the NETCONF mailing list. Being listed here does not mean there is WG concensus - it just means the editor believes he understood what the requirement is all about.

solution should focus on notification support for configuration [AB]
solution should support structured hierarchical data [BL, SC]
solution should be able to carry configuration fragments [?]
solution should support a reasonable message size limit (syslog and SNMP are rather constrained in terms of message sizes) [BL]
solution should provide reliable delivery of notifications [BL]
solution should support preconfigured notification destinations [AB]
solution should support agent initiated connections [KW]
solution should provide a subscription mechanism [HT]
solution should support multiple subscriptions [RP]
solution should provide a filtering mechanism [HT]
solution should support notification names [BL]
solution should support notification timestamps [BL]
solution should support notification classes [SC]
solution should support notification info [BL]
solution should provide the ability to specify the content of notifications to ensure predictability [SC]
solution should send sufficient information in a notification so that it can be analyzed independent of the transport mechanism [AB]
solution should allow notifications to refer to prior configuration change RPCs
solution should not bind subscriptions to a connection [RP]
channels for configuration change notifications should share fate with a session that includes a configuration channel [DP]
solution should support replay of locally logged notifications [KW]
solution should support message chunking capability in cases channels carry mixed RPCs [KW]
solution should scale to 30.000-100.000 nodes which may emit notifications [BL]
solution should scale to order 30.000-100.000 nodes to send notifications [BL]