[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NETCONF Notifications: Consensus Points

Ted Goddard wrote:



On 25-Nov-05, at 11:32 AM, Andy Bierman wrote:


Feature Consistency at the Protocol Layer

 There is WG consensus that the protocol-level notification
 features must be consistent across the supported transports.
 However, there is not yet WG consensus that NETCONF over SOAP
 must be supported.  The discussions have focused on SSH and BEEP.
 Each time it is mentioned that SOAP/HTTP cannot support this
 feature, the issue is ignored.



Notifications for NETCONF over SOAP/HTTP could be implemented
using:

    1. Separate HTTP connections for NETCONF management and
       NETCONF notifications channels



You mean one session in each direction?
Both NC peers have to implement HTTP Server and Client SW
to have notifications in this case.


    2. HTTP response to a notification request delayed until
       notifications are available



Not sure what you mean here.
I think you mean the NMS continuously polls for notifications,
but the agent holds each response until there is a notification
to send (in order to minimize the polling overhead).

Won't this cause the connection to time out in the client,
and perhaps HTTP caches in between the manager and agent?
(I guess this can be avoided by using a different port number than 80.)



Ted.



Andy





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





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