hi
Well, I would say it isn't a gating problem, because people can choose
to use separate sessions if they think the command will take a long
time. It's a reasonable workaround since I don't think configuration
connections would be as long lived.
The problem could be solved via some sort of fragmentation mechanism for
large commands, but I don't think we need it yet. Retrieving active
alarm list is an interesting case where you would want them to be on the
session, but we have an event-replay mechanism where this isn't a
problem.
If resources are tight and they really only want one connection, then
multiple channel support seems to be the better solution.
Sharon
-----Original Message-----
From: Balazs Lengyel [mailto:balazs.lengyel@ericsson.com]
Sent: Friday, March 17, 2006 10:54 AM
To: Chisholm, Sharon [CAR:ZZ00:EXCH]
Subject: Re: Informal Issue summary for Netconf Notification
Sharon,
Someone voiced the concern that if we have only a single channel and use
the same Netconf
connection for both configuration and notifications then a big response
to a <get>
operation might block notifications for considerable time.
What is the solution?
- You don't think this is a problem
- it is recommended to use separate Netconf connections
- multi-channel
- the problem is not a real problem because ???
- else
regards Balazs
Sharon Chisholm wrote:
3) Multiple-channel support: seem to have consensus to defer
> Sharon Chisholm
Nortel
Ottawa, Ontario
Canada
--
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/>