[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: snmpconf BCP-07 vs configuration management

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.


> Hi Randy...
> At 04:28 PM 11/28/2001 -0800, rpresuhn-lists@dorothy.bmc.com wrote:
> >  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.
> 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


Jon Saperia		     saperia@jdscons.com
			     Phone: 617-744-1079
			     Fax:   617-249-0874