Subject: Session reuse

From: Balazs Lengyel <[email-masked]>
Date: Wed, 07 Jun 2006 16:40:41 +0200

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?
Balazs

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

---

From: Andy Bierman <[email-masked]>
Date: Wed, 07 Jun 2006 08:38:07 -0700

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

---

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 15 Jun 2006 09:56:27 -0400

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.

Sharon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Andy Bierman
Sent: Wednesday, June 07, 2006 11:38 AM
To: Balazs Lengyel
Cc: Netconf (E-mail)
Subject: Re: Session reuse

I wrote:

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.

Andy

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

---

From: Andy Bierman <[email-masked]>
Date: Thu, 15 Jun 2006 07:22:05 -0700

> introduction of new verbs. I think calling consensus on this issue is

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.

Andy

---

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 15 Jun 2006 12:38:06 -0400

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: [email-masked] [mailto:[email-masked]] 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

What is "this approach"?

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.

Andy

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Andy Bierman
> 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
> 
> 
> --

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 16 Jun 2006 15:56:07 +0200

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

--

---

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 19 Jun 2006 14:10:31 -0400

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

<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

---

From: Andy Bierman <[email-masked]>
Date: Mon, 19 Jun 2006 12:15:45 -0700

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

---

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 19 Jun 2006 16:09:10 -0400

<Andy>
</Andy>
Two points on that:

1) I need to store a copy of my desired notification subscription
anyways because if configuration  doesn't exist I need to create it.
2) I am likely to be asking for the same information from all of my
devices. If they are stored on the device I then need to change them on
all of the devices. Much more work have to update those and then worry
about whether some other fool has the subscription configuration locked
or will step on my changes later on.

<Andy>
  - It forces the NMS and agent to replicate filter expressions
    instead of allowing them to be shared across applications,
    sessions, or even subscriptions.
</Andy>
You can use named profiles if you want to.

Sharon

---

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 20 Jun 2006 07:35:14 -0400

hi

I was driving home last night thinking about how of all the notification
receiver applications I've worked on over the years only one attempted
to perform automatic notification subscription. In thinking about why
this was, aside from the complexity issue which I've already discussed,
there is the support issue. Not all devices supported the MIB in SNMP.
You could argue again that this was the complexity issue, but I think it
also goes to the fact when we delegate everything to the data model,
implementations have a difficult time figuring out which are the
important bits to support or else start to support a proprietary chunk
of data model which they think is better/simpler/cooler instead. I think
this deviation is more obvious with verbs, assuming of course we have a
finite number of them.

So, verbs signal that this 'thing' is important so you should support it
and support it exactly this way. It's good for interoperability. I am
hoping there are other ways to solve this as well, since I am sure there
will be key bits of data model we will want people to support.

Sharon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Chisholm, Sharon [CAR:ZZ00:EXCH]
Sent: Monday, June 19, 2006 4:09 PM
To: Netconf (E-mail)
Subject: RE: Verbs or data model [was: Session reuse]

<Andy>
    instead of having the option of storing it on the agent. </Andy> Two
points on that:

<Andy>

Sharon