Subject: snmpconf BCP-07 vs configuration management

From: [email-masked]
Date: Wed, 28 Nov 2001 16:28:06 -0800 (PST)

Hi -

The -07- version of the BCP seems much improved in comparison
to earlier versions.

However, it still doesn't do justice to some of the
central issues of configuration management.  (as defined in
http://www.itil.co.uk/online_ordering/itil_glossary.htm ) For
example, though the document spends quite a bit of time on the
transaction concept, only one sentence in section 5 (2) seems
to even touch on the issue of versioning of configurations,
and almost nothing on the concept of identifying configurations.

I think it would be worthwhile to provide a higher-level
view by including more of the concepts from ITIL, at least
by reference.  Otherwise, it has more of the flavor of a
tutorial on how to implement SNMP, rather than a compendium of
best current practice for the use of SNMP for configuration
management.  Does the best current practice really have so
far to go?

I propose adding the references to the ITIL definitions
to section 1.2, and extending section 2 by adding another
subsection dealing with identification and versioning of
configurations using SNMP.  Section 5 should be expanded
so that point (2) in the first paragraph is sytematically
addressed, particularly since this can interact with the
persistance / activation mechanisms discussed in 3.7+

 ------------------------------------------------------
 Randy Presuhn          BMC Software, Inc.  1-3141
 [email-masked]  2141 North First Street
 Tel: +1 408 546-1006   San José, California 95131  USA
 ------------------------------------------------------
 My opinions and BMC's are independent variables.
 ------------------------------------------------------

---

From: Michael MacFaden <[email-masked]>
Date: Wed, 28 Nov 2001 17:41:34 -0800

>and almost nothing on the concept of identifying configurations.

I agree versioning configurations is a very important part 
of the configuration process. In my experience, that has
been done outside of scope of the Internet Standard
Managment Framework and is very well understood.

We BCP editors did discuss how difficult it is to get a configuration
off a device using SNMP, and that writing a generic configuration
extraction tool for an arbitrary device is impractical. 
Jon did mention to me a nice solution to this problem but 
it has not been defined yet as a standards track MIB module. 

>management.  Does the best current practice really have so

My goal was enumerate good and contrast with not so good
implementation mechanisms and processes that directly involve
components of the management framework. 
If this level of knowledge is not achieved and implemented,
then any higher level view of configuration won't be of much use 
to the practitioner. I'm not against adding some references to 
some higher model(s), it is just not the case everyone subscribes 
to the same models.  

For example from your glossary: "Expert User" See 'Super User' 
Give me a break.  'Super user' is just a particular account on a *nix
box right? (I'm not kidding). And I've never seen 
'Super Users' be required to do first line support
in an organisation that wants to retain them. 

>configurations using SNMP.  

I just haven't seen any systems in practice given the scope
described above. For CLI methods of configuration, this 
is the one pattern I've seen used most:
   http://www.shrubbery.net/rancid

>Section 5 should be expanded

Maybe the sample MIB module could be used to provide
such a secenario?

Regards,
Mike

---

From: Jon Saperia <[email-masked]>
Date: Thu, 29 Nov 2001 07:51:39 -0500

Mike and Randy,

I think the interpretation that Mike has about the scope of what we
wanted to accomplish in the BCP is accurate. I also agree that the
versioning, while interesting and important is generally outside the
domain of the SNMP portion of the managed system.

All that said, I like Randy's idea of putting in the reference. That way
if people read this document and want to learn 'more advanced' topics
they can do so from the pointer. What we could do is add a paragraph in
section 1.2 as Randy suggests. Specifically, we could add
a paragraph at the end of 1.2, something like:

  "Configuration management of networked systems is complex area.The
  focus of this document is on effective design and usage of the SNMP
  with regard to configuration activities. Many of the configuration
  concepts in this document are broadly useful and would be appropriate
  to consider in any configuration management system regardles of the
  form of the configuration data. Because of the focus of this document,
  there are topics related to configuration that are broader in scope
  than this document that one might wish to read before attempting the
  design or implemetation of any configuration management system
  [ITIL]."

Or something like that. Randy if you would like to reword this, that is
OK as well.

/jon

> Maybe the sample MIB module could be used to provide

Thanks,
/jon
--

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

---

From: "Wayne F. Tackabury" <[email-masked]>
Date: Thu, 29 Nov 2001 12:13:46 -0500

Hi Randy...

At 04:28 PM 11/28/2001 -0800, [email-masked] wrote:
>  For

Well, for my own contribution on this, my professional affiliation might 
make discussing the right way to do configuration versioning a, uh, 
conflict of interest. :)

No, seriously, you'll notice that in a prior version (don't bother digging 
it out, just take my word for it) we had this involved pseudo-state-machine 
for configuration deployment which included this very task area (archival) 
as an important step, with certain detail.  We took that out, mostly 
because it seemed that the readership was evenly split between having that 
deployment roadmap/state machine either not matter to them, or having it 
give them migraines.

Since we have in fact retained the separate "Deployment and Security 
Issues" section though, I think that text like what Jon proposed is 
appropriate for that section.  Independent of ITIL's take on the matter 
(which, although valid and defensible, does appear to have a fairly 
subjective point of view and isn't what I'd call 'normative'), I would 
enhance it with a few other practical points..

First of all, there's the notion of simply version identification (perhaps 
we could add that into whatever section we have in Section 3 about 
including last modified stamps as MIB table row design?).

In practical usage, though, there are considerations for how one does 
config version *archival* (forgive me if I'm driving a lot further down the 
road than you intended, but I think it's vitally pertinent, no?).  In 
modern practice, that's generally about storage of a CLI-based 
configuration, using homebrew scripting or something a la Rancid or the 
Gold Wire Formulator product.  The most common usage, or certainly the 
simplest, is to treat the unit of archival (CLI or the results of a MIB 
walk) as opaque with respect to the archival itself.  An interesting 
operational point, however, is that the connection between the SNMP 
configuration and the CLI isn't always direct (mostly meaning, the way the 
management information is structured is often not the same between a 
config-savvy MIB module and the CLI bits covering the same function), but 
the same changes should have the same effect (i.e., tweak the CLI--it may 
have a nonobvious change in the config as reported by SNMP, but make the 
same CLI tweak again, and the same change should be evident).

Finally, there are devices that don't actually *lend* themselves to having 
a complete "config" for archival as such.  A cable modem is the main 
example that comes to mind.  DOCSIS specifies that I can set a 
configuration in bulk, but I can't retrieve a configuration in bulk.  The 
practical upshot of this is that one needs to scope the configuration one 
cares about in the version archival practice, and implement it carefully 
into the management application.

Anyways, thanks much for your thoughtful review of the BCP.

Regards,
Wayne

---

From: Jon Saperia <[email-masked]>
Date: Thu, 29 Nov 2001 13:32:51 -0500

My take on this is that I think Randy's view about the broad nature of
configuration management is a reasonable one. As I indicated before, I
do not what to extend the scope of what we have written too much. Wayne
was expressing a similar concern in terms of configuration files
etc. Getting the BCP to this point has taken some work and to extend it
is probably not appropriate since we are focused on SNMP mechanims and
not configuraitonin general. 

If we can agree on pointers for other important topics, I think it would
be fine to include them along with a paragraph such as the one I
proposed however modified to reach consensus. I would not want to extend
the scope of the BCP at this point though.

/jon

Thanks,
/jon
--