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

From: "Harrington, David" <[email-masked]>
Date: Mon, 14 Jan 2002 15:56:39 -0500

> when you have to scale, tweaking single devices is just not on.

Which is where using an application helps to automate and coordinate the
process. CLI scripting is one way to automate the process, but SNMP
applications are much more able to respond to a wide variety of differences
or changes in the environment, and apply appropriately adjusted
configurations to multiple devices.

dbh

> -----Original Message-----
> From: Randy Bush [mailto:[email-masked]]
> Sent: Monday, January 14, 2002 3:15 PM
> To: MacFaden, Mike
> Cc: [email-masked]
> Subject: Re: Review of draft-ietf-snmpconf-bcp-07
> 
> 
> > 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.
> 
> when you have to scale, tweaking single devices is just not on.  the
> canonic configuration is on a disk drive.
> 
> randy
>

---

From: "Glenn Waters"<[email-masked]>
Date: Tue, 15 Jan 2002 10:24:58 -0500

> From: David Partain [mailto:[email-masked]]
> Sent: Tuesday, January 15, 2002 3:07
> To: [email-masked]

[...]
 
> 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 think that some clarification from the standards gurus is called for here.

Point 1:

My rough understanding of BCP is that it describes the best way to perform
an existing practice.

The term *thinking* implies something that *may not* be in use and hence is
not a "Practice".

As I said in my review I find that some of the document does indeed describe
in use practices. I think other parts of the document (particularly sections
4 and 5) are somewhat experimental and/or informational in nature.

Point 2:

My rough understanding of BCP is that it describes something that is
commonly accepted. I think that many parts of the document describe
interesting stuff but the stuff is not commonly accepted and hence not
"Best" and possibly not "Current" (but it is a "Practice")

Enough said on this. Standards gurus go to work on this one.

Cheers, /gww

---

From: [email-masked]
Date: Wed, 16 Jan 2002 12:50:40 +0530

I would like to share some of my experience with SNMP for
  configuration. I am working in developing the management solution for
softswitches
   in a carrier grade environment. SNMP is being used as the management
protocol.

  Customer input especially for embedded solutions look for
  minimal configuration at run time on the EMS. Most of the SNMP  object
  have pre-defined default values and the configuration gets done
  during startup or is read from a persistent storage file. SNMP
   is used majorly for monitoring and SNMP traps.

   For OEM/Switches SNMP makes more sense as a configuration
  interface. For service provider  segment  file based configuration
  profiles are more widely used and SNMP is used for monitoring.

   --
   harish

---

From: "Tom Petch" <[email-masked]>
Date: Thu, 16 Jan 2003 17:59:48 -0000

The router manufacturer supplied the GUI tool (running under
Windows) which generated both a script file which could be
run as a sort of CLI and an 'online' download using SNMP and
it was the latter we used.  This meant it was easy to
implement change control and backout if and when things went
wrong at 0600 on Sunday morning, with a central database of
current and historic configurations.  SNMP download is so
easy that a half-asleep, inexperienced human could get it
right.  I never even saw an OID (apart from a trace taken
from curiosity) although I did have to select and specify
community names and enable the appropriate UDP ports (UDP is
bad news in a secure environment).  I did wonder at what
level the objects operated, like was it 'when I write to
this, take it and execute it as if it had come from an API
or CLI' as opposed to having a separate variable name for eg
set port 2/7 to FDX.

SNMP is v1 with security achieved by a hardened system using
standard techniques eg different networks with different
levels of trust separated by firewalls, users could not
introduce their own code to workstations (no A-drive,
regular scans of C-drive for unexpected executables), making
IP addresses trustworthy (DHCP a four-letter word, LAN ports
disable on change of MAC address), extensive logging of
anything that might be an attempted hack etc etc

Tom Petch, Network Consultant
[email-masked]
+(44) 192 575 3018
-----Original Message-----
From: John Schnizlein <[email-masked]>
To: [email-masked] <[email-masked]>
Date: 15 January 2002 17:11
Subject: Re: Review of draft-ietf-snmpconf-bcp-07

>At 07:23 AM 1/15/2003, you wrote:
>>I have made extensive use of SNMP to configure routers; in
>>fact, I've known it be the standard way of doing it once
the
>>initial IP/SNMP support is configured into the router.
This
>>is in a high availability, high security environment,
using
>>vendor-provided tools and (of course) vendor proprietary
>>MIB.
>
>Are you using SNMPv3? How do you manage keys?
>How do you control which administrators can write which
variables?
>Could you please identify the router and vendor-provided
tools?
>
>>But I am talking Enterprise, not Operator, which is why I
>>stayed quiet at Salt Lake City.
>
>Whoever operates the network is what matters, not whether
it is
>a commercial service provider or within an enterprise.
>
>>Tom Petch, Network Consultant
>>[email-masked]
>
>
>John
>
>