Subject: Review of draft-ietf-snmpconf-bcp-07

From: "Glenn Waters"<[email-masked]>
Date: Fri, 11 Jan 2002 20:11:58 -0500

Sorry this is late and past the end of the WG last call.

I find that there is a great deal of good information in this document. It
is a monumental task to write about so many complex network management
topics in a single IETF document -- a book would be hard pressed to present
so much information.

Let me start with a few general comments about the document. 

First, I have a hard time with the classification of this document as a BCP.
There is some BCP content but there is also content that is Experimental,
Informational, and, some which should be put into a standard. I point out
some of those sections as I went through.

Second, there are some sections of the document that seem to gloss over the
detail. Sections 4 and 5 are notable examples where the concepts are hastily
presented and conclusions on how to deal with the issue is light on detail.
I found reviewing these sections very difficult since if I were to write
anything then I would have to spend a huge amount of time giving the
feedback. I do note that the topics in those sections are very complexity
and I can understand why I feel that they are light. I am not sure how or if
they should fit into this document.

Third, and this doesn't have so much to do with this document as it does
with SNMP configuration management in general, it's no wonder people don't
do configuration management using SNMP. Given the amount of information
presented in this document (and for the most part its good information), the
complexity of implementing configuration management using SNMP is well
beyond many development organizations. I consider myself reasonable
experienced in this area and I find that I would have a hard time developing
a system that could reasonably be configured using the SNMP. Not many
organizations have experienced SNMP developers to the level of some of the
techniques that are presented here. CLI looks so very inviting after reading
all the tricks, tips, and details that one must consider.

Finally, I did not review section 8.

Onto some specifics:

----

[page 5]
	2.2.  Practical Requirements for Transactional Control

This section was overly vague and I am not sure exactly what the I am to
take away from information. There is some good general information but
nothing that is specific enough that I could use it -- especially in the
context of a BCP.

----

[page 10]
	Object descriptors (the "human readable names" assigned to object
iden-
	tifiers [5]) defined in standard MIB modules should be unique across
all
	MIB modules.  

Not sure that this is possible, desirable, or required. I think that being
unique within a MIB module is just fine. Besides, vendors MIBs will likely
use a name that is being used by some other module.

----

[page 10]
	Secondly, management
	applications can be pointed at specific subtrees for fault or
configura-
	tion, causing a more efficient retrieval of data and a simpler
manage-
	ment application with potentially better performance.

I don't get this point which is in the section called "Naming MIB Modules
and Managed Objects". How does naming objects have anything to do with the
OID tree structure?

----

[page 12]
	3.3.3.  Transaction Control MIB Objects

This section should be merged with section 3.12. This section (3.3.3) is
vague and section 3.12 has some better detail to help understand the
concept.

----

[page 14]
	RowStatus object when the row under creation does not yet have all
of
	the required, non-defaultable instance values for the row.  One
approach
	to simplifying in-row configuration transactions when designing MIB
mod-
	ules is to construct table rows that have no more instance data for
	columnar objects than will fit inside a single SET PDU.  In this
case,
	the createAndWait() value for the RowStatus columnar object  is not
	required.  It is possible to use createAndGo() in the same SET PDU,
thus
	simplifying transactional management.

It is also possible for an MIB to say "the agent must support a minimum PDU
size of 'X'" where X is big enough to contain all the columns of a new row.
This would ensure that an entire row fits in a PDU.

----

[page 27]
	An example of such an object from the OSPF Version 2 MIB [27] is the
	global ospfAdminStat:

	    ospfAdminStat OBJECT-TYPE
		SYNTAX   Status
		MAX-ACCESS   read-write
		STATUS   current
		DESCRIPTION
		   "The  administrative  status  of  OSPF  in  the
		   router.   The  value 'enabled' denotes that the
		   OSPF Process is active on at least  one  inter-
		   face;  'disabled'  disables  it  on  all inter-
		   faces."
	       ::= { ospfGeneralGroup 2 }

This object does not seem to match the discussion from the previous
paragraphs. The point that I get from the section is that you are describing
how to activate parts of a configuration. It seems that this object is
activating a process which uses some configuration. I thought that you would
present an object that controls some part of the configuration.

----

[page 32]
	INFORM PDUs, as opposed to TRAP PDUs, have an inherent advantage
when
	the concern is the reduction of unneccessary messages from the
system
	generating the NOTIFICATION-TYPE data.

I don't understand what the inherent advantage is. This statement could use
some clarification.

----

[page 39]
	4.1.  Operational Consistency

I read this section a number of times and the text seems more like a thesis
than a BCP document. There is some good information in the section but there
I think that the information would only give me some food for thought when
designing the system and would not give me concrete ideas on my design.

----

[page 41]
	4.2.  Handling Multiple Managers

This topic is very complex and has very little explanation. I am not
comfortable with what is presented. Maybe a one liner somewhere else in the
document that says something to the effect that "managers could consider
methods of providing redundancy for each other when possible" (similar to
the last sentence in the paragraph).

----

[page 42]
	  1. A method for restoring a previous configuration to one or
	  more devices. Ideally this restoration should be time indexed
	  so that a network can be restored to a configured state as of
	  a specific time and date.

	  2. A method for saving back up versions of the configuration
	  data in case of hardware or software failure.

	  3. A method of providing fail-over to a secondary (management)
	  system in case of a primary failure. This capability should be

These are not BCP but are requirements of a management station solution.
Good stuff to think about but not in the context of a BCP.

----

[page 43]
	-    Ensure minimum movement of data

Minimum movement of data does not stand alone as a general management
application design. It needs to be traded off against CPU, bandwidth,
application complexity, etc.

----

[page 44]
	Management software should be mindful of the environment in which
SET
	operations are being deployed. The intent here is to move
configuration
	information as efficiently to the managed device as possible.  There
are
	many ways to achieve efficiency and some are specific to given
devices.
	One general case that all management software should employ is to
reduce
	the number of SET PDU exchanges between the managed device and the
man-
	agement software to the smallest reasonable number. One approach to
this
	is to verify the largest number of variable bindings that can fit
into a
	SET PDU for a managed device. In some cases, the number of variable
	bindings to be sent in a particular PDU will be influenced by the
	device, the specific MIB objects and other factors.

I'm not sure what to do with this paragraph. There are some true and valid
points but the paragraph ends on a very vague not saying "and other
factors". This document is supposed to help those who don't know. I think I
knew, but I have not figured out what the other factors are.

----

[page 44]
	Maximizing SET variable bindings within a PDU has beneficial
implica-
	tions in the area of management application transaction initiation,
as
	well, as we will discuss in the following section.

Parse error.
I think I get the meaning. Could it not be said a whole lot simpler -- or
not said at all -- let the following section talk about it.

----

[page 44]
	Yet there are agents that may have implementation limitations on the
	number and order of varbinds it can handle in a single SET PDU.  In
this
	case, sending fewer varbinds will be necessary.

Good information. How am I supposed to write the management application? How
do I determine that I have a "broken" agent?

----

[page 44]
	Some SNMP agents implement a subset
	of the features available and so the  management application must
avoid
	using features that may not be supported in a specific table
implementa-
	tion, such as createAndWait.

Good information. How am I supposed to write the management application? How
do I determine that I have an agent with partial support for a standard?

----

[page 46]
	5.2.3.  Notifications
	As described throughout the section on Agent Software Development,
	agents should provide the capability for notifications to be sent to
	their configured management systems whenever a configuration
operation
	is attempted or completed.  The management application must be
prepared
	to accept these notifications so that it knows the current
configured
	state of the devices it has been deployed to control.  Some
configura-
	tion management applications may consume data from the managed
devices
	that reflect configuration, operational and utilization state
informa-
	tion. The GetBulkRequest-PDU is useful here whenever supported by
the
	managed device. For the purposes of backward compatibility, the
manage-
	ment station should also support and make use of the
GetNextRequest-PDU
	in these cases.

I am missing the point here. First what does getBulk have to do with
notifications? I think the point around get* should be in a separate section
that deals with retrieving lots of data from a box.

----

[page 46]
	5.2.4.  Scalability of Data Retrieval

	Efficient data retrieval described above is only part of the
dimension
	of scale that application developers should consider when developing
	configuration applications. Management applications should provide
for
	distributed processing of the configuration operations. This also
	extends to other management functions not the focus of this
document.
	This capability can also be used to provide resilience in the case
of
	network failures as well. An SNMP-based configuration management
system
	might be deployed in a distributed fashion where three systems in
dif-
	ferent locations keep each other synchronized. This synchronization
can
	be accomplished without additional polling of network devices
through a
	variety of techniques between each of the three managers. In the
case of
	a failure, a 'backup' system can take over the configuration
responsi-
	bilities of the failed manager without having to re-synchronize with
the
	managed elements since it will already be up to date.

This section sounds very experimental to me.

----

[page 49]
	7.  POLICY BASED MANAGEMENT

Not sure how policy management is BCP.

----

[page 50]
	    - there is the ability to specify "default" configuration data
for a
	      number of instances of managed elements, where those instances
can
	      be correlated in some data driven or algorithmic way.  The
engine
	      to do this correlation and activate instances from defaults
may
	      reside in the agent or externally.  Where the representation
of
	      these defaults are in the MIB design itself, the object types
	      supporting this notion are referred to as "template objects".

The notion of template objects is introduced here. What I do not understand
is why is the concept of template objects not used in
draft-ietf-snmpconf-pm-09.txt? We need some consistency of terminology
whether it is in this document or in the policy MIB document. Seems like
this is a new concept that needs more vetting than what is being done in
this document. Once again, the information is interesting and somewhat good
just misplaced.

----

General edits...

s/internet/Internet/
s/implementors/implementers/
s/accomodate/accommodate/
s/indesx/indexes/
s/variable bindings/varBinds/ -- this would improve some of the readability

From page 5 of RFC 2223:
      Do not do hyphenation of words at the right margin.

Cheers, /gww

---

From: Michael MacFaden <[email-masked]>
Date: Fri, 11 Jan 2002 17:59:00 -0800

Glen,

Thanks very much for the detailed review as well as the 
impression the document left you with. 

Below are some comments... 

Regards,
Mike

>identifiers [5]) defined in standard MIB modules should be unique across
>all MIB modules.  
>

The experts I spoke with have said this isn't good to do.
Also I know of one implementation (hp openview xnmloadmib) where such things
will cause import errors.

Granted enterprise mib modules may have overlaps, so the problem remains. 
sming should fix this.

>configuration, causing a more efficient retrieval of data and a simpler
>management application with potentially better performance.
>

I'll take a stab at this, though Jon or Wayne should chime in.

Many folks assume there is a relationship between the names and the branches
of the oid tree. The example above goes into one specific approach
to grouping information with a given name. Would it be useful
to have a real example? 

>present an object that controls some part of the configuration.

I see your point, the above object does activate the whole config
and not a part of it. I will find a better example from a standard mib
module.

>I don't understand what the inherent advantage is. This statement could use

Jon, can you augment paragraph 3 of 3.10.2 ?

In the code I've seen, you have two cases: 
1) a given event occurs either slower than can be delivered
to manager station or faster.
In the slow case, there isn't anything "reduction"
as the agent didn't care and the manager which may
or may not have seen the event eventually polled for
status and took care of the problem anyway.

2) In the fast case, an inform will just cause a backup
of messages in the agent, and some events will be dumped 
(queue full) before being sent. I guess this is a
"reduction" of traffic on the wire :-)

---

From: "Jon Saperia <saperia>" <[email-masked]>
Date: Sat, 12 Jan 2002 09:17:56 -0500

> Below are some comments...

Glen, thanks also for your comments. This also gives me a chance to say 
where we are on revisions to the document. We have recieved comments on 
the most recent version for Bert in a handwritten form, David Partain, and 
Rand P who posted to this list some time ago.  We are happy to work on 
your comments as well. I do have some comments on them and rather than 
starting multiple threads, I have replied to the comments Mike made.

We did spend quit a lot of time on Thursday going over the handwritten 
notes that Bert provided. Some were specific and detailed, others were 
not. David Partain was also very thorough and even gave us a diff.  Our 
goal is to work through these over the next week or so.

Not to the comeents on the comments.

> >First, I have a hard time with the classification of this document as a
> > BCP. There is some BCP content but there is also content that is
> > Experimental, Informational, and, some which should be put into a
> > standard. I point out some of those sections as I went through.
> >
We have discussed this point in the past at some length. This is a hard 
call here, but at some point in the future if more work is done in this 
area and we need standardization, that can happen. I still feel BCP is the 
best general description.

With regard to your comments about configuraiton with SNMP. Yes, it does 
add complexity but in my experience now with at least 4 implementations of 
systems that use SNMP as a configuration method, it is just not as hard as 
many people that have not done it indicate. These implementations include 
products that range from shipping bandwidth management products in quite 
small footprints to very large router types of products. Much of the work 
is in the design of the MIB Objects. Done following some of the principles 
in the BCP, it makes the task easier and the resulting product more useful 
at least for those of us that wish to write sophisticated management 
applications. This is really not too relevant to the BCP at this point 
except to say that people can and do build products successfully this way.

> >identifiers [5]) defined in standard MIB modules should be unique
> > across all MIB modules.
> >
> >Not sure that this is possible, desirable, or required. I think that
> > being unique within a MIB module is just fine. Besides, vendors MIBs
> > will likely use a name that is being used by some other module.
>
> Also I know of one implementation (hp openview xnmloadmib) where such
> things will cause import errors.
>
> Granted enterprise mib modules may have overlaps, so the problem
> remains. sming should fix this.

Mike, is quite correct in my experience with applications. His example of 
HP is one. I had a similar experience with the SUN product not that long 
ago.  

> >I don't get this point which is in the section called "Naming MIB
> > Modules and Managed Objects". How does naming objects have anything to
> > do with the OID tree structure?
>
> Many folks assume there is a relationship between the names and the
> branches of the oid tree. The example above goes into one specific
> approach to grouping information with a given name. Would it be useful
> to have a real example?

Glen/Mike When constructing a management application to work with an 
agent, if the counters for a particular part of the sub system fall 
withing a single branch like the acmeFooStatistics group, then with a 
single OID, I can tell the system to retrieve all the data needed to know 
about Foo statistics without having to put into the manager several OIDs. 
It is just good organization of data. 
> >paragraphs. The point that I get from the section is that you are
> > describing how to activate parts of a configuration. It seems that
> > this object is activating a process which uses some configuration. I
> > thought that you would present an object that controls some part of
> > the configuration.
>

Mike please pass that on to use and we will be sure to include it.
> >I don't understand what the inherent advantage is. This statement could
> > use some clarification.
>

Yup, you folks are quite correct. Wayne and I talked about this the other 
day. We have some new words.

-- 
Jon Saperia                         
				
[email-masked]
Phone: 617-744-1079
Fax:   617-249-0874
http://www.jdscons.com/

---

From: "Jon Saperia <saperia>" <[email-masked]>
Date: Sat, 12 Jan 2002 09:47:54 -0500

On Friday 11 January 2002 08:11 pm, Glenn Waters wrote:

> Second, there are some sections of the document that seem to gloss over
> the detail. Sections 4 and 5 are notable examples where the concepts are
> hastily presented and conclusions on how to deal with the issue is light
> on detail. I found reviewing these sections very difficult since if I
> were to write anything then I would have to spend a huge amount of time
> giving the feedback. I do note that the topics in those sections are
> very complexity and I can understand why I feel that they are light. I
> am not sure how or if they should fit into this document.

Mike did not comment on this so it was not in my previous reply. The 
approach that we took is that an increment in information is better than 
the current lack in some of these areas, particularly with regard to 
management applications (section 5). I have to agree with your observation 
that quite a lot more could be written. We think the observations 
contained in these sections while not complete add to understanding and 
are good practices. Section 5 stems mostly from my experience sometimes 
learned the hard way.

/jon
-- 
Jon Saperia                         
				
[email-masked]
Phone: 617-744-1079
Fax:   617-249-0874
http://www.jdscons.com/

---

From: John Schnizlein <[email-masked]>
Date: Mon, 14 Jan 2002 09:06:13 -0500

Questioning the appropriateness of describing configuration through 
SNMP as Best Current Practice will not go away. The most basic reason 
for this is that it is not a current practice.

Among the interesting observations discussed in the Configuration BOF
(Salt Lake City 12/10) was Randy' Bush's summary:
"We can't find anybody using SNMP to configure."

What are the "at least 4 implementations of systems that use SNMP as 
a configuration method" mentioned in your reply below? 
Maybe we missed them.

John

---

From: Randy Bush <[email-masked]>
Date: Mon, 14 Jan 2002 09:02:53 -0800

> "We can't find anybody using SNMP to configure."

and many vendors, including prominent ones, don't even implement writing of
all the things which would be needed.

> a configuration method" mentioned in your reply below? 

as the 'p' in bcp stands for 'practice,' who are the USERS who use snmp as
their configuration method?

randy

---

From: "David T. Perkins" <[email-masked]>
Date: Mon, 14 Jan 2002 10:21:06 -0800

HI,

There are specific products and markets where configuration is done
via SNMP. For example, the interoperable way to configure RMON probes,
and cable modems across device vendors is to use SNMP. There way also
be other examples in specific areas.

Let me go out on a limb here...
Where there is a standard way to perform configuration that works
across products from different vendors, SNMP is probably the mechanism
that is being used. Creating a standard approach is more time consuming
and expensive for early device vendors (than creating proprietary
mechanisms). (And it can be much cheaper for follow-on device vendors).
Creating multiple standards (one for each technology area) for use in
a modern router (where there is some amount of interaction) is
a quite difficult problem. For example, configuration of brand C routers
is based on creating access control lists (ACLs), which are used as
a selection mechanism in configuration of many different technologies.
Brand X router, may use a different model for a selection mechanism.
How is a set of configuration standards created that has
dependencies between standards and can be implemented by
different device vendors?

Moving even farther out on the limb...
It doesn't seem to me that it is the SNMP protocol, or SNMP's SMI,
but an immaturity and/or diversity of configuration models found
in modern routers from different device vendors. Creating another
protocol or data modeling language will probably not help.

If this is the case, then the area needs some really smart,
experienced, and motivated people with a shared goal to make
some progress. I'll be the first to support them. But I'm also
leery of sales agents of simple solutions or those that make
unsupported claims.

>their configuration method?
Regards,
/david t. perkins

---

From: John Schnizlein <[email-masked]>
Date: Mon, 14 Jan 2002 14:43:59 -0500

At 01:21 PM 1/14/2002, David T. Perkins wrote:

>and cable modems across device vendors is to use SNMP. 

I don't claim to be an expert on cable modems. My understanding is
that the usual operation of cable modems is as specified by DOCSIS.
Admiting that I don't have the most current documentation, the
August 29, 2001 Operations Support System Interface Specification
(SP-OSSIv1.1-I04-010829) contains this on page 30:

  During initialization, a CM communicates with a DHCP Server that 
  provides the CM with its assigned IP address and, in addition,
  provides a pointer to the TFTP Server that stores the assigned
  CM Config File for that CM. The CM reads the CM Config File and
  forwards the set of Service Flow definitions (using SCNs) up to 
  the CMTS...

My interpretation (maybe there is a clearer quote) is that DOCSIS
configuration is performed through Dynamic Host Configuration Protocol
(DHCP) and Trivial File Transfer Protocol, not SNMP. This document
specifies in detail how SNMP is configured along with other things 
through these protocols. So, cable modems are an example where SNMP
is NOT used in practice for configuration.

I know even less about RMON probes, but since RMON is a creature of
SNMP, its configuration through SNMP would constitute configuring SNMP
features through SNMP, not configuring the network through SNMP.

>...

We agree on the need for smart people with shared goals to invent
configuration solutions for networks. Randy is trying to gather and
organize the perspective of operators in a fresh start on this effort.

My impression is that there is not a Current Best Practice for network
configuration to be documented. Instead, there are lots of creative ideas.

Don't know who you see as a sales agent.
I am not making unsupported claims, just asking for actual instances of
the practice of configuring through SNMP.

John

---

From: Michael MacFaden <[email-masked]>
Date: Mon, 14 Jan 2002 12:09:34 -0800

>  forwards the set of Service Flow definitions (using SCNs) up to 

John,

Please keep reading.

SNMP is an application layer protocol
so SNMP can't do any initial device configuration. 
Once a cable modem is up and running cable modems and cable modem head
ends are managed via SNMP to tweak and endless number of
configuration bits. See RFC 2669, 2670 or give Rich Woundy
at Cisco a call.

Most all other devices I listed behave the same way. The
low end devices often come with a preconfigure ip address:
Gee, what should it be? Hmm. Underlying hacks must then
be invented to figure out how to make such things simpler.

Regards,
Mike

---

From: Randy Bush <[email-masked]>
Date: Mon, 14 Jan 2002 12:14:30 -0800

> configuration bits. See RFC 2669, 2670 or give Rich Woundy

when you have to scale, tweaking single devices is just not on.  the
canonic configuration is on a disk drive.

randy

---

From: Michael MacFaden <[email-masked]>
Date: Mon, 14 Jan 2002 12:43:50 -0800

>canonic configuration is on a disk drive.

My words above may give the wrong impression of how things
work, sorry. If you spend time in the operations of a cable modem 
shop, I haven't heard of many scaling issues other than
managing nasty coax/how many upstreams you can get&need 1x4/7/... 

Mike St John and crew figured out the scaling issues pretty well. 
At the time of @Home's demise, over 5 milllion subscribers
were being served across a number of continents, across a number
of mom and pop HFC networks (the kind that reboots your head ends 
when their m$ dhcp server doesn't work). That's an alot of devices that
support full read-write SNMP configuration in RFC 2670
plus the updated MIB-II objects 1907/2863/2011-13/2096.

They got config, diag, and monitoring stuff nicely wrapped
up in one consistent protocol (albeit SNMP) and then the market muscle 
(docsis org) to make vendors to implement it consistently.

Could it have been done with a standard CLI? Absolutely.  

Thanks,
Mike

---

From: John Schnizlein <[email-masked]>
Date: Mon, 14 Jan 2002 15:47:55 -0500

I hope "to tweak endless number of configuration bits" is not 
being put forward as best practice for network configuration.

The existence of a (small fraction) of R/W MIB variables is not a very
compelling argument for the "best practice" claim. Can you name the
operator of a network who would say that they configure their network
through SNMP? 

This is different from using SNMP for monitoring and tweaking.

John

At 03:14 PM 1/14/2002, Randy Bush wrote:
>> Once a cable modem is up and running cable modems and cable modem 
>> head ends are managed via SNMP to tweak and endless number of
>> configuration bits. 
>
>when you have to scale, tweaking single devices is just not on.  
>the canonic configuration is on a disk drive.
>
>randy

---

From: "Jon Saperia <saperia>" <[email-masked]>
Date: Mon, 14 Jan 2002 16:00:14 -0500

> being put forward as best practice for network configuration.

The Best Current Practices document we have written has a focus on SNMP, 
thus the title Configuring Networks and Devices With SNMP. It does not 
claim to be the final best approach for configuration of networks. I think 
we are a long way from there. It does offer good approaches for 
configuration when one uses SNMP.

> operator of a network who would say that they configure their network

I have provided examples of products that have SNMP configurability for 
their major operational compoents, are shipping and in use. 

/jon

-- 
Jon Saperia                         
				
[email-masked]
Phone: 617-744-1079
Fax:   617-249-0874
http://www.jdscons.com/

---

From: Michael MacFaden <[email-masked]>
Date: Mon, 14 Jan 2002 13:17:53 -0800

>being put forward as best practice for network configuration.

No more so than tweaking metrics on routing protocols or updating
access control lists or handling connectivity problems due to
an implementation bug when an edge router sees invalid cruft 
from another edge router whose software was just updated.

You just have admire this quote from Tony Li:
  Be liberal in what you accept, conservative in what you send, and add a
  knob so that you can interoperate even if the other guy blows it.

That kind of tweaking...of course it isn't a BCP.

>operator of a network who would say that they configure their network

Strangely, they may or may not know they use SNMP. 
Customers will to me things like, I use
Lucent NavisCore or some other marketing term for an EMS product
and that is how they want to configure their network. 

If you define/use SNMP read-write objects and implement the
Internet Standard Management Framework, the BCP attempts to show how 
things have progressed in the past ten years or so and what works and
what to watch out for and to some extent, what the current 'thinking' is. 

Mike

---

From: John Schnizlein <[email-masked]>
Date: Mon, 14 Jan 2002 16:17:57 -0500

At 04:00 PM 1/14/2002, Jon Saperia <saperia> wrote:
>> Can you name the operator of a network who would say that 
>> they configure their network through SNMP?
>
>I have provided examples of products that have SNMP configurability 
>for their major operational compoents, are shipping and in use. 

Please forgive me if it is just my inability to see equivalence.
Just because features are included in products, and used somewhere,
does not make them practices, much less best practices.
There are some QoS features in older versions of IOS I would not
recommend. ;-) I was told somebody asked for them.

John

---

From: John Schnizlein <[email-masked]>
Date: Mon, 14 Jan 2002 16:36:14 -0500

You have made some useful points:

>That kind of tweaking...of course it isn't a BCP.

I do admire Tony's attitude and style. When I was operating a network
I once had occasion for him to tell me "Just because we give you enough
rope to hang yourself, doesn't mean we want you to."

>>The existence of a (small fraction) of R/W MIB variables is 
>>not a very compelling argument for the "best practice" claim. 
>>Can you name the operator of a network who would say that they 
>>configure their network through SNMP? 
>

Maybe the correct summary is that operators who do not know 
what protocol they use to configure their networks use SNMP.

>Customers will to me things like, I use Lucent NavisCore 
>or some other marketing term for an EMS product

The most important word in the immediately above is "want".
But wanting to use SNMP for configuration is not the same as
practicing the use of SNMP for configuration.

>Internet Standard Management Framework, the BCP attempts to 
>show how things have progressed in the past ten years or so 
>and what works and what to watch out for and to some extent, 
>what the current 'thinking' is. 

This appears to be an accurate description of the document.
It is the current 'thinking' of those who advocate the SNMP framework.
The practical point of Best Current Practice is that it requires
people actually doing something well at present, not wanting to in
the future.

John

---

From: "David T. Perkins" <[email-masked]>
Date: Mon, 14 Jan 2002 13:46:27 -0800

HI,

I want to clarify a misperception that is in John's message...

>features through SNMP, not configuring the network through SNMP.
RMON is not a creature of SNMP. (There was a lot of marketing
several years back trying to make such a claim.) RMON probes
are devices that monitor network traffic (and capture packets),
and allow management applications to get the statistics on the
traffic. Such devices could be created that used proprietary
protocols for configuring them and for retrieving stats and packets.
Remote monitoring probes existed before SNMP was used to
manage them.

Regards,
/david t. perkins

---

From: "Jon Saperia <saperia>" <[email-masked]>
Date: Mon, 14 Jan 2002 17:21:19 -0500

> recommend. ;-) I was told somebody asked for them.

What we are talking about are practices for use of SNMP in a configuration 
management context. What is in the document are approaches that have been 
found to work when want wants to do configuration management with SNMP. So 
while one may or may not like SNMP in general, or for configuration in 
particular, the document is only about practices that have been found 
helpful when one wants to use SNMP for configuration. Nothing more. As 
such I believe it meets the requirements for BCP as I read RFC2026. 

If you believe it does not, please cite why and the text in context from 
2026 that shows that this document would be inappropriately called a BCP.

/jon
-- 
Jon Saperia                         
				
[email-masked]
Phone: 617-744-1079
Fax:   617-249-0874
http://www.jdscons.com/

---

From: "Wayne F. Tackabury" <[email-masked]>
Date: Mon, 14 Jan 2002 18:52:59 -0500

>recommend. ;-) I was told somebody asked for them.

John:

I'm not sure if you're trying to be facetious, but I think at this point 
your assertion that there are no applications of doing configuration and 
activation using SNMP, no applications that one can interpret a set of best 
practices for (to perhaps facilitate even more and better and more scalable 
etc. usage going further) have been pretty well shot down.

I was going to add one more--MPLS optical switches which do LSP setup and 
traffic engineering over LSPs using SNMP-created rows.  Early adopters have 
done this around in-progress versions of the MIBs currently under IESG 
review.  I know of one vendor (Tenor Networks) that uses that as a selling 
point for their management strategy.  The BCP has looked at design 
techniques for the kind of MIBs these devices are shipping and identified 
the most scalable desig...well, you've read the document, you know what 
it's about.  If these MIBs are *shipping and in deployment now*, how can 
you claim that guidance on MIB design for their ilk doesn't address a 
*current practice*?

Regards,
Wayne

---

From: John Schnizlein <[email-masked]>
Date: Mon, 14 Jan 2002 19:56:54 -0500

At 06:52 PM 1/14/2002, Wayne F. Tackabury wrote:

>... I think at this point your assertion that there are no 
>applications of doing configuration and activation using SNMP, 
>no applications that one can interpret a set of best practices 
>for (to perhaps facilitate even more and better and more scalable 

I have not made such an assertion.
I have just asked, without anyone answering, for the name of a
single network operator who configures their network with SNMP.

If configuring through SNMP is not any operator's practice, how
can it be a best practice? The question is not about the existence
of applications, but the operational use of practices.

Since when is shooting down a goal of an IETF WG?

>Early adopters have done this around in-progress versions of 
>the MIBs currently under IESG review.  I know of one vendor 
>(Tenor Networks) that uses that as a selling point for their 
>management strategy.  

In-progress MIBs as a selling point of a vendor's strategy does
not make a Best Current Practice, it makes a marketing strategy.

John

---

From: Michael MacFaden <[email-masked]>
Date: Mon, 14 Jan 2002 20:42:17 -0800

>practicing the use of SNMP for configuration.

Agreed. I'm sure want does not infer a CLI then either.

Most 'want' a simple GUI that will contain some smarts
the operator doesn't have and that often means an EMS which means
programmatic access, which then leads to SNMP/TL1,etc.

Here is one user you could go ask,
http://www.asiaglobalcrossing.com/products_services/ds_framerelay.htm
Last published report I read said they had thousands of cisco edge 
routers and a hundreds of Junipers in the core.

Now if we went around asking for what everyone *wants*,
my guess would be something like this:

a) provide simple technology to begin with aka 'disk drive' 
   as Randy mentioned so all one needs to set is the ide jumper 
   and install it, no monitoring other than having to listen to 
   the blasted thing wheeze and deal with corrupt filesystems or disk 
   full conditions and the occaisonal backup.
   No MEDS, no LocalPrefs, no Communities to worry about or
   interoperability issues with other disk drives.

b) vendor provided free highly skilled engineer 
   to hunker down over a CLI and keep those pesky 
   protocols and devices going so their service remains intact.

Mike MacFaden

---

From: Randy Bush <[email-masked]>
Date: Mon, 14 Jan 2002 18:12:41 -0800

> people actually doing something well at present, not wanting to in

i think you could say this is the best current practice if you use
snmp for configuration.  and it should mention that, unfortunately,
very few folk use snmp for configuration and almost all use snmp
for monitoring.

randy

---

From: David Partain <[email-masked]>
Date: Tue, 15 Jan 2002 09:06:59 +0100

Hi,

Regarding the discussion of whether the BCP should be a BCP,
I would like to quote RFC 2026 "The Internet Standards Process
-- Revision 3", page 16, in the middle of the page:

   The BCP subseries of the RFC series is designed to be a way to
   standardize practices and the results of community deliberations.  A
   BCP document is subject to the same basic set of procedures as
   standards track documents and thus is a vehicle by which the IETF
   community can define and ratify the community's best current thinking
   on a statement of principle or on what is believed to be the best way
   to perform some operations or IETF process function.

I think, given statements like "the community's best current
thinking" and "what is believed to be the best way to perform
some operations", that our "BCP" certainly qualifies to be
called a "BCP".  The document identifies what "is believed to
be" the best way to do configuration with SNMP and represents
the SNMP communities "best current thinking" on how to do that.

I understand that there are people who don't think that
SNMP _should be_ or _is_ used for configuration.  I do think,
though, that various mail sent recently adequately demonstrates
that SNMP is used for configuration even if not even close
to ubiquitously.  That doesn't seem to me to be the question,
though.  Does this document represent "what is believed to be
the best way to perform some operations" and "the community's
best current thinking" about SNMP-based configuration?
I believe so.

Cheers,

dlp