Subject: RE: comments on draft-ietf-netconf-notification-01.txt

From: "Hector Trevino \(htrevino\)" <[email-masked]>
Date: Wed, 3 May 2006 09:02:54 -0700

Thanks for sending comments. See some responses in-line
Hector

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Andy Bierman
> Sent: Tuesday, May 02, 2006 11:39 AM
> To: Netconf (E-mail)
> Subject: comments on draft-ietf-netconf-notification-01.txt
> 
> Hi,
> 
> This is not a full review.
> I'm still waiting for some WG members to do that.

HT: Could you please include the names of the reviewers so we get an
idea of what the various interested people are saying.

> 
> -----------------------
> 
> General comments:
> 
>   - The draft still lacks any discussion of why we need this
>     document, what role it plays in the overall netconf architecture.

HT: Ok. 
> 
>   - The use of special RPCs, named profiles, and a read-only 
> data model
>     goes against the core concept of netconf -- use the 
> standard operations
>     to manipulate standard read-write data models.  The 
> convoluted manner
>     in which a traditional notification generation 
> application would be
>     realized would win a Rube Goldberg Machine Contest.
> 
>     I strongly object to this design approach.

HT: The notification related RPCs give the user a convinient way to
request notification forwarding. While I agree that you could achieve
the same by using the NETCONF RPCs against a data model, such model does
not exist and there isn't much work in this area. Therefore, I don't see
how you can argue this point. 

The named profiles provide a way to pre-configure subcription
information. What is the objection to this? In previous e-mails I
thought you also suggested having "profiles" with pre-configured
destinations. The idea is to allow for read/write access to the
subscription information. 

> 
>   - multiple subscriptions per session
> 
>     I strongly object to this feature.
>     There is no rationale given for it.
>     Netconf has a single-user session model.
>     The NMS can use modify-subscription instead of creating multiple
>     subscriptions.  The NMS, not the agent, should provide this
>     additional, programmable classification service.  The complexity
>     added to the document to move this classification service to
>     the agent is unwarranted, and the feature is totally redundant.
> 
>   - Event classes
> 
>     I strongly object to this document defining the mandatory set of
>     event classifications.  This document should simply define a
>     field that contains a constrained string, which can be used for
>     filtering purposes.  The list still contains enumerations such as
>     'metrics' and 'heartbeat' which were supposed to be removed.
>     There are under-specified semantics and requirements for many
>     of these classifications.
> 
>     The actual set of standard events is a modeling problem, and is
>     out of scope in this WG.

HT: I thought we had agreed to at least config change and syslog. 
> 
> --------------------------------------
> 
> page 4:
> 
>    "discusses implications for the mapping of application protocols"
> 
> 
> Is this document doing to define the normative procedures for 
> supporting notifications on each transport?  I think this 
> would be better than generating 4 RFCs instead of 1, but the 
> WG needs to decide where the normative transport-specific 
> text will be located.

HT: Ok 
> 
> ----------------
> 
> page 4:
> 
> NETCONF[NETCONF] --> NETCONF [NETCONF-PROTO]

HT: OK
> 
> ---------------
> 
> sec. 2:
> 
> There are no examples shown for each RPC operation.
> There should be examples here instead of spread out in the 
> end of the document.

HT: OK
> 
> ----------------
> 
> page 6:
> 
> <create-subscription>
> 
> "This command .."
> 
> Wrong terminology.
> Use RPC method or operation.

HT: OK
> 
> -----------------
> 
> page 6:
> 
> <named-profile>
> 
> This is still an opaque, under-specified proprietary hack.
> There should be a read-write standard data model with 
> standard parameters -- and nothing else.
> 
> I strongly object to this parameter.
> If vendors want to ignore the standard parameters and use 
> their own instead, then XML already allows them to do that -- 
> we should not help them hack around the standard within the 
> standard itself.
> 
> ----------------
> 
> 
> <notification>
> 
> Positive Response: no response, etc.
> 
> This only applies to RPCs, so it can be removed here.

HT: Ok  
> 
> ------------------
> 
> notification examples in section 5:
> 
> It should be made clear they are only examples and are not 
> normative.  The examples need to be explained as well.
> 
> These examples are unrealistic.
> I don't think it's proper for the agent to return a copy of 
> all the config that actually changed in a 'config-change' 
> notification.
> This could be really verbose, introduce access control 
> problems, and it's not really needed anyway, if the NMS is 
> designed correctly.

HT: OK, will update description. Regarding you second part of the
comment... the definition of a config change
notification allows for the inclusion (or not) of the changes that took
place. Depending on the managed device, this is actually a
desired/useful behavior. In some cases the device will send a change
notification with an ID & the management station may retrieve the
associated information. In other cases, the device will send all the
changes in a notification. I disagree the examples are unrealistic. 
I think the comment on access control is too generic & this may or may
not be true depending on the deployment. 

> 
> ------------------
> 
> schema comments
> 
> - an unspecified access control model is thrown in
>    with these 'minAccess' and 'maxAccess' <appinfo> additions.
>    There is no agreement in the WG on these XSD extensions,
>    or understanding of the functional requirements.
> 
> -----------------
> 
> filter example comments
> 
> Sec 6.2 introduces additional 'severity=foo' filtering syntax 
> without really explaining it.

HT: OK, will add explanatory text
> 
> Not sure what this <neb> element is in the example.

HT: It's just a tag to represent the top of a model that doesn't exist.
Same as top in the NETCONF examples. Will clarify. 
> 
> <netconf:filter> is broken XML -- there is no 'netconf' 
> prefix or an xmlns declared in the example.

HT: No, it's not broken XML. It is correct based on the XSD that it was
generated against. Will update to make sure there is no
misunderstandings. 
> 
> 
> ------------------
> 
> section 7.1.1.1 session lifecycle
> 
> The WG did not discuss or approve any such feature.
> This watchdog-timer design doesn't work in a mixed-mode 
> session very well.  The netconf agent never abruptly 
> terminates a live session.  The lack of architecture 
> discussion in this document jumps out in this section.  There 
> is no mention of the agent constantly starting and tearing 
> down sessions anywhere else.
> 
> This section needs to be removed.

HT: Will look at text 

> 
> ------------------
> 
> Appendix A: Design Alternatives
> 
> A.1 Suspend and Resume
> 
> This section introduces even more complexity with new 
> <suspend-subscription> and <resume-subscription> RPCs.
> 
> I strongly object to all of these specialized RPCs.
> If we have a proper read-write data model, the standard 
> operations such as <edit-config> provide all the 
> configuration manipulation features we need.
> 
> The agent already has code to implement <edit-config>.
> All of these special RPCs which are used to avoid 
> <edit-config> add extra code and complexity to the agent.
> 
> --------------------
> 
> A.2 Lifecycle
> 
> This section is incorrect and needs to be removed.
> The NETCONF-PROT document already mandates certain 
> non-volatile storage requirements.  This section contradicts 
> that normative text.
> 
> ---------------------
> 
> Appendix B: Syslog within NETCONF events
> 
> events --> notifications
> 
> This section does dot clearly define how to encode the XML 
> PDU.  This should be a normative section (and fully
> specified) or removed from the document.
> 
> Notification forwarding options needs to be agreed upon by 
> the WG, and fully explained in a detailed architecture section.
> 
> There is no proxy in netconf, and I aim to keep it that way.

HT: Ok. So can we agree to make updates and move this section into the
main body 
> 
> ---------------------
> 
> Appendix C: Example Configuration Notifications
> 
> This section needs to be removed.
> If the WG can agree of fully-specified standard 
> notifications, then they will included in normative text.

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

--
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, 03 May 2006 09:44:25 -0700

> idea of what the various interested people are saying.

I wish I could, but this is a volunteer organization.
I have asked many people to do full reviews and to start
prototyping implementations.  I haven't received much
interest in either task.

> how you can argue this point. 

I don't see how you could argue
that we should ignore all the standard
operations we just created in NETCONF-PROT.
The proposed special RPCs don't exist anymore
than a standard data model for configuration notifications.
It's less work to define data models for use with the
netconf protocol than it is to redefine the netconf protocol
functionality.

> subscription information. 

There is a big difference between a standard data model
with a set of standard parameters, and a standard pointer
off to some proprietary data model.

> HT: I thought we had agreed to at least config change and syslog. 

There is interest in this type of content.
Not wide consensus on any particular type of content,
but these seem to keep coming up in examples.

> not be true depending on the deployment. 

It seems to be a TimeFilter mechanism
(get all config that changed since time T)
is more useful than including all the changed
config in a notification.

Which products do this with notifications today?  None, AFAIK.

> generated against. Will update to make sure there is no

You have the same <event> subtree listed 3 times in the
filter example.  I'm not sure this is legal.

> HT: Ok. So can we agree to make updates and move this section into the

No -- You can wait until the WG discusses it,
and if the WG wants it, it will move to a different section.

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 03 May 2006 19:03:58 +0200

We don't have a data model for notifications today, but sooner or later we will need to 
define some models. Why not start now? You already have a half data model in the 
notification draft.
Balazs

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 3 May 2006 21:03:01 +0200

On Wed, May 03, 2006 at 09:44:25AM -0700, Andy Bierman wrote:

> It's less work to define data models for use with the netconf
> protocol than it is to redefine the netconf protocol functionality.

I do not believe this to be true. Implementation wise, I actually do
not see much of a difference. My SNMP experience tells me that adding
new PDUs is actually not a big deal - implementing the semantics is
where you have to spend time. And having to check whether the data
elements you received make since is about the same work as checking
whether a PDU that you received makes sense.

<soap>
  Once upon a time, people believed that the addition of create/delete
  operations to SNMP would add a huge amount of complexity and so we
  got RowStatus which I assume every implementor who has gone through
  the 8K description clause has falled into deep love with.
</soap>

While I do not have a strong opinion, I do have a preference for a
_simple_ subscription mechanism as part of the protocol since I
believe having special verbs will make it more likely that management
apps get to actually use the feature. The argument is clearly on the
irrational side of things how I believe many human programmers work -
they usually tend prefer verbs over data structures and even purely
declarative approaches.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: Andy Bierman <[email-masked]>
Date: Wed, 03 May 2006 12:38:35 -0700

> they usually tend prefer verbs over data structures and even purely

There is always engineering trade-offs to consider.

I agree it will always be simpler on the NMS for
a particular task to use a specialized API that moves
complexity to the agent.  It is not simpler on the agent
to add new specialized code than it is to reuse existing code.

This approach doesn't scale well.
By the time you define 5 or 10 specialized RPCs for each
possible feature, you have 5000 special RPCs
and no reusable code.

We explicitly designed a protocol to provide
a small set of powerful standard operations which can
manipulate any arbitrary data model.
IMO, it is better to stick with this architecture
than ignore it and start on a path of specialized RPCs.

> /js

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 3 May 2006 22:13:20 +0200

> to add new specialized code than it is to reuse existing code.

I am not convinced that using a verb instead of a data model makes any
difference implementation wise on the agent. I accept that your
experience might be different from mine so we do not have to agree on
this.
 
> possible feature, you have 5000 special RPCs

My background is work on DISMAN MIBs and I can assure you that the
fact that we had to cast every disman operation into gets/sets on a
data model did not make things simpler. In fact, it requires some
engineering efforts to cast out verbs from many data models that can
be provided as a library to be used by applications. In some MIBs, I
started to write down procedures how the various knobs should be used
to implement a verb. Here is also a quote from RFC 3535:

   -  Several standardized MIB modules lack a description of high-level
      procedures.  It is often not obvious from reading the MIB modules
      how certain high-level tasks are accomplished, which leads to
      several different ways to achieve the same goal, which increases
      costs and hinders interoperability.

I also note that CLIs tend to have lots of verbs and even though you
might not like this approach, they have at least been successful.
Note that I am not arguing we should open up pandora's box and add
verbs for everything (e.g. "shutdown interface" vs. "set interface
status down"). But we should also not fall into the other extreme
where we strictly stick to a fixed set of verbs just for purity
reasons or not very detailed claims of "increased complexity".

> than ignore it and start on a path of specialized RPCs.

I thought we would have learned from SNMP's history and the success of
CLIs and that we would be a bit more flexible this time around and
take some of the irrational factors of humans also into account when
we design things.

Anyway, I think I stated my preference wrt. notification subscriptions
and if I am just a small minority who has some unusal implementation
experiences, I am fine to accept a more data driven approach (means I
will not object against it).

/js

---

From: "David T. Perkins" <[email-masked]>
Date: Wed, 3 May 2006 13:49:02 -0700 (PDT)

HI,

I really agree with Juergen on this issue.

One thing that I would like to remind the readers about is
the following about creates.....

Consider a create operation. In some cases, the instance
of the item being created has a semantic meaning and
in other cases the instance is arbitrary. In other management
protocols, a create operation returns the instance of
the item being created. In the SNMP protocol, since
the designers did not provide "reliability", the result
of an operation could be lost. If the operation was
"create", then an instance could be created, but lost
when the result message was lost. Thus, to add a
create operation, the SNMP protocol would have to be
made "reliable". This is much harder, given the
installed base, than just adding a new verb.

> will not object against it).
Regards,
/david t. perkins

---

From: Andy Bierman <[email-masked]>
Date: Wed, 03 May 2006 14:31:31 -0700

> reasons or not very detailed claims of "increased complexity".

Here is my concern.

We have zero standard data models now.
We have zero specialized RPCs now.

The notifications draft completely ignores all
of the write/save/reload operations in the protocol
and reinvents them with specialized RPCs instead.
Except they are under-specified and contradict
the protocol standard in some places (e.g., saying
NV-storage is optional).

I think a combined approach would be acceptable:

1) Define a data model for all the parameters that control/monitor
    the notification subscription, so that it can also be used by the
    agent without any manager subscription.  I.e., a table indexed by
    a name string containing one 'row' per parameter set.  A separate
    table for reusable filters is also needed.

    A notification target table is also needed which is completely
    independent of the session-subscription API.  Parameters such
    as the notification receiver address, user name, and user credentials
    need to be included to configure a traditional notification
    generation application.

2) Use standard operations such as <edit-config> to manipulate
    all notification parameters, even for changing profiles in use.
    <create-subscription> and all other special RPCs go away.

3) A new special RPC <start-notifications> is used
    for a manager to start receiving notifications.
    There is no subscription ID because there is only one
    stream of notifications on this session, which can be changed
    by editing the configuration.

    The <stop-notifications> RPC is used to tell the agent to
    cease notification generation for the session.

4) There is no real need for <suspend> and <resume> because
    the parameters passed in <start-notifications> are trivial.

5) mixed-mode vs. endless-RPC is very problematic.
    I could live with mixed-mode, but I don't want
    the WG coming back next year asking for a lot
    of complicated hacks to deal with the horrible
    operational characteristics of mixed-mode.
    The answer will be "don't mix operations and notifications
    if you are not prepared to deal with the delays or the lost
    notifications."

Andy

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 3 May 2006 19:53:32 -0400

Hi,
 
> they usually tend prefer verbs over data structures and even purely

I am not an operator, so I cannot really state what operators would
prefer.
I am not a Netconf implenentor, so I cannot discuss implementation
issues.
I do not know XML or XSD very well, so cannot discuss
language-specific tradeoffs.
But I've heard complaints about SNMP for 13+ years, so I know about
that.
And I've been programming even longer, so I know about that.

One operator complaint is the data-centric rather than a task-based
approach of SNMP. People don't think in terms of "how should I
manipulate data sets to cause a side-effect to occur?", they think in
terms of "what do I need to do" to accomplish a task.

Programming languages migrated from binary to assembly to procedural
to object oriented designs.
Andy often complained about the peek-poke nature of SNMP. I associate
that approach with assembly language and its limited set of operations
that allowed one to peek/poke memory locations and registers.

I think a verb-based approach is associated with the more advanced
procedural style. I am of the impression that operators would prefer
to move from the antiquated peek-poke method of SNMP to a task-based
procedural approach (verb-based), akin to that used by CLI. 

In a private email, somebody made this observation:
"In all my years of doing SNMP work, I never saw the
immediate uptake and commitment of real dollars to
an I-D, like I saw for netconf.  It's because dev-groups
all over were already migrating their CLI to XML, and all
doing it differently.  Netconf is all about CLI, not SNMP.
The SNMP people don't understand that yet. ;-)"

I think I understand that. If Netconf is all about CLI, then it
appears that support for a verb/task-based approach is called for,
rather than the data-centric peek-poke approach of SNMP.

Of course, with that decision comes the possibly-unconstrained growth
of verbs often found in CLIs.
But that's the price of progress, just as the unconstrained growth of
functions written in Fortran/Pascal/C/etc was the price one paid for
moving away from assembly language.

To be continued ...

dbh

---

From: Andy Bierman <[email-masked]>
Date: Wed, 03 May 2006 19:15:10 -0700

> Hi,

I don't understand why these comments were not
raised during the 4 years we were developing
a set of operations to manipulate XML data models.

Anyone who understands the power of arbitrarily
complex nested XML data knows that netconf is
quite a bit more powerful than SNMP + SMI.
It seems that some people want to give up on
data modeling before we even start.

Companies are implementing netconf because their
CLI is inappropriate for use as a programmatic API.
That doesn't mean they want to repeat all the
mistakes that were made in the CLI or SNMP.

Most of the features that have been declared so useful
by NMS developers on this list don't actually exist in
any NE products, because of the economics of SW engineering.
Mandating technology in an RFC isn't going change the
economics.

There is a big difference between an RPC like
<create-loopback-interface> (e.g., the agent picks the
interface instance identifier) which cannot be achieved any
other way, and RPCs that simply replicate the existing
functionality in the protocol for the perceived ease-of-use
by the NMS.

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 04 May 2006 09:35:55 +0200

For me one main point is that a subscription (a set of data about where and what 
notifications to send) is real data that we want to keep for some time maybe even for a 
long time.

For complex operations we might need additional verbs/operations, but the subscription 
data is not so complex.

For operations where the main/sole aim is to produce a side effect (e.g. restart the node 
or start ping/traceroute tests) verbs may make more sense, but here we want to store the 
subscription data as well.

While I agree that using set operations sometimes can be unnatural way of handling objects 
I believe this is not the case for operations.

regards Balazs

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 04 May 2006 09:42:48 +0200

Balazs Lengyel wrote:

> While I agree that using set operations sometimes can be unnatural way 
> of handling objects I believe this is not the case for operations.
I MEAN FOR NOTIFICATIONS

Balazs

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 4 May 2006 12:25:01 +0200

>    if you are not prepared to deal with the delays or the lost

We should not compromise for the sake of a compromise.

What I am interested in is to have an easy mechanism to request that
notifications are directed to a given session (by default 'this'
session if we allow mixed content) and to have that request bound to
the lifetime of the session. In other words, I am thinking of a
subscription which establishes operational state rather than a change
of the configuration of the device and hence <edit-config> might not
be the primitive of choice.

You are looking for ways to configure persistent notificiation
receivers and I agree that this is essentially a configuration change
and so <edit-config> seems to be the appropriate primitive to use.

I think the first decision to take is whether the WG wants to support
both, one, or none of the use cases.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 04 May 2006 12:59:33 +0200

Juergen Schoenwaelder wrote:
> both, one, or none of the use cases

I agree, and I don't think we should be too proscriptive with netconf
regarding new operations or anything else, except to say that if a
standard approach can be use it should be used as long as it isn't so
contorted as to end up with GET/SET for side effects, as Dave pointed out.

This having been said, perhaps there is a more general approach that we
should be considering than notifications, as to ephemeral state.

Eliot

---

From: Andy Bierman <[email-masked]>
Date: Thu, 04 May 2006 04:17:10 -0700

>> I think a combined approach would be acceptable:

I think what Balazs and I are saying is that special RPCs
are fine when they are not merely replicating the functionality
of the standard operations.

This subscription info is just config data.
If it wasn't, you couldn't represent it in
the read-only data model (as in the document).

Since you can easily represent it as config data,
and since this approach allows both agent initiated
and manager initiated sessions to share the same config,
the standard operations (not special RPCs)
are the most correct choice.

I think enough people have spoken up
that we can say there is interest in
both manager and agent initiated notifications.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 4 May 2006 14:23:29 +0200

> the read-only data model (as in the document).

For me, a subscription bound to the lifetime of a session just adds
operational state and does not constitute a configuration change of
the device. If I log into a CLI and I request the CLI to show log
messages in my ssh session, I do not really consider this to be a
configuration change activity.

> are the most correct choice.
 
In order to support dynamic subscriptions via <edit-config>, the data
model needs to provide appropriate 'short-cuts' in terms of special
values to point to a session rather than a target (or to a target
implicitely defined by a given existing session) and there must be
ways to distinguish between entries whose lifetime is bound to the
existence of something like a session and other permanent entries
and/or there need to be timers to help with garbage collection of
subscriptions of dead sessions. In other words, you have to add
features and some complexity to the data model to properly support
dynamic subscriptions if you go down the <edit-config> path and
consider a dynamic subscription to actually be a configuration change
of the device.

I simply find a <subscribe/> verb more natural for dynamic
subscriptions than doing a configuration change which has a limited
lifetime bound to some other operational state on the device, namely
the existance of the session.

/js

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 04 May 2006 14:38:44 +0200

If garbage collection is desirable it is anyway needed for the long term subscriptions.
You need a pointer to the session in the data structure as one target might have multiple 
sessions.

> configuration change activity.
Operational state could be part of the data model. Netconf-prot Section 1.3  title is 
Separation of Configuration and State Data. Also we need both dynamic and persistent 
subscriptions; we should have a common handling and persistent subscriptions are really data.

> consider a dynamic subscription to actually be a configuration change
Agree. This means two extra pieces of data for each subscription:
- related netconf session's sessionId
- garbage collection time or NIL

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Thu, 04 May 2006 06:21:50 -0700

> configuration change activity.

agreed; but the parameters used for filtering are
just config data.  There are valid use cases for
wanting to NV-store the filter data on the agent,
and wanting to share that config data amongst multiple sessions.

> the existance of the session.

My proposal uses a <subscribe> verb.
It just does it in a way that maximizes
the reusability of the data and the protocol,
instead of reinventing the protocol.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 04 May 2006 06:56:27 -0700

David B Harrington wrote:
>....

I'm confused.
What do you think <edit-config> <get-config> <commit> etc. are?
These are the standard verbs in netconf.

For the configuration components of notification generation,
we already have a set of verbs.

> rather than the data-centric peek-poke approach of SNMP.

I think clueful vendors will figure out that XML (not netconf)
allows them an opportunity to finally build the kind of
structure and metadata into their CLI tree they have wanted
for a long time.

Netconf provides the standard set of verbs on that XML config data.

> moving away from assembly language.

I know examples of SW that did not run amok
with specialized functions, and spent the extra effort to
keep code-size down, code consistency and reuse up.
This often happens in embedded NE development where the
hardware platform is resource limited and dictated in advance.

The mindset is that these NE devices are used for processing
packets, not XML documents.  IMO, embedded engineers will
never change -- their mission is to keep COGS costs down.
Adding hardware (such as memory) has to be cost-justified.
Moving lots of code from one cheap workstation to 1000's of
embedded agents is not usually done, for this very reason.

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 04 May 2006 12:47:48 +0200

In the current draft even short lived subscriptions (session based) can be queried 
(Section 3.2) so to me they seem to be data.

In Ericsson we need  persistent receivers. Imagine a management station that manages 5000 
  nodes. When the management station restarts it does not want to go and subscribe 5000 
times if this can be avoided.

On the other hand I don't see any reason not to support session based subscriptions either.

regards Balazs

---

From: Andy Bierman <[email-masked]>
Date: Fri, 05 May 2006 19:57:31 -0700

Balazs Lengyel wrote:
> In the current draft even short lived subscriptions (session based) can 
> be queried (Section 3.2) so to me they seem to be data.
> 
> In Ericsson we need  persistent receivers. Imagine a management station 
> that manages 5000  nodes. When the management station restarts it does 
> not want to go and subscribe 5000 times if this can be avoided.
> 

I agree.
I thought about this problem and punted (in my latest data
model email proposal).

The entire callhome feature needs to be independently specified
in full detail, for all 3 transports (if possible).  There are security
considerations, reason-for-connect, redundancy and failover,
capabilities format, and many other details to work out.
I think Eliot Lear is working with someone at Cisco on this problem.
It didn't just fall through the cracks.

> On the other hand I don't see any reason not to support session based 

I agree.
Let's make sure the agent reuses as much code as possible.
Notice I haven't complained about all the filtering the
agent has to do for a subscription?  The agent already
needs to have that code for <get-config> and <get>, so
this is total code reuse -- an excellent way to do filtering.

Andy