RE: Proposed text for Section 1.2 of the notifications draft

["Sharon Chisholm" <schishol@nortel.com>]

Hi

Looks good, except the third bullet.

    o  There will be a limit for the message size at a reasonable value
      (i.e., not too short) 

The intension was to ensure that there was either no limit or a
reasonably long limit. The working group went with no limit.

Sharon

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] 
Sent: Monday, July 30, 2007 8:08 AM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: Netconf (E-mail)
Subject: Proposed text for Section 1.2 of the notifications draft


Following the discussions in Chicago, here is my action item including
the proposed text of section 1.2 of the Notifications Draft. 

- Section 1.4 in draft-08 will disappear. 
- Proposed text for new Section 1.2

1.2 Motivation

   The motivation for this work is to enable the sending of asynchronous
   messages that are consistent with the data model (content) and
   security model used within a NETCONF implementation.

   The scope of the work aims meeting the following operational needs: 

   o  The initial release should ensure support for notifications in
support
      of configuration operations

   o  It should be possible to use the same data model for notifications
as 
      for configuration operations. 

   o  There will be a limit for the message size at a reasonable value
      (ie, not too short) 

   o  The notifications should be carried over a connection-oriented
delivery 
      mechanism

   o  A subscription mechanism for notifications should be provided.
This 
      takes into account that a NETCONF server does not send
notifications 
      before being asked to do so and that it is the NETCONF client who
      initiates the flow of notifications

   o  A filtering mechanism for sending notifications should be put in
place
      within the NETCONF server

   o  The information contained in a notification should be sufficient 
      so that it can be analyzed independent of the transport mechanism.

      In other words the data content fully describes a notification; 
      protocol information is not needed to understand a notification,

   o  The server should have the capability to replay locally logged 
      notifications

Let me know if this looks OK. 

Dan





















 

--
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/>