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

Verbs or data model [was: Session reuse]

Hello,
I am definitely no expert in the Web services field but as I understand: connections and notification sessions change in WS quite frequently which might suite the subscription model more. However in network management most of the time you are interested in the same set of notifications all the time or repeatedly. More static "subscription information" is better handled with a data based model.
IMHO WS speaks about many or multiple subscribers to each notification source while in Netconf the number of interested parties for a given set of notifications is often just one.
In case of TMF MTOSI the use of CORBA might have provided the designers of the system with a well established subscribe-notify mechanism. If you know about other reasons please share them? 


Sharon what would be the reason for selecting verbs instead of data model. As I see it:

Pro Verbs:
- some people feel verbs are more understandable
- else ???

Pro Data Model:
- some people feel if the whole of netconf is based on the idea of reading and writing configuration data we should use our own mechanisms - it lets short "mixed session type" notification sessions and call-home type sessions work together more easily. They can use a common data model and a single mechanism instead of in-line filter definition for subscriptions and stored filters for call-home. - it is inefficient to require the notification generation and filtering parameters to be passed to the agent every time 
- filters might be reused between sessions and different notification receivers

Sharon please extend my list so we can collect pro and con arguments.
Balazs

Sharon Chisholm wrote:

hi

Another data point is that other popular XML-based network management
solutions in the industry have also chosen to use subscribe and
unsubscribe verbs
	- TMF MTOSI
	- WS-based Notifications

Sharon

-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
Behalf Of Andy Bierman
Sent: Thursday, June 15, 2006 10:22 AM
To: Chisholm, Sharon [CAR:ZZ00:EXCH]
Cc: Netconf (E-mail)
Subject: Re: Session reuse


Sharon Chisholm wrote:

hi
But there have also been a number of people who disagreed with this approach as making netconf unusable and supported intelligent introduction of new verbs. I think calling consensus on this issue is premature. 

What is "this approach"?

There isn't any consensus that the new verbs proposed
in the draft are appropriate.

Several people have mentioned that it is inefficient
to require the notification generation and filtering
parameters to be passed to the agent every time a new
session starts.  There have also been strong objections
to multiple mechanisms (filter + profile) to convey
the configuration parameters.  Netconf already has
a model and mechanisms for manipulating NV-stored configuration, which
cannot be ignored or superseded.




Sharon


Andy


-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman 
Sent: Wednesday, June 07, 2006 11:38 AM
To: Balazs Lengyel
Cc: Netconf (E-mail)
Subject: Re: Session reuse


Balazs Lengyel wrote:

Hello Andy,
As I remember you mentioned you hoped to reach consensus on session reuse before the IETF meeting. Could you summarize how you see the 
state

of consensus?

I wrote:

   I was hoping we could finish up event classes before the meeting.
   The other issue that seems to be finishing up is the use of

existing

   configuration RPCs instead of new subscription RPCs for conveying
   notification generation parameters.


Not session reuse. RPC reuse.
I think there is WG consensus that notification generation parameters need to be capable of being NV-stored, and that existing RPCs for manipulating configuration data must be used for this purpose.
There have also been multiple objections to having overlapping subscription and configuration based mechanisms, so IMO there is also WG consensus to limit any new RPCs to new features which do not duplicate existing RPCs. 


Balazs


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





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


--

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