Subject: [OPSAWG] darft agenda for opsawg

From: [email-masked] (Scott O. Bradner)
Date: Tue, 7 Jul 2009 20:31:15 -0400 (EDT)

I poseted a draft agenda for the opsawg session in Stockholm

please send the list any other suggestions

tnx

Scott

---

From: WashamFan <[email-masked]>
Date: Wed, 08 Jul 2009 11:21:36 +0800

Hi,

I want to ask for the time slot for lock-mib and snmp-lock
presentation. Is it OK?

draft lock-mib refers to http://tools.ietf.org/html/draft-meng-fan-lock-mib-01
draft snmp-lock refers to http://tools.ietf.org/html/draft-fan-meng-snmp-lock-00

washam

----- Original Message -----
From: [email-masked] (Scott O. Bradner)
Date: Wednesday, July 8, 2009 8:32 am
Subject: [OPSAWG] darft agenda for opsawg
To: [email-masked]

>  _______________________________________________
>  OPSAWG mailing list
>  [email-masked]
>  https://www.ietf.org/mailman/listinfo/opsawg
>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 08 Jul 2009 08:10:51 -0700

> draft snmp-lock refers to http://tools.ietf.org/html/draft-fan-meng-snmp-lock-00

only the -01 draft is relevant, right?

from lock-mib, sec. 4.1:

 This table exists on devices that can be managed and configured
   via SNMP, NETCONF, COPS-PR or any other protocols.

I think we should first agree on the need, and
then specification, of a multi-protocol
network management database architecture.
There isn't even agreement in the NETCONF WG
that the NETCONF database architecture includes
the new 'partial-lock' additions or not.

I do not agree there is any need for a standard MIB module
to lock all or part of a NETCONF database.  I do not
see any need for a multi-protocol NM database architecture
at this time, either. Use NETCONF to manage a NETCONF database.

> washam

Andy

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 08 Jul 2009 08:20:45 -0700

>>>>> On Wed, 08 Jul 2009 08:10:51 -0700, Andy Bierman <[email-masked]> said:

AB> I do not agree there is any need for a standard MIB module
AB> to lock all or part of a NETCONF database.

Andy, you can't have it both ways.  The netconf protocol says it gets to
lock everything else and it's hardly fair if the other protocols can't
lock data instrumented with netconf.

AB> I do not see any need for a multi-protocol NM database architecture
AB> at this time, either. Use NETCONF to manage a NETCONF database.

That's not how the real world works.  If netconf was only managing it's
database and it's data wasn't expect to affect real-world configuration
that a device is supposed to implement that'd be just dandy and netconf
could do it's own thing and insist no one else touch it's resources.
But the reality is that netconf, SNMP, COPS, CLI, CPANEL, HTTP, DHCP,
etc are all touching the same underlying configuration in a device.
They likely all need to lock the underlying data, regardless of how it's
represented in each protocol (a netconf datastore, a SNMP MIB, CLI deny/allow).
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Andy Bierman <[email-masked]>
Date: Wed, 08 Jul 2009 08:56:38 -0700

> represented in each protocol (a netconf datastore, a SNMP MIB, CLI deny/allow).

IMO, agent integration with other protocol access methods
are NETCONF implementation details at this time.

Right now, there isn't any standard content at all in NETCONF.
Nothing.  Not one little writable leaf.  I would much rather
that the IETF focus on that problem, rather than add more bells
and whistles to a protocol already brimming in chrome.

How about if NETCONF actually managed something first?

How does a SNMP/NETCONF database even work?
The naming is totally different.
The data structures are totally different.
The protocol operations are much different.
There are no RowStatus or StorageType objects in NETCONF.
There are protocol operations and the <startup> database instead.

NETCONF is like a shiny new bullet train,
going around and around on a test track.
We don't need to keep working on the engine.
We need real tracks, and stations, and passengers.

Andy

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 08 Jul 2009 09:15:26 -0700

>>>>> On Wed, 08 Jul 2009 08:56:38 -0700, Andy Bierman <[email-masked]> said:

AB> I would much rather that the IETF focus on that problem, rather than
AB> add more bells and whistles to a protocol already brimming in
AB> chrome.

I'd much rather that netconf was usable today too, but it's not yet.
You're right about that.

But the reality is that you can't control the market or desire space by
simply stating that nothing else should be worked on but netconf.  There
are lots of other work items in the IETF that have nothing to do with
netconf.  And there are lots of items in the same rough-area as netconf
that people want to work on because that's what they're getting paid to
do.  If those same resources can't be redirected to work on netconf
(because you have no control over them) then so be it.

I think I've told you in the past that I've tried to drum up more
support for netconf because I think it's a good solution (though I still
have issues with aspects of it; they're solvable).  There is, it turns
out, a *lot* of people out there that have no interest in it.  At least yet.

AB> How does a SNMP/NETCONF database even work?
AB> The naming is totally different.

You're lost in the details Andy.  The real issue is that when netconf is
used to edit a route or when SNMP or CLI or anything else is used to
edit a route it doesn't matter how the individual access protocol
implements the "database" or other layer on top of the internal routing
table, which I promise you is not in any sort of format but an internal
format, then it has to either do simultaneous edits or lock it.

You seem to think the picture will be like:

+---------+     +----------+     +----------+
| NETCONF | --> | database | --> | hardware |
+---------+     +----------+     +----------+
                  ^
                  |
                  |
                +----------+
                |   SNMP   |
                +----------+

But it's not like that at all and I'm rather amazed you'd even think
that way.

The paths are completely independent:

+---------+     +-----------------+     +-----------------+     +----------+
| NETCONF |     |    database     |     |       db        |     | hardware |
|         | --> |                 | --> | instrumentation | --> |          |
+---------+     +-----------------+     +-----------------+     +----------+
                                                                  ^
                                                                  |
                                                                  |
+---------+     +-----------------+                               |
|  SNMP   |     |       MIB       |                               |
|         | --> | instrumentation | ------------------------------+
+---------+     +-----------------+

That's closer to reality and why there isn't a conflict that you're so
worried about.  The lock has to happen in that last layer *as it already
does*.  Right now, even if that other path you want to ignore didn't
exist you already have the issue because netconf is allowed to lock out
the CLI, and in reality that means the lock has to be implemented in the
instrumentation *NOT* in the database.  If you were only doing candidate
config, then sure it might work.  But the running config simply doesn't
work like that and never can.

AB> We need real tracks, and stations, and passengers.

Then spend your time on it.  But you don't have control over how others
want to spend their time if you're not writing their paychecks.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Andy Bierman <[email-masked]>
Date: Wed, 08 Jul 2009 09:34:51 -0700

> You seem to think the picture will be like:

Replace SNMP with CLI in your picture.
I do expect the NETCONF data structures and CLI commands
to tweak the same API, rather than independently.

I don't think SNMP Set is used enough to worry about.

> The paths are completely independent:

This is an implementation choice, and a bad one.

> want to spend their time if you're not writing their paychecks.

I am spending time working on the details.

There's already enough people in the IETF doing high-level hand-waving,
and telling other people they should go solve hard problems.

This is a read-only MIB module.
I thought there was some functionality
like a SNMP agent taking out a NETCONF lock,
but this is just another monitoring MIB,
so it isn't a problem.

But if SNMP were to modify a shared managed object...

Why can't the SNMP agent implementation work with the
NETCONF or CLI implementation on the same box, and handle
the locking without any operator involvement?  That's
what we have now.

Andy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 8 Jul 2009 11:41:12 -0700

Hi -

> From: "Wes Hardaker" <[email-masked]>
> To: "Andy Bierman" <[email-masked]>
> Cc: "WashamFan" <[email-masked]>; <[email-masked]>
> Sent: Wednesday, July 08, 2009 9:15 AM
> Subject: Re: [OPSAWG] darft agenda for opsawg
...

In at least some systems you'll find a mixture, where some information
is coordinated by a shared database, other bits are accessed through
common instrumentation without database coordination, and some other
bits go to/from the hardware down at the driver (or even I/O) level.
SNMP's "as if simultaneously" requirement always bordered on wishful
thinking, and NETCONF's drive to nail down locking behaviour, while
admirable, needs to face the messy reality.  SHOULD access be
coordinated? Absolutely.  Can we impose that requirement, particularly
onto existing SNMP, CLI, .... instrumentation? 

Even if the database / instrumentation / hardware coordination is
worked out, there's still a conflict between the locking models used.
Consider the "advisory locks" used in SNMP-land.  They don't map onto
the NETCONF lock semantics at all.  And the locks used within CLI
implementations?

I think that what one ends up with as a consequence of NETCONF's
approach to locking is a model where NETCONF operates on a
configuration data store, and some local demon does its darndest
to make sure that whatever has been done to that data store
via NETCONF supercedes anything done via other interfaces /
instrumentation access points while NETCONF locks were in place.
I'm not saying this is *desirable*; it just seems to be where
all the assumptions lead.

Randy

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 08 Jul 2009 11:41:23 -0700

>>>>> On Wed, 08 Jul 2009 09:34:51 -0700, Andy Bierman <[email-masked]> said:

AB> I don't think SNMP Set is used enough to worry about.

Which is why I wouldn't expect you to support it in your product.  I
know for a fact it's actually used quite a bit.  We have different
contacts though.

AB> This is an implementation choice, and a bad one.

The reality is that nothing but the routing layer in the kernel owns the
routing table.  You may see the picture differently but I doubt you can
argue that a SET, a HTTP POST or a netconf edit-config don't end up only
dealing directly with the data in the kernel.  I don't think an
abstraction from that notion is ever safe, and certainly not when things
like BGP are in play.

AB> But if SNMP were to modify a shared managed object...

It already can and is being used in that way, weather we like it or not.

---

From: "David Harrington" <[email-masked]>
Date: Wed, 8 Jul 2009 19:02:46 -0400

Hi,

The LOCK-MIB is for monitoring locks, since a lock can affect SNMP
operations. This lets an operator (or an SNMP application) understand
why they are getting a resourceUavailable error (or whatever the
correct error code is) when the resource is known to be available.
Otherwise the SET just fails and the operator/NMS has no idea why.

Have you ever worked on a corporate SCCS system, where you might have
gone home at night and forgot to check in your sources before leaving?
Other engineers typically would get a "file locked by user:andy"
message when the other engineer tried to check out the file you had
locked. Withoug actualy changing the SNMP protocol, we want to make
this information available in a MIB to the operator/NMS trying to use
SNMP SET (or other NM interface) when somebody else locked the
configuration using netconf (or other locking NM interface).

If you do not think we need a multi-interface architecture, then why
add a lock mechanism to netconf and declare that every other NM
interface must honor netconf's lock?  The Netconf WG decided netconf
needs to control the behavior of other NM interfaces with its lock.

This MIB just lets operators know what locking behavior is being
forced on other NM interfaces by netconf (or by COPS-PR or by CLI
locks and so on).

dbh

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Andy Bierman
> Sent: Wednesday, July 08, 2009 12:35 PM
> To: Wes Hardaker
> Cc: WashamFan; [email-masked]
^
|
|
|
> > |  SNMP   |     |       MIB       |
|

---

From: "David Harrington" <[email-masked]>
Date: Wed, 8 Jul 2009 19:12:59 -0400

Hi,

I hope everybody is having a wonderful day... 

> know for a fact it's actually used quite a bit.  We have different

+1 

I guess working on multi-vendor NMSs gives one more perspective on how
many vendors' devices do support SETs, as compared to the perspective
of working on one vendor's implementations. Of course, not all vendors
do, and not all functionality is manageable using SETs, but that
doesn't mean SETs are not used in a significant portion of the network
for performance tweaking, for example. Having those SNMP tweaks
blocked by a netconf lock could be problematic to operators responding
to network problems, so we should give operators the ability to
monitor locking activity. YMMV.

dbh

---

From: Phil Shafer <[email-masked]>
Date: Wed, 8 Jul 2009 19:10:48 -0400

"David Harrington" writes:
>for performance tweaking, for example.

This horse looks familiar.  And mostly dead.  rfc3535 c. 2002:

   4.  Because of the previous items, SNMP is not widely used today for
       network device configuration, although there are notable
       exceptions.

That said, I've no problem with someone defining an SNMP lock mib,
but the win would be limited to those "notable exceptions".  If
those exceptions are your customers, then the win's worthwhile.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 08 Jul 2009 16:49:54 -0700

> those exceptions are your customers, then the win's worthwhile.

I agree.
I have no problem with a lock monitoring MIB.

The focus of NETCONF is to replace an unstructured 'screen-scraping',
CLI-encoded API, with a programmatic, XML-encoded API.  SNMP has very
little impact on network device configuration, in comparison.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 9 Jul 2009 09:00:08 +0200

> configuration using netconf (or other locking NM interface).

It is well known that SNMP's error reporting facilities are rather
terse and there have been several proposals over the years to fix
this. I personally have doubts that having separate MIB modules for
all possible error cases is a reasonable approach to address this
issue. Do you really expect management systems to poll a potentially
growing number of MIB modules for possible explanations why a SET
might have failed?

Technically, there are several issues with the MIB module

- it imposes restrictions that might not exist in the lock owning
  technologies (e.g. a user name is limited to 32 octets)

- it uses TimeTicks where it should be using TimeStamp, it does not
  talk about locks that were established before the last reset of
  sysUpTime

- the organization of the tables using different indexes makes it more
  difficult than needed to read out the relevant pieces of
  information

- it provides details about a lock that requires quite some insights
  into other protocol engines, which on many systems might be hard to
  get at implementation wise

I am also wondering why locks are the most interesting thing to look
at. From an SNMP perspective, I would find it much more natural to
have a NETCONF monitoring MIB (which might include information about
NETCONF locks) instead of a MIB module that tries to report locking
information across an open ended set of management interfaces.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "David Harrington" <[email-masked]>
Date: Thu, 9 Jul 2009 17:19:07 -0400

Hi,

Earlier proposals to extend error messages tended to be
content-specific.  They usually included information about why a
specific managed functionality failed, or why, for example, the
configuration SET of a specific functionality failed, not about why an
SNMP operation (independent of the managed technology) failed. That
is, the requested error codes were about the content of the MIB
module, not about SNMP processing. That violated the (sigh) modularity
of the SNMP-SMI-MIB system.

The LOCK-MIB is about something that impacts the processing of the
SNMP protocol itself. SETs could fail because of locks created by
other interfaces. This is different than a SET error caused because an
operator sent an invalid combination of values for the functionality
being managed, and the MIB designer wants to specify a detailed error
report on why the combinations were invalid. Hopefully there will NOT
be a growing number of MIB modules reporting SNMP failures because of
what other NM protocols do that force changes to the way SNMP
processing is done, beyond the SNMP spec.

I used to work on the SNMP stack for an NMS, and that stack had to
deal with error conditions in requested SNMP operations. The stack
would, for example, rebuild the request to remove the identified
problem varbinds in an SNMPv1 request and resend the (n-1) request,
until a query was successful, and then send the combined results to
the requesting code. I think I would definitely consider adding code
to query a LOCK-MIB if I received an unexpected resourceUnavailable
failure for a device I know is functioning properly for GETs, or which
properly handles SET requests to other portions of the MIB. I would
especially consider having such LOCK-MIB checks trigger if I know the
target node supports netconf locks. And I could set a short delay on
retrying the request while polling to see if a lock was removed.

So yes, based on my experience, I do think it is a reasonable
expectation for an NMS to check this MIB module.

And as an oldtimer in the IETF SNMP community, I consider developing a
mib module the appropriate way to handle this, and find it greatly
preferable to charterijng a WG to define a new SNMP version to add a
resourceLockedbyNetconf error code. YMMV.

dbh

> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Thursday, July 09, 2009 3:00 AM
> To: David Harrington
> Cc: 'Andy Bierman'; 'Wes Hardaker'; 'WashamFan'; [email-masked]

---

From: "David Harrington" <[email-masked]>
Date: Thu, 9 Jul 2009 17:33:59 -0400

response #2

Hi,

> information across an open ended set of management interfaces.

Hmmm. Good question. Here's my take:

As described in my first response, SNMP is impacted by cross-interface
locking. I don't care that much whether that locking is done by
netconf, or cops-pr, or the CLI. If it impacts SNMP SET processing, I
would like to know about it. And I would like to know about it fast
enough to make the information useable for possibly coordinating
retries of the original SET, or for an interactive operator to
understand why their SET failed.

Nothing else about netconf or other NM interfaces directly impacts
SNMP protocol operations the way a cross-interface lock does.

We can have one LOCK-MIB that monitors locks "in the system", and
which can be augmented as new locking NM interfaces are added to the
system. The other approach is to document the locks on a
per-locking-NM-interface basis. The choice is between having one MIB
to query, or "an open ended set of" mib modules for an "open ended set
of management interfaces." Persoanlly, I would rather be able to query
one common MIB module than to have to find and query all the MIB
modules for different NM interfaces that might use locking.

dbh

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 9 Jul 2009 14:55:10 -0700

Hi -

> From: "David Harrington" <[email-masked]>
> To: "'Juergen Schoenwaelder'" <[email-masked]>
> Cc: "'WashamFan'" <[email-masked]>; <[email-masked]>
> Sent: Thursday, July 09, 2009 2:19 PM
...
...

One of the challenges to actually implementing such a MIB would be
figuring out how to gather the information pertaining to the various
resources' locks from their respective subagents.  The lack of
direct support in the subagent protocols wouldn't help.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 10 Jul 2009 07:26:11 +0200

On Thu, Jul 09, 2009 at 11:19:07PM +0200, David Harrington wrote:

[...]

I assume many systems have had locks well before NETCONF and it seems
to me that at least Unix systems lack a general centralized mechanism
to record which locks are taken when and by which subsystem and for
how long etc. (and this is why implementing a general lock reporting
MIB module will either be very difficult or never be complete).

But the big question here is: Do we have evidence that NETCONF locks
(or COPS-PR locks or CLI locks or ... locks) seriously impact SNMP set
requests in real world installations?

/js

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 10 Jul 2009 07:20:32 -0700

>>>>> On Fri, 10 Jul 2009 07:26:11 +0200, Juergen Schoenwaelder <[email-masked]> said:

JS> But the big question here is: Do we have evidence that NETCONF locks
JS> (or COPS-PR locks or CLI locks or ... locks) seriously impact SNMP set
JS> requests in real world installations?

I'm sure they don't right now, as netconf isn't used in the real world (yet).
I'm not sure that's a wise way to decide whether the work should be done
or not.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: WashamFan <[email-masked]>
Date: Sat, 11 Jul 2009 13:24:14 +0800

Hi,

>    technologies (e.g. a user name is limited to 32 octets)

How about user name is limited to 255 octets which is the max allowed
length of SnmpAdminString?
  
>    talk about locks that were established before the last reset of

TimeStamp may make more sense. OK. for the locks which is 
still valid across reboot of SysUpTime , the startTime should be kept 
as persistent after the reboot otherwise startTime should be set to
0 which implies "I don't know when the lock starts".
  
>    difficult than needed to read out the relevant pieces of

OK. lockIndex should be used as the INDEX of lockTable as well
as specific tables. I will fix it.
  
>    get at implementation wise

For example, Netconf toolkits are responsible for lockNetconfTable
implementation. agentX could be used to consistent between lockTable
and specific tables.
   
>  information across an open ended set of management interfaces.

locks seem the only aspect of Netconf impacting SNMP operations. 
The purpose of this MIB is to make information available to operators 
about conditions that prevent SNMP from working properly.

While a netconf MIB might be nice, the netconf WG decided that
providing their own monitoring schema was appropriate. The proposal
does not preclude the development of a mib module for monitoring
netconf.

washam

---

From: WashamFan <[email-masked]>
Date: Sat, 11 Jul 2009 13:34:12 +0800

Hi,

>  only the -01 draft is relevant, right?

Well, lock-mib is dealing with monitoring multi-protocol locks.
snmp-lock is dealing with defining "virtual SNMP lock operations"
through which managers can lock, unlock something in SNMP
context. SNMP lock should be monitored via LOCK-MIB.

washam

---

From: Andy Bierman <[email-masked]>
Date: Sun, 12 Jul 2009 07:51:54 -0700

> I'm not sure that's a wise way to decide whether the work should be done

I think Juergen asked the most relevant question possible.
The IETF does not have enough resources to solve theoretical
problems instead of high-priority real problems.

If nobody is using NETCONF in the 'real world', it seems highly
unlikely that SNMP Set could be getting blocked by NETCONF locks.

Andy

---

From: "David Harrington" <[email-masked]>
Date: Mon, 13 Jul 2009 06:16:17 -0400

Hi,

COPS-PR recognied that have multiple interfaces n a device could lead
to conflicts, and defined a lock.
Netconf recognized the same thing, and designed a lock into netconf.
SNMP recognized the same thing, and designed the "as-if-simultaneous"
logic into the design of a SET.

But things have changed since 1988.
SNMP now supports session-based transports.
We can send larger messages.
A session-based approach helps solve the "gumball" problem - an
application can send multiple SETs through the same session,
effectively craeting a transaction spanning multiple messages.
Operators said they really wanted better transaction control in IETF
NM interfaces.
But the "as-if-simuktaneous" logic gets stretched pretty thin when the
message size increases, and does not apply at all to multi-message
transactions. Netconf, CLI, COPS-PR - <add your favorite management
protocols here> - can interfere with a large SET or a multi-message
SET.

Is this a real issue, or just some theoretical edge case?
Well, HuaweiSymantec builds firewalls, and we configure those
firewalls using policy-based configuration of ACL lists, and we happen
to use SNMP SETs in our products to do that feature-specific
configuration. The tables that define the ACLs have a large number of
columns, and the table can have a large number of rows. We really do
not want to configure one row at a time, and have netconf or CLI or
COPS-PR stop us in the middle and do other confguration work that
might impact our configuration. We also do not want to ship the ACL
table in one HUGE SNMP message so we do not tie up the CPU from doing
other non-configuration duties while performing an as-if-simultaneous
SET of the whole table; we would rather send multiple messages to
complete the transaction.

Therefore, we would like a LOCK in SNMP that allows us to make sure
nobody interrupts our configuration transaction. We want an SNMP lock
because it is a real need for a real shipping product. We do not have
an SNMP lock at this point, but if we are going to put netconf on the
product, then we want locks protecting both interfaces, not just one
of them. And we have dedicated our resources to defining such a lock,
and we have made sure that what we propose accommodates netconf and
other NM standard interfaces that have defined locks.

We think our use case is real enough to justify that this work should
be done. 

dbh

> From: Andy Bierman [mailto:[email-masked]] 
> Sent: Sunday, July 12, 2009 10:52 AM
> To: Wes Hardaker
> Cc: David Harrington; 'WashamFan'; [email-masked]
> >>>>>> On Fri, 10 Jul 2009 07:26:11 +0200, Juergen 
> Schoenwaelder <[email-masked]> said:
> >

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 13 Jul 2009 12:52:56 +0200

> [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder

> 
> I am also wondering why locks are the most interesting thing 
> to look at. From an SNMP perspective, I would find it much 
> more natural to have a NETCONF monitoring MIB (which might 
> include information about NETCONF locks) instead of a MIB 
> module that tries to report locking information across an 
> open ended set of management interfaces.
> 
> /js
> 
> -- 

Yes, but I would expect that piece of work to be proposed to the NETCONF
WG. What is being proposed here in OPSAWG seems to be a MIB module that
would help an operator understand that the failure of an SNMP SetRequest
is caused by a lock activated by some protocol (not necessarily SNMP,
not necessarily NETCONF). This looks like useful functionality to me,
and worth agenda time in Stockholm. 

Dan
(speaking as a contributor and catching up with mail after vacation)

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 18 Jul 2009 20:30:57 +0200

> length of SnmpAdminString?

If the original protocol (NETCONF in this case) does not have a limit,
you can't impose a limit in the MIB module. Or you have to explain
what happens if a name happens to exceed the limit.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 18 Jul 2009 20:36:10 +0200

> and worth agenda time in Stockholm. 

The MIB module only support NETCONF and COPS-PR (a protocol many
consider dead). My problem is that I do not understand the target:

- If the target is better error reporting for SNMP, then fix this
  problem and lock error reporting falls out of that.

- If the target is to indicate reasons for SNMP set failures due to
  arbitrary transient locks, then the MIB module should be much more
  generic and not NETCONF/COPS-PR specific. (I do remain sceptical
  that this is practical to implement.)

- If the real worry are NETCONF and SNMP interactions, then you really
  want a NETCONF MIB.

I think it is crucial to figure out in Stockholm which problem
operationally exists and should be solved.

/js