Subject: [OPSAWG] opsawg consensus check

From: [email-masked] (Scott O. Bradner)
Date: Thu, 20 Aug 2009 20:59:32 -0400 (EDT)

the SNMP Lock & lock MIB documents were dicussed during the Stockholm
meeting - the room was asked if they should become opsawg documents

no one raised their hand to indicate that they were against the
idea but only a few people raised their hands in favor 

the IDs are
	draft-fan-meng-snmp-lock
	draft meng-fan-lock-mib

please express your opinion to the list

tnx

Scott

---

From: "David Harrington" <[email-masked]>
Date: Thu, 20 Aug 2009 21:28:23 -0400

Hi,

I think the lock-mib would be a useful monitoring tool. the IETF is
moving toward a multi-protocol management approach, to support the
real-world multi-protocol approach to NM. The IETF is designing NM
protocols with locks that impact SNMP. It is important to allow
operators to see what locks are impacting SNMP.

The SNMP lock is less urgent. SNMP has no decent lock capability. With
the emerging changes to SNMP, such as session-based transports, and
new NM protocol standards, I think support for locking in SNMP could
be needed. This is an optional feature that implementers can choose to
implement or not; it is not being proposed as a mandatory-to-implement
feature in SNMP. Since OPSAWG is handling many of the
multi-NM-protocol coordination issues already, I believe this is the
appropriate WG to take on this task, and as with many of the other
proposals in this WG, this does not look like a resource-intensive
work item. 

David Harrington
[email-masked]
[email-masked]
[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Scott O. Bradner
> Sent: Thursday, August 20, 2009 9:00 PM
> To: [email-masked]
> Subject: [OPSAWG] opsawg consensus check
> 
> 
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 21 Aug 2009 08:30:45 +0200

> please express your opinion to the list

I suggest the authors of these documents take the feedback from the WG
meeting in Stockholm and the mailing discussion as input to produce
revised IDs where the motivation and scope for this work becomes
clearer. This will give us a much better basis to take a decision.

/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: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Fri, 21 Aug 2009 09:07:27 +0200

+1
  ----- Original Message ----- 
  From: Juergen Schoenwaelder 
  To: Scott O. Bradner 
  Cc: [email-masked] 
  Sent: Friday, August 21, 2009 8:30 AM
  Subject: Re: [OPSAWG] opsawg consensus check

  /js

------------------------------------------------------------------------------

  No virus found in this incoming message.
  Checked by AVG - www.avg.com 
  Version: 8.5.409 / Virus Database: 270.13.62/2315 - Release Date: 08/20/09 06:05:00

---

From: Tina TSOU <[email-masked]>
Date: Fri, 21 Aug 2009 16:46:08 +0800

+1

B. R.
Tina
http://tinatsou.weebly.com/contact.html

  ----- Original Message ----- 
  From: Bert Wijnen (IETF) 
  To: Juergen Schoenwaelder ; Scott O. Bradner 
  Cc: [email-masked] 
  Sent: Friday, August 21, 2009 3:07 PM
  Subject: Re: [OPSAWG] opsawg consensus check

  +1
    ----- Original Message ----- 
    From: Juergen Schoenwaelder 
    To: Scott O. Bradner 
    Cc: [email-masked] 
    Sent: Friday, August 21, 2009 8:30 AM
    Subject: Re: [OPSAWG] opsawg consensus check

    /js

----------------------------------------------------------------------------

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 21 Aug 2009 08:05:46 -0700

>>>>> On Thu, 20 Aug 2009 20:59:32 -0400 (EDT), [email-masked] (Scott O. Bradner) said:

SOB> the SNMP Lock & lock MIB documents were dicussed during the Stockholm
SOB> meeting - the room was asked if they should become opsawg documents

I agree that reading something more concrete based on the suggestions
would be good.

But the fundamental problem is: is the problem real enough we should be
working on it, and I think it is so I'm in favor of a solution.  Which
solution is a different question.

Cross-protocol locks, unfortunately, are difficult.  Especially when
trying to write generic support code.  I've had conversations with
people that aren't sure how'd they'd implement the netconf locking
requirements.  It's a system-wide feature requirement so it's actually
impossible to stamp a "RFC4741 Locking Compliant" stamp on a agent
development package.  Because it's impossible.  The system has to make
sure the lock is enforced everywhere, which a software provider can't
do.

Because the complexity of simple locks can be difficult depending on the
system, I think management of them from *every* protocol affect is an
absolute MUST.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 25 Aug 2009 12:18:03 -0700

Hi -

> From: "Wes Hardaker" <[email-masked]>
> To: "Scott O. Bradner" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, August 21, 2009 8:05 AM
...
> sure the lock is enforced everywhere, which a software provider can't

To me the problem looks more and more like Byzantine agreement,
particularly if we have no way of ensuring that the access control models
of the various protocols will have been configured to provide a coherent
policy, and if we admit the reality that there will be inconsistencies in how
the information is modelled and thereby constrained in the different protocol
environments.  Assuming the implementations are error-free, of course.  :-)

> system, I think management of them from *every* protocol affect is an

And there's the rub.  Retro-fitting SNMP, for example, would require digging
into AgentX, SNMP proxy, and the various proprietary subagent mechanisms.
This would keep someone busy for a long time.

There may be lessons to be learned here from the world of configuration
management.  (As in Webdav, CVS, SCCS, RCS, .... )

Randy

---

From: "David Harrington" <[email-masked]>
Date: Wed, 26 Aug 2009 12:26:58 -0400

Hi,

I am not sure this answered Scott's question.

dbh 

> [mailto:[email-masked]] On Behalf Of Randy Presuhn
> Sent: Tuesday, August 25, 2009 3:18 PM
> To: [email-masked]