Re: Verbs or data model [was: Session reuse]

[Andy Bierman <ietf@andybierman.com>]

Sharon Chisholm wrote:
> hi
>
> We had another one of these lists goings at one point, but I'll add on
> to this one since I'm too lazy to dig it up ...
> <Balazs>
>
> Pro Verbs:
> - some people feel verbs are more understandable
> - else ???
> </Balazs>
>
> First, we are talking verbs for this particular case since I don't
> support the general idea that we want 345309840 different verbs. We have
> historically made a decision to create new netconf verbs when it made
> sense to do so and that is what I am suggesting we do now
>
> - Acts as a hindrance for people wishing to over-engineer the
> subscription data model
> - Acts as a hindrance for people wishing to over-engineer the
> subscription process
> - Notification subscription a common verb in other solutions
> - Allows for the Netconf client to be the authoritative source of the
> subscription
> - Simplifies housekeeping

Please explain in more detail.
How are these goals achieved with these new RPCs in question?


Some people (including myself) believe that passing all
of the notification delivery parameters each time the
session restarts is inefficient and bad SW design.
 - It also forces the manager to store all the parameters
   for every device, instead of giving them the option to
   use agent NV-stored data.
 - It forces all the NMS apps to share or duplicate this data,
   instead of having the option of storing it on the agent.
 - It forces the NMS and agent to replicate filter expressions
   instead of allowing them to be shared across applications,
   sessions, or even subscriptions.

I think a solution which does not allow for agent NV-stored
config for something this basic is deficient.  The netconf
solution for NV-stored config is <edit-config> + data model.
(+ <commit>, <discard-changes>, <copy-config(running, startup)>,
<lock>, <unlock>, etc.)

IMO, new RPCs which in any way are intended to manipulate
non-existent "pseudo data models", to avoid using all the
existing operations which support NV-stored data models,
is a poor design choice.


Andy



> <Balazs>
> 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
>
> </Balazs>
>
> Actually both regular notifications and the call home ones can share the
> same named profile if they choose to use it. I'm not sure I would expect
> these in the same box, but perhaps the same network.
>
> Sharon
>
> --
> 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/>