high-level summary of today's discussions

[Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>]

Hi,

this afternoon, we went through the requirements list one by one and
this is what we have produced:

   1. solution should focus on notification support for configuration [AB]

=> R1: required to identify configuration changes on a device

   2. solution should support structured hierarchical data [BL, SC]

=> not meaningful since we do not focus on the content of a notification

   3. solution should be able to carry configuration fragments [?]

=> not meaningful since we do not focus on the content of a notification

   4. solution should support a reasonable message size limit (syslog and 
      SNMP are rather constrained in terms of message sizes) [BL]

=> netconf does not impose message size constraints

   5. solution should provide reliable delivery of notifications [BL]

=> netconf does have a reliable transport which is good enough

   6. solution should support preconfigured notification destinations [AB]

=> nice to have feature if there is a solution - ISMS is investigating
   whether there is a solution for SSH (seems to be easy over BEEP)

=> this is just a notification specific instantiation of the call home
   feature (see below)

   7. solution should support agent initiated connections [KW]

=> this is a transport issue and as such must be handled outside the
   notification work

   8. solution should provide a subscription mechanism [HT]

=> subscription is vague - does it mean a subscription that is bound
   to the lifetime of a session or is it a more permanent subscription?

=> R2: an agent does not send notifications before asked to do so

=> R3: the manager initiates the flow of notifications

   9. solution should support multiple subscriptions [RP]

=> netconf supports multiple session which means that multiple
   subscription in separate different sessions is covered

=> multiple subscriptions over the same session are not required

  10. solution should provide a filtering mechanism [HT]

=> R4: yes

  11. solution should support notification names [BL]

=> notification names belong into the data content

=> R5: it is required to be able to filter on the data content

  12. solution should support notification timestamps [BL]

=> notification timestamps belong into the data content

  13. solution should support notification classes [SC]

=> notification classes belong into the data content

  14. solution should support notification info [BL]

=> notification info belong into the data content

  15. solution should provide the ability to specify the content of 
      notifications to ensure predictability [SC]

=> notifications should be formally defined, to be addressed by data
   modeling language efforts

  16. solution should send sufficient information in a notification so 
      that it can be analyzed independent of the transport mechanism [AB]

=> R6: data content fully describes a notification; protocol information
       is not needed to understand a notification

  17. solution should allow notifications to refer to prior configuration 
      change RPCs

=> belongs into the data content

  18. solution should not bind subscriptions to a connection [RP]

=> sounds a bit too complex - unclear what the real use case is

  19. channels for configuration change notifications should share fate 
      with a session that includes a configuration channel [DP]

=> R7: sessions are independent

  20. solution should support replay of locally logged notifications [KW]

=> need to distinguish between retrieval of logged notifications and
   replay of notifications

=> might be a capability

=> R8: yes

  21. solution should support message chunking capability in cases 
      channels carry mixed RPCs [KW]

=> netconf does not interleave messages, no chunking/fragmentation needed

  22. solution should scale to 30.000-100.000 nodes which may emit
      notifications [BL]

=> the netconf transport has already been decided

  23. solution should scale to order 30.000-100.000 nodes to send
      notifications [BL] 

=> dropped

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>