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

snmpconf Re: ANNOUNCEMENT: WG last call on draft-ietf-snmpconf-bcp-06.txt

At 11:17 AM 9/6/2001, David Partain wrote:
>This mail is to announce the beginning of the Working Group
>Last Call period on this document. The WG Last Call period
>will last until October 6, 2001.
>The WG members are strongly urged to review this document as
>soon as possible, and express any concerns, or identify any
>errors, in e-mail sent to the SNMPCONF WG mailing list.

One of the early promises in WG discussion was identification of
how production networks that actually use SNMP for configuration.
To support the (implied) claim that this is common in section 6,
at least some such networks should be identified. Did I just miss
this on the mailing list? Or when was it posted?

>> Network devices are configured using many mechanisms, however two 
>> methods remain the most common: SNMP and Command Line Interface (CLI).

An issue which was framed more crisply in the Policy Framework WG, but
still applies here because policy configuration is advocated, is the need
to control which persons can modify (possibly even read) which 
configuration items. It is well known that different persons or teams
are responsible for different configuration parameters on production
networks. It is not clear from the relevant section how different user's
access is controlled to different items. For example, where is the
control information stored?

>> 6.4.  Sensitive Information Handling
>> Some MIB modules contain objects that may contain data for keys, 
>> passwords and other such sensitive information and hence must be 
>> protected from unauthorized access.

How can the "new SNMPCONF technology" be the subject of "best practice"
without distorting the very idea that technology has been already found
effective in practice?

>> A common practice used to move large amounts of data that some vendors
>> employ involves using SNMP as a control channel in combination with
>> other protocols defined for transporting bulk data. This approach is
>> sub-optimal since it raises a number of security and other concerns.
>> Transferring large amounts of configuration data via SNMP can be 
>> efficiently performed with several of the techniques described earlier 
>> in this document. This policy section shows how even greater efficiency 
>> can be achieved using the new SNMPCONF technology. 

Please do not simply repeat the refrain that these fundamental problems
have been addressed already, or that they are (surprisingly) appearing
only at the last-call stage of discussion. It appears they have not yet
been actually resolved.