Internet Engineering Task Force Shimin Ban, Ed. Internet-Draft Hangzhou H3C Tech. Co., Ltd Intended status: Standards Track Shimin Ban, Ed. Expires: April 9, 2010 Hangzhou H3C Tech. Co., Ltd October 8, 2009 Backup and Restore MIBs draft-shimin-opsawg-snmp-backuprestore-mib-01 Status of This Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 9, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Ban Expires April 9, 2010 [Page 1] Internet-Draft Backup and Restore MIBs October 2009 Abstract This memo defines a portion of the Management Information Base (MIB) for transferring files between a device and servers and managing the system files, specially image and configuration files. In particular, the managed objects can be used for configuration backup/restore and agent upgrade. Currently, there are several enterprise-specific MIBs for tranfering or managing files. The purpose of this memo is to define a standards-based solution to enable interoperability. Ban Expires April 9, 2010 [Page 2] Internet-Draft Backup and Restore MIBs October 2009 Table of Contents 1. Introduction ....................................................4 2. The Internet-Standard Management Framework ......................4 3. Terminology .....................................................4 4. Conventions .....................................................5 5. Structure of the MIB Modules ....................................5 5.1. Structure of the FILE-TRANSFER-MIB Module ..................6 5.1.1. ftProtocolCapabilities ..............................6 5.1.2. ftScheduleTable .....................................6 5.1.3. ftResultTable .......................................7 5.1.4. ftLogTableMaxSize ...................................7 5.1.5. ftLogTable ..........................................8 5.2. Structure of the SYSFILE-MAN-MIB Module ....................8 5.2.1. sfmLocalDateAndTime .................................8 5.2.2. sfmSaveConfig and sfmSavedFileName ..................8 5.2.3. sfmRunningLastChanged and sfmRunningLastSaved .......9 5.2.4. sfmConfigFileTable ..................................9 5.2.5. sfmImageTable .......................................9 5.2.6. sfmCurrentTable .....................................9 5.2.7. sfmResetWithReloadIndexOrZero .......................9 5.2.8. sfmReloadScheduleTable .............................10 5.2.9. sfmReloadErrorTable ................................10 6. Relationship to Other MIB Modules ..............................11 7. Definitions ....................................................11 7.1. FILE-TRANSFER-MIB Definitions .............................11 7.2. SYSFILE-MAN-MIB Definitions ...............................30 8. Usage Examples .................................................47 8.1. To backup a config file at once ...........................48 8.2. To restore the running config at specified time ...........49 8.3. To upgrade agent at once ..................................49 8.4. To reboot the system conditionally ........................50 9. Security Considerations ........................................51 10. IANA Considerations ...........................................52 11. References ....................................................53 11.1. Normative References ....................................53 11.2. Informative References ..................................53 Authors' Addresses ................................................53 Ban Expires April 9, 2010 [Page 3] Internet-Draft Backup and Restore MIBs October 2009 1. Introduction The image and configuration file are the most important files for the devices. In most cases the management station need to backup, restore and upgrade them. For example, the management station might want to deploy the same configuration file to many switches that have the same hardware so that they have identical module and port configurations. In present although many vendors provide support to these operations, the degree of support are different. Also the solutions are lack of interoperability. It brings inconvenience to network management. This document defines two SNMP MIB modules to perform configuration backup/restore and agent upgrade operations. The file transfer MIB is used to control file transfer. The system file management MIB is used to manage the system files, mainly configuration files and images. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 3. Terminology Some new terms are used throughout this document: o Configuration The set of parameters in network elements and other systems that determine their function and operation. Generally the configuration information is kept in command lines in text format. There are two types of configuration: startup configuration and running configuration. For simplification reason 'configuration' is also refered as 'config' in this document. o Startup Config A config file used for initialization when the device boots. Ban Expires April 9, 2010 [Page 4] Internet-Draft Backup and Restore MIBs October 2009 o Running Config Refering to the current config running in the device. The running config MAY include the startup config if the startup config is not modified during system operation, and it also includes the new config added during the system operation. Generally the running config is stored in the temporary storage medium of the device, and will be lost when the device reboots without save. o Image File Essential file of the operating system, which forms base functionality of the device. o Configuration Backup Backuping a config file from the device to other servers in the network. o Configuration Restore Restoring the backup config file from other servers in the network. o Agent Upgrade Upgrading the agent with an image in the other servers in the network. 4. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 5. Structure of the MIB Modules This document defines two MIB modules: o FILE-TRANSFER-MIB Defines MIB objects which provide a way to transfer files between the backup servers and the device. o SYSFILE-MAN-MIB Defines MIB objects which provide a way to manage the system file, especially configuration and image file. This MIB module also provides a way to reload an entity or the entire system. Specially, working together the two MIB modules can be used to backup/restore the configuration files and upgrade agent. The following table lists the main operations which can be performed by the two MIB modules. Ban Expires April 9, 2010 [Page 5] Internet-Draft Backup and Restore MIBs October 2009 +------------------------------------------------------------+ | | to server | from server | +------------------------------------------------------------+ |config file |Backup config file |Restore config file. | +------------------------------------------------------------+ |running config|Backup running config|Restore the whole or | | | |part of running config.| +------------------------------------------------------------+ |image |Backup image |Agent upgrade. | +------------------------------------------------------------+ 5.1. Structure of the FILE-TRANSFER-MIB Module The FILE-TRANSFER-MIB consists of the following components: o ftProtocolCapabilities o ftScheduleTable o ftResultTable o ftLogTableMaxSize o ftLogTable 5.1.1. ftProtocolCapabilities The object ftProtocolCapabilities indicates the protocols that are implemented by the device to transfer files. To use file transfer mib, the agent SHOULD support at least one of TFTP, FTP, SFTP, RCP or SCP protocols. 5.1.2. ftScheduleTable This table is used to define the file-transfer task. The NMS wishing to create a task SHOULD generate a random serial number to be used as the index to this sparse table. Once the appropriate instance of all the objects have been created, either by an explicit SNMP SET request or by default, the row status SHOULD be set to active to initiate the task. Note that this entire procedure SHOULD be initiated via a single SET request which specifies a row status of createAndGo as well as specifies valid values for the non-defaulted objects. Once the file-transfer task has been created (i.e. the ftScheduleRowStatus has been active), an entry of ftResultTable will Ban Expires April 9, 2010 [Page 6] Internet-Draft Backup and Restore MIBs October 2009 be created correspondingly and automatically in which ftResultScheduleState is 'ready'. Once the file transfer is running (i.e. the ftResultScheduleState is 'waiting ' or 'inProgress'), it cannot be stopped, modified and deleted. When the transfer completes, if ftScheduleSendCompletionTrap is 'true', a ftTransferCompletion notification will be sent. The NMS SHOULD query the transfer state via ftResultScheduleState, and then delete the task. In order to prevent old entries from clogging this table, entries will be aged out. But an entry SHOULD never be deleted within 5 minutes of completion. When the entry in this table is deleted, the corresponding entry in ftResultTable SHOULD also be deleted in the same time. 5.1.3. ftResultTable This table is used to hold the results of file-transfer requests. It has the same index as ftScheduleTable. Once the file-transfer task has been created (i.e. the ftScheduleRowStatus has been active), the system will create an entry in this table correspondingly with the same index as the ftScheduleEntry and in which the ftResultScheduleState is 'ready'. Once the transfer completes, the NMS SHOULD query its state via ftResultScheduleState, and then delete the entry. Once a entry in ftScheduleTable is deleted, the corresponding entry in this table SHOULD also be deleted in the same time. 5.1.4. ftLogTableMaxSize The object ftLogTableMaxSize controls how many entries are held in the ftLogTable. A particular setting does not guarantee that there is sufficient memory available for the maximum number of table entries indicated by this object. A value of zero means not logging file-transfer operation. If an application reduces the limit while there are log messages in the ftLogTable, the log messages that are in the ftLogTable for the longest time MUST be discarded to bring the table down to the new limit. Ban Expires April 9, 2010 [Page 7] Internet-Draft Backup and Restore MIBs October 2009 5.1.5. ftLogTable This table is used to hold log information of file-transfer requests. The object ftLogTableMaxSize controls how many entries are held in this table. 5.2. Structure of the SYSFILE-MAN-MIB Module The SYSFILE-MAN-MIB consists of the following components: o sfmLocalDateAndTime o sfmSaveConfig o sfmSavedFileName o sfmRunningLastChanged o sfmRunningLastSaved o sfmConfigFileTable o sfmImageTable o sfmCurrentTable o sfmResetWithReloadIndexOrZero o sfmReloadScheduleTable o sfmReloadErrorTable 5.2.1. sfmLocalDateAndTime The object sfmLocalDateAndTime is used to display the current local date and time of the system. It's writable and through it the system's date and time can be modified. 5.2.2. sfmSaveConfig and sfmSavedFileName The object sfmSavedFileName specifies the file name used to save. The NMS can save the running config at once via sfmSaveConfig object. The two objects can work together, but it's not required. If the sfmSaveConfig object is set individually, the system SHOULD check sfmSavedFileName before saving the running config. If its value is valid, the system SHOULD save the running config to the file named by sfmSavedFileName. Otherwise, the system SHOULD save the running Ban Expires April 9, 2010 [Page 8] Internet-Draft Backup and Restore MIBs October 2009 config to the default file, for example, the current startup config. If the two objects are both set in a PDU, the system SHOULD save the running config to the file specified by sfmSavedFileName. The value of sfmSavedFileName object SHOULD be cleared after used. 5.2.3. sfmRunningLastChanged and sfmRunningLastSaved The object sfmRunningLastChanged indicates when the running config was last changed. The object sfmRunningLastSaved indicates when the running config was last saved. If the value of sfmRunningLastChanged is greater than sfmRunningLastSaved, that means the running config has been changed but not saved yet. 5.2.4. sfmConfigFileTable The table is used to hold the configuration file information. The NMS can rename a config file through sfmConfigFileName object and specify a config file as the startup config by setting the value of sfmConfigFilePRI to 'primary'. 5.2.5. sfmImageTable The table is used to hold the image information. The NMS can rename an image through sfmImageName object and specify an image as the startup image by setting the value of sfmImagePRI to 'primary'. 5.2.6. sfmCurrentTable The table is used to provide information about the files being used by the system, mainly for the config files and images. If the value of SystemFileType is 'config', the value of sfmCurrentFileIndexOrZero identifies the config file specified by the same value of sfmConfigFileIndex. If the value of SystemFileType is 'image', the value of sfmCurrentFileIndexOrZero identifies the image specified by the same value of sfmImageIndex. If the value of SystemFileType is 'other' or 'unknown', the value of sfmCurrentFileIndexOrZero SHOULD be zero. 5.2.7. sfmResetWithReloadIndexOrZero With the object sfmResetWithReloadIndexOrZero the NMS can reset the system at once. Ban Expires April 9, 2010 [Page 9] Internet-Draft Backup and Restore MIBs October 2009 If sfmResetWithReloadIndexOrZero is set to zero, the system will be reset at once with the startup config and image. The files here MAY be not the ones held in sfmCurrentTable because the file priority can be changed via sfmConfigFilePRI or sfmImagePRI. If sfmResetWithReloadIndexOrZero has a non-zero value, it means that the reload task specified by the same value of sfmReloadIndex will be used. That is, the system will be reset at once with the config file and image specified in the task, regardless of sfmReloadScheduleTime. If there is no such task or there is an invalid parameter in the task, an error will be returned. 5.2.8. sfmReloadScheduleTable This table is used to define the system reload task. The NMS wishing to create a reload task SHOULD generate a random serial number to be used as the index to this sparse table. Once the appropriate instance of all the objects have been created, either by an explicit SNMP SET request or by default, the row status SHOULD be set to active to initiate the task. Note that this entire procedure SHOULD be initiated via a single SET request which specifies a row status of createAndGo as well as specifies valid values for the non-defaulted objects. Before reload the system will check the parameters of the task. If there is an invalid parameter, for example, the specified image or config file not exist, the reload won't be executed. Then the system will create a sfmReloadErrorEntry with the same index as the task. And if sfmReloadSendErrorTrap is 'true', a smfReloadError notification will be sent. The NMS can query sfmReloadErrorTable to get the detailed error information about the reload. In order to prevent old entries from clogging the table, entries will be aged out. When the entry in this table is deleted, the corresponding entry in sfmReloadErrorTable SHOULD also be deleted in the same time. 5.2.9. sfmReloadErrorTable The table is used to hold the error information of system reload. Before reload the system will check the parameters of the task. If there is an invalid parameter, for example, the specified image or config file not exist, the reload won't be executed. Then a new entry of sfmReloadErrorEntry will be created. And if the value of sfmReloadSendErrorTrap is 'true', a smfReloadError notification will Ban Expires April 9, 2010 [Page 10] Internet-Draft Backup and Restore MIBs October 2009 be sent. The table has the same index as sfmReloadScheduleTable. To get the detailed error information, the NMS SHOULD query this table with the corresponding value of sfmReloadIndex after receiving smfReloadError notification. In order to prevent old entries from clogging the table, entries will be aged out. But an entry SHOULD never be deleted within 5 minutes of error occurring. When the entry in sfmReloadScheduleTable is deleted, the corresponding one in this table SHOULD also be deleted in the same time. 6. Relationship to Other MIB Modules The ENTITY-MIB [RFC4133] meets the need for a standardized way of representing a single agent, which supports multiple instances of one MIB. It can express a certain relationship between multiple entities, and provide entity properties for each entity. The ENTITY-MIB MAY be used if the NMS needs to get the information about the entity to be reloaded or in which the configuration files or images reside. Therefore, the agent is expected to maintain the value of sfmConfigFilePhysicalIndex or sfmImagePhysicalIndex object with the same value of entPhysicalIndex identifing the entity in which the files reside. The FILE-TRANSFER-MIB module IMPORTS objects from SNMPv2-SMI [RFC2578], SNMPv2-TC [RFC2579], SNMPv2-CONF [RFC2580], and INET-ADDRESS-MIB [RFC3291]. The SYSFILE-MAN-MIB module IMPORTS objects from SNMPv2-SMI [RFC2578], SNMPv2-TC [RFC2579], SNMPv2-CONF [RFC2580], and ENTITY-MIB [RFC4133]. 7. Definitions 7.1. FILE-TRANSFER-MIB Definitions FILE-TRANSFER-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, mib-2, TimeTicks, NOTIFICATION-TYPE FROM SNMPv2-SMI DisplayString, TruthValue, RowStatus, TEXTUAL-CONVENTION, DateAndTime FROM SNMPv2-TC Ban Expires April 9, 2010 [Page 11] Internet-Draft Backup and Restore MIBs October 2009 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF InetAddressType, InetAddress FROM INET-ADDRESS-MIB; fileTransferMIB MODULE-IDENTITY LAST-UPDATED "0910020000Z" ORGANIZATION "IETF OPSAWG Working Group" CONTACT-INFO "Shimin Ban Oriental Electronic Bld., No.2, Chuangye Road, Shang-Di Information Industry Base, Hai-Dian District, Beijing, China(100085) Email: banshimin@h3c.com" DESCRIPTION "Copyright (C) 2009 The Internet Society. This version of the MIB module is part of RFC xxxx; see the RFC itself for full legal notices. This MIB module defines MIB objects which provide a way to transfer files between the backup servers and the device. Working with SYSFILE-MAN-MIB, this MIB module can be used: (1) to backup/restore the configuration files. (2) to upgrade agent. " REVISION "0910020000Z" DESCRIPTION "The initial revision, published as RFC xxxx" ::= { mib-2 xxx } ftMIBObjects OBJECT IDENTIFIER ::= { fileTransferMIB 1 } -- MIB contains two groups ftOperation OBJECT IDENTIFIER ::= { ftMIBObjects 1 } ftLog OBJECT IDENTIFIER ::= { ftMIBObjects 2 } -- Textual Conventions TransferFileProtocol ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The protocol that can be used to transfer the file through the network. tftp: Transfer File Transfer Protocol ftp: File Transfer protocol sftp: Secure File Transfer Protocol Ban Expires April 9, 2010 [Page 12] Internet-Draft Backup and Restore MIBs October 2009 scp: Secure Copy Protocol rcp: Remote Copy Protocol" SYNTAX INTEGER { tftp(1), ftp(2), sftp(3), scp(4), rcp(5) } TransferFileDirection ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The direction of the file transfer. fromServer: Transfer file from server to this device. toServer: Transfer file from this device to server." SYNTAX INTEGER { fromServer(1), toServer(2) } TransferFileType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "With 'commonFile' this MIB can be used to transfer any type of files between the server and the device. With 'startupConfigFile' and 'runningConfigFile' this MIB can be used to backup the agent-config files to the server or restore from the server. With 'imageFile' this MIB can be used to backup the image file to the server or upgrade the agent from the server. commonFile: A file other than the following types. startupConfigFile: A startup config file. runningConfigFile: A running config file. imageFile: A base file of the device which forms base functionality. " SYNTAX INTEGER { commonFile(1), startupConfigFile(2), runningConfigFile(3), imageFile(4) } Ban Expires April 9, 2010 [Page 13] Internet-Draft Backup and Restore MIBs October 2009 TransferFileState ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The state of the file-transfer operation. The description of each state is given below: ready: After the task is created and before it's called, the state SHOULD be ready. waiting: For the device in which only one file-transfer task can be run at any time, a newly activated file-transfer task SHOULD be placed in this state if another task is running. inProgress: This state indicates that the file-transfer task is running. successful: The state when a file-transfer task is successfully completed. failed: The file-transfer task was unsuccessful." SYNTAX INTEGER { ready(1) waiting(2), inProgress(3), successful(4), failed(5) } LogSourceType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The source command which launched the file transfer. cli: Command line interface. snmp: Simple Network Management Protocol. other: Unknown source." SYNTAX INTEGER { cli(1) snmp(2), other(3) } -- operation group ftProtocolCapabilities OBJECT-TYPE SYNTAX BITS { tftp(0), ftp(1), sftp(2), scp(3), Ban Expires April 9, 2010 [Page 14] Internet-Draft Backup and Restore MIBs October 2009 rcp(4), } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the protocols that are implemented by this device to transfer files." ::= { ftOperation 1 } ftScheduleTable OBJECT-TYPE SYNTAX SEQUENCE OF FtScheduleEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of file-transfer tasks." ::= { ftOperation 2 } ftScheduleEntry OBJECT-TYPE SYNTAX FtScheduleEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A file-transfer task. The NMS wishing to create an entry SHOULD generate a random serial number to be used as the index to this sparse table. Once the appropriate instance of all the objects have been created, either by an explicit SNMP SET request or by default, the row status SHOULD be set to active to initiate the task. Note that this entire procedure SHOULD be initiated via a single SET request which specifies a row status of createAndGo as well as specifies valid values for the non-defaulted objects. Once the file-transfer task has been created (i.e. the ftScheduleRowStatus has been active), a ftResultEntry will be created correspondingly and automatically in which ftResultScheduleState is 'ready'. Once the file transfer is running (i.e. the ftResultScheduleState is 'waiting ' or 'inProgress'), it can not be stopped, modified and deleted. When the transfer completes, if ftScheduleSendCompletionTrap is 'true', a ftTransferCompletion notification will be sent. The NMS SHOULD query the transfer state via ftResultScheduleState, and SHOULD then delete the entry. In Ban Expires April 9, 2010 [Page 15] Internet-Draft Backup and Restore MIBs October 2009 order to prevent old entries from clogging the table, entries will be aged out. But an entry SHOULD never be deleted within 5 minutes of completion. When the entry in this table is deleted, the corresponding entry in ftResultTable SHOULD also be deleted in the same time." INDEX { ftScheduleIndex } ::= { ftScheduleTable 1 } FtScheduleEntry ::= SEQUENCE { ftScheduleIndex Integer32, ftScheduleProtocol TransferFileProtocol, ftScheduleServerAddressType InetAddressType, ftScheduleServerAddress InetAddress, ftScheduleServerPort Integer32, ftScheduleDirection INTEGER, ftScheduleUserName DisplayString, ftScheduleUserPassword DisplayString, ftScheduleSrcFileName DisplayString, ftScheduleDestFileName DisplayString, ftScheduleFileType TransferFileType, ftScheduleOverwriteSameFile TruthValue, ftScheduleSendCompletionTrap TruthValue, ftScheduleStartTime DateAndTime, ftScheduleRowStatus RowStatus } ftScheduleIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Specifies an unique entry in the ftScheduleTable. The NMS wishing to initiate a file-transfer operation SHOULD use a random value for this object when creating an instance of ftScheduleEntry." ::= { ftScheduleEntry 1 } ftScheduleProtocol OBJECT-TYPE SYNTAX TransferFileProtocol MAX-ACCESS read-create STATUS current DESCRIPTION "The protocol to be used for the file-transfer operation." DEFVAL { tftp } ::= { ftScheduleEntry 2 } ftScheduleServerAddressType OBJECT-TYPE SYNTAX InetAddressType Ban Expires April 9, 2010 [Page 16] Internet-Draft Backup and Restore MIBs October 2009 MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates the transport type of the address contained in ftScheduleServerAddress object." ::= { ftScheduleEntry 3 } ftScheduleServerAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The IP address of the server from (or to) which to transfer the file. The address format depends on the value of the ftScheduleServerAddressType object." ::= { ftScheduleEntry 4 } ftScheduleServerPort OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates the port number of the server. If the value is 0 or not specified, the known port number will be used." DEFVAL { 0 } ::= { ftScheduleEntry 5 } ftScheduleDirection OBJECT-TYPE SYNTAX TransferFileDirection MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates the direction of the file transfer." DEFVAL { fromServer } ::= { ftScheduleEntry 6 } ftScheduleUserName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..64)) MAX-ACCESS read-create STATUS current DESCRIPTION "The remote username for the file transfer via the protocol specified by the ftScheduleProtocol object. It's not required for the file-transfer via TFTP protocol." ::= { ftScheduleEntry 7 } Ban Expires April 9, 2010 [Page 17] Internet-Draft Backup and Restore MIBs October 2009 ftScheduleUserPassword OBJECT-TYPE SYNTAX DisplayString (SIZE (1..40)) MAX-ACCESS read-create STATUS current DESCRIPTION "Password used by the protocol for transferring a file to/from an server. Reading it returns a zero-length string for security reason. It's not required for the file-transfer via TFTP and RCP protocol." ::= { ftScheduleEntry 8 } ftScheduleSrcFileName OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-create STATUS current DESCRIPTION "The full path name of the source file. If there is no path information, the current directory will be used. If ftScheduleFileType is 'runningConfigFile' and ftScheduleDirection is 'toServer', that is, backuping the running config to the server, this object will be ignored." ::= { ftScheduleEntry 9 } ftScheduleDestFileName OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-create STATUS current DESCRIPTION "The full path name of the destination file. If there is no path information, the current directory will be used. If ftScheduleFileType is 'runningConfigFile' and ftScheduleDirection is 'fromServer', that is, restoring the running config with the backup file, this object will be ignored." ::= { ftScheduleEntry 10 } ftScheduleFileType OBJECT-TYPE SYNTAX TransferFileType MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates the type of file to transfer. Ban Expires April 9, 2010 [Page 18] Internet-Draft Backup and Restore MIBs October 2009 If the value of this object is 'runningConfigFile' and ftScheduleDirection is 'fromServer', that is, restoring the running config with the backup file, it's not required that the backup file is a whole configuration file. In fact the file can be a config segment which MAY only consist of several commands to perform a certain operation." ::= { ftScheduleEntry 11 } ftScheduleOverwriteSameFile OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "If there is the same name file in the destination directory, this object indicates whether or not it SHOULD be overwritten. If the value is 'false' and there is the same name file in the destination directory, the transfer will fail." DEFVAL { false } ::= { ftScheduleEntry 12 } ftScheduleSendCompletionTrap OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates whether or not a ftTransferCompletion notification SHOULD be issued on completion of the transfer." DEFVAL { true } ::= { ftScheduleEntry 13 } ftScheduleStartTime OBJECT-TYPE SYNTAX DateAndTime (SIZE(8)) MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates the local time at which the file transfer action will occur. The system SHOULD only take octet strings with length 8 for this object. The date-time specification is shown as follows: field octets content srange ----- ------ -------- ----- 1 1-2 year 0..65536 2 3 month 1..12 Ban Expires April 9, 2010 [Page 19] Internet-Draft Backup and Restore MIBs October 2009 3 4 day 1..31 4 5 hour 0..23 5 6 minutes 0..59 6 7 seconds 0..60 7 8 deci-seconds 0..9 For example, Tuesday September 15, 2009 at 1:30:15 PM would be returned as '07D9090F0D1E0F00'H and displayed as: 2009-9-15,13:30:15.0 If the object is set to '0000000000000000'H the task will be run immediately. If the object is set to 'FFFFFFFFFFFFFFFF'H or the set time is previous to sfmLocalDateAndTime, the task won't be run. If the object is set to any valid octet strings other than the above cases the task will be run at the specified time. The tasks which the value of this object is 'FFFFFFFFFFFFFFFF'H won't be deleted for ever. The NMS must delete them with RowStatus explicitly." ::= { ftScheduleEntry 14 } ftScheduleRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The row status object controls the creation/deletion of rows in this table. Its semantics are the same as those for the RowStatus textual convention specified for SNMPv2." ::= { ftScheduleEntry 15 } ftResultTable OBJECT-TYPE SYNTAX SEQUENCE OF FtResultEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of file-transfer requests result." ::= { ftOperation 3 } ftResultEntry OBJECT-TYPE SYNTAX FtResultEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Ban Expires April 9, 2010 [Page 20] Internet-Draft Backup and Restore MIBs October 2009 "The result entries of file-transfer requests. The table has the same index as ftScheduleTable. Once the file-transfer task has been created (i.e. the ftScheduleRowStatus has been active), the system SHOULD create an entry in this table correspondingly with the same index as ftScheduleEntry and in which the value of ftResultScheduleState SHOULD be 'ready'. Once the transfer completes, the NMS SHOULD query its state via ftResultScheduleState, and then delete the entry. Once a entry in ftScheduleTable is deleted, the corresponding entry in this table SHOULD also be deleted in the same time." INDEX { ftScheduleIndex } ::= { ftResultTable 1 } FtResultEntry ::= SEQUENCE { ftResultScheduleState TransferFileState, ftResultTransferTakenTime TimeTicks, ftResultTransferEndTime DateAndTime, ftResultErrDescr DisplayString } ftResultScheduleState OBJECT-TYPE SYNTAX TransferFileState MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the state of this file-transfer task. The value of this object will be dynamically changed with the transfer progress." ::= { ftResultEntry 1 } ftResultTransferTakenTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "Time taken for the file-transfer operation. This object is just like a stopwatch, starting when the transfer starts, stopping when the transfer completes." ::= { ftResultEntry 2 } ftResultTransferEndTime OBJECT-TYPE Ban Expires April 9, 2010 [Page 21] Internet-Draft Backup and Restore MIBs October 2009 SYNTAX DateAndTime (SIZE(8)) MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the local time at which the file-transfer operation completes. The system SHOULD only take octet strings with length 8 for this object. The date-time specification is shown as follows: field octets contents range ----- ------ -------- ----- 1 1-2 year 0..65536 2 3 month 1..12 3 4 day 1..31 4 5 hour 0..23 5 6 minutes 0..59 6 7 seconds 0..60 7 8 deci-seconds 0..9 For example, Tuesday September 15, 2009 at 1:30:15 PM would be returned as '07D9090F0D1E0F00'H and displayed as: 2009-9-15,13:30:15.0 " ::= { ftResultEntry 3 } ftResultErrDescr OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only STATUS current DESCRIPTION "If ftResultScheduleState is 'failed', the NMS can get the detailed error information about the task via this object. Reading this object SHOULD return a zero-length string if ftResultScheduleState is not 'failed'." ::= { ftResultEntry 4 } -- log group ftLogTableMaxSize OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of log messages that MAY be held in ftLogTable. Ban Expires April 9, 2010 [Page 22] Internet-Draft Backup and Restore MIBs October 2009 A value of zero means not logging file-transfer operation. If an application reduces the limit while there are log messages in the ftLogTable, the log messages that are in the ftLogTable for the longest time MUST be discarded to bring the table down to the new limit." DEFVAL { 50 } ::= { ftLog 1 } ftLogTable OBJECT-TYPE SYNTAX SEQUENCE OF FtLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table for logging file-transfer operation in device." ::= { ftLog 2 } ftLogEntry OBJECT-TYPE SYNTAX FtLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Log information of a particular file-transfer entry." INDEX { ftLogIndex } ::= { ftLogTable 1 } FtLogEntry ::= SEQUENCE { ftLogIndex Integer32, ftLogSoureType LogSourceType, ftLogProtocol TransferFileProtocol, ftLogServerAddressType InetAddressType, ftLogServerAddress InetAddress, ftLogServerPort Integer32, ftLogDirection INTEGER, ftLogUserName DisplayString, ftLogSrcFileName DisplayString, ftLogDestFileName DisplayString, ftLogFileType TransferFileType, ftLogState TransferFileState, ftLogTransferStartTime DateAndTime, ftLogTransferEndTime DateAndTime, ftLogTransferTakenTime TimeTicks, ftLogErrDescr DisplayString, ftLogComments DisplayString } ftLogIndex OBJECT-TYPE SYNTAX Integer32 Ban Expires April 9, 2010 [Page 23] Internet-Draft Backup and Restore MIBs October 2009 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Object which specifies an unique entry in the ftLogTable." ::= { ftLogEntry 1 } ftLogSoureType OBJECT-TYPE SYNTAX LogSourceType MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the source command which launched the file transfer." DEFVAL { tftp } ::= { ftLogEntry 2 } ftLogProtocol OBJECT-TYPE SYNTAX TransferFileProtocol MAX-ACCESS read-only STATUS current DESCRIPTION "The protocol to be used for this operation." DEFVAL { tftp } ::= { ftLogEntry 3 } ftLogServerAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the transport type of the address used by this operation." ::= { ftLogEntry 4 } ftLogServerAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The IP address of the server from (or to) which to transfer the file in this operation." ::= { ftLogEntry 5 } ftLogServerPort OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION Ban Expires April 9, 2010 [Page 24] Internet-Draft Backup and Restore MIBs October 2009 "The port number of the server used by this operation." ::= { ftLogEntry 6 } ftLogDirection OBJECT-TYPE SYNTAX TransferFileDirection MAX-ACCESS read-only STATUS current DESCRIPTION "The direction of this operation." DEFVAL { fromServer } ::= { ftLogEntry 7 } ftLogUserName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..64)) MAX-ACCESS read-only STATUS current DESCRIPTION "The remote username for the file transfer." ::= { ftLogEntry 8 } ftLogSrcFileName OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only STATUS current DESCRIPTION "The full path name of the source file." ::= { ftLogEntry 9 } ftLogDestFileName OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only STATUS current DESCRIPTION "The full path name of the destination file." ::= { ftLogEntry 10 } ftLogFileType OBJECT-TYPE SYNTAX TransferFileType MAX-ACCESS read-only STATUS current DESCRIPTION "The transferred file type." DEFVAL { false } ::= { ftLogEntry 11 } ftLogState OBJECT-TYPE SYNTAX TransferFileState MAX-ACCESS read-only Ban Expires April 9, 2010 [Page 25] Internet-Draft Backup and Restore MIBs October 2009 STATUS current DESCRIPTION "The state of the operation. The value of this object will be 'successful' or 'failed'. If it's 'failed', the NMS can get the detailed error information of the operation via ftLogErrDescr object." ::= { ftLogEntry 12 } ftLogTransferStartTime OBJECT-TYPE SYNTAX DateAndTime (SIZE(8)) MAX-ACCESS read-only STATUS current DESCRIPTION "The local time at which the operation starts. The system SHOULD only take octet strings with length 8 for this object. The date-time specification is shown as follows: field octets contents range ----- ------ -------- ----- 1 1-2 year 0..65536 2 3 month 1..12 3 4 day 1..31 4 5 hour 0..23 5 6 minutes 0..59 6 7 seconds 0..60 7 8 deci-seconds 0..9 For example, Tuesday September 15, 2009 at 1:30:15 PM would be returned as '07D9090F0D1E0F00'H and displayed as: 2009-9-15,13:30:15.0 " ::= { ftLogEntry 13 } ftLogTransferEndTime OBJECT-TYPE SYNTAX DateAndTime (SIZE(8)) MAX-ACCESS read-only STATUS current DESCRIPTION "The local time at which the operation completes. The system SHOULD only take octet strings with length 8 for this object. The date-time specification is shown as follows: Ban Expires April 9, 2010 [Page 26] Internet-Draft Backup and Restore MIBs October 2009 field octets contents range ----- ------ -------- ----- 1 1-2 year 0..65536 2 3 month 1..12 3 4 day 1..31 4 5 hour 0..23 5 6 minutes 0..59 6 7 seconds 0..60 7 8 deci-seconds 0..9 For example, Tuesday September 15, 2009 at 1:30:15 PM would be returned as '07D9090F0D1E0F00'H and displayed as: 2009-9-15,13:30:15.0 " ::= { ftLogEntry 14 } ftLogTransferTakenTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "Time taken for the operation." ::= { ftLogEntry 15 } ftLogErrDescr OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only STATUS current DESCRIPTION "If ftLogState is 'failed', the NMS can get the detailed error information about the task via this object. Reading this object SHOULD return a zero-length string if ftLogState is 'successful'." ::= { ftLogEntry 16 } ftLogComments OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only STATUS current DESCRIPTION "The comments for the operation." ::= { ftLogEntry 17 } -- File Transfer MIB Trap Definitions ftMIBNotifications OBJECT IDENTIFIER ::= { fileTransferMIB 2 } ftTransferCompletion NOTIFICATION-TYPE Ban Expires April 9, 2010 [Page 27] Internet-Draft Backup and Restore MIBs October 2009 OBJECTS { ftScheduleIndex, ftResultScheduleState, ftResultTransferTakenTime, ftResultTransferEndTime, ftResultErrDescr } STATUS current DESCRIPTION "If the value of ftScheduleSendCompletionTrap object is 'true', a ftTransferCompletion notification will be sent at the tranfer completion. Otherwise, the notification will not be sent." ::= { ftMIBNotifications 1 } -- conformance information ftConformance OBJECT IDENTIFIER ::= { fileTransferMIB 3 } ftCompliances OBJECT IDENTIFIER ::= { ftConformance 1 } ftGroups OBJECT IDENTIFIER ::= { ftConformance 2 } -- compliance statements ftCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for those that implements this MIB." MODULE MANDATORY-GROUPS { ftScheduleGroup, ftResultGroup, ftGeneralGroup, ftNotificationsGroup } GROUP ftLogGroup DESCRIPTION "It's not mandatory for agents to implement this group." ::= { ftCompliances 1 } -- MIB groupings ftScheduleGroup OBJECT-GROUP OBJECTS { ftScheduleProtocol, ftScheduleServerAddressType, ftScheduleServerAddress, ftScheduleServerPort, ftScheduleDirection, ftScheduleUserName, ftScheduleUserPassword, Ban Expires April 9, 2010 [Page 28] Internet-Draft Backup and Restore MIBs October 2009 ftScheduleSrcFileName, ftScheduleDestFileName, ftScheduleFileType, ftScheduleOverwriteSameFile, ftScheduleSendCompletionTrap, ftScheduleStartTime, ftScheduleRowStatus } STATUS current DESCRIPTION "The collection of objects providing the ability to transfer a file." ::= { ftGroups 1 } ftResultGroup OBJECT-GROUP OBJECTS { ftResultScheduleState, ftResultTransferTakenTime, ftResultTransferEndTime, ftResultErrDescr } STATUS current DESCRIPTION "The collection of objects providing the result of a file transfer." ::= { ftGroups 2 } ftLogGroup OBJECT-GROUP OBJECTS { ftLogSoureType, ftLogProtocol, ftLogServerAddressType, ftLogServerAddress, ftLogServerPort, ftLogDirection, ftLogUserName, ftLogSrcFileName, ftLogDestFileName, ftLogFileType, ftLogState, ftLogTransferStartTime, ftLogTransferEndTime, ftLogTransferTakenTime, ftLogErrDescr } STATUS current DESCRIPTION "The collection of objects providing the log information Ban Expires April 9, 2010 [Page 29] Internet-Draft Backup and Restore MIBs October 2009 about a file transfer." ::= { ftGroups 3 } ftGeneralGroup OBJECT-GROUP OBJECTS { ftProtocolCapabilities } STATUS current DESCRIPTION "The collection of objects used to represent general file-transfer information, for which a single agent provides management information." ::= { ftGroups 4 } ftNotificationsGroup NOTIFICATION-GROUP NOTIFICATIONS { ftTransferCompletion } STATUS current DESCRIPTION "The collection of notifications used to indicate File Transfer MIB data consistency and general status information." ::= { ftGroups 5 } END 7.2. SYSFILE-MAN-MIB Definitions SYSFILE-MAN-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, mib-2, TimeTicks, NOTIFICATION-TYPE FROM SNMPv2-SMI DisplayString, TruthValue, RowStatus, TEXTUAL-CONVENTION, DateAndTime FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF PhysicalIndex FROM ENTITY-MIB; sysFileManMIB MODULE-IDENTITY LAST-UPDATED "0910020000Z" ORGANIZATION "IIETF OPSAWG Working Group" CONTACT-INFO "Shimin Ban Oriental Electronic Bld., No.2, Chuangye Road, Ban Expires April 9, 2010 [Page 30] Internet-Draft Backup and Restore MIBs October 2009 Shang-Di Information Industry Base, Hai-Dian District, Beijing, China(100085) Email: banshimin@h3c.com" DESCRIPTION "Copyright (C) 2009 The Internet Society. This version of the MIB module is part of RFC xxxx; see the RFC itself for full legal notices. This MIB module defines MIB objects which provide a way to manage the system file, especially configuration and image files. This MIB module also provides a way to reload an entity or the entire system. Working with FILE-TRANSFER-MIB, this MIB module can be used: (1) to backup/restore the configuration files. (2) to upgrade agent. " REVISION "0910020000Z" DESCRIPTION "The initial revision, published as RFC xxxx" ::= { mib-2 xxx } sfmMIBObjects OBJECT IDENTIFIER ::= { sysFileManMIB 1 } sfmLocalDateAndTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-write STATUS current DESCRIPTION "The current local date and time of the system." ::= { sfmMIBObjects 1 } -- MIB contains four groups sfmConfig OBJECT IDENTIFIER ::= { sfmMIBObjects 2 } sfmImage OBJECT IDENTIFIER ::= { sfmMIBObjects 3 } sfmCurrent OBJECT IDENTIFIER ::= { sfmMIBObjects 4 } sfmReload OBJECT IDENTIFIER ::= { sfmMIBObjects 5 } -- Textual Conventions SysFilePRI ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The priority which indicates the reloading sequence of the file. For normal reload, which not on schedule, the system SHOULD firstly select 'primary' files. If there is no 'primary' Ban Expires April 9, 2010 [Page 31] Internet-Draft Backup and Restore MIBs October 2009 file or reloading 'primary' file fails, the 'secondary' files SHOULD be selected, then 'tertiary' files. If the file is a 'none' one, it won't be used for ever. For the newly transferred files, the priority should be set to 'primary' automatically. For systems which only support one 'primary' file, if a new file is set to 'primary', the former 'primary' one SHOULD be downgraded to 'secondary' automatically." SYNTAX INTEGER { primary(1), secondary(2), tertiary(3), none(4) } SystemFileType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The type of the system file. config: Configuration file image: Image file other: A file that can be recognized by the system and other than the above types unknown: Unknown file" SYNTAX INTEGER { config(1), image(2), other(3), unknown(4) } -- config group sfmSaveConfig OBJECT-TYPE SYNTAX INTEGER { save(1) } MAX-ACCESS read-write STATUS current DESCRIPTION "Save the running config at once. The object can be used with sfmSavedFileName object. If the object is set individually, the system SHOULD check Ban Expires April 9, 2010 [Page 32] Internet-Draft Backup and Restore MIBs October 2009 sfmSavedFileName object before saving the running config. If its value is valid, the system SHOULD save the running config to the file named by sfmSavedFileName. Otherwise, the system SHOULD save the running config to the default file, for example, the current startup file. If the object and sfmSavedFileName are both set in a PDU, the system SHOULD save the running config to the file specified by sfmSavedFileName." ::= { sfmConfig 1 } sfmSavedFileName OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates the file name used to save the running config. The object can be used with sfmSaveConfig, but it's not required. The value of this object SHOULD be cleared after used." ::= { sfmConfig 2 } sfmRunningLastChanged OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at which the running config was last changed. If the value of sfmRunningLastChanged is greater than sfmRunningLastSaved, that means the running config has been changed but not saved yet." ::= { sfmConfig 3 } sfmRunningLastSaved OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at which the running config was last saved. If the value of sfmRunningLastChanged is greater than sfmRunningLastSaved, that means the running config has been changed but not saved yet." ::= { sfmConfig 4 } sfmConfigFileTable OBJECT-TYPE SYNTAX SEQUENCE OF SfmConfigFileEntry MAX-ACCESS not-accessible Ban Expires April 9, 2010 [Page 33] Internet-Draft Backup and Restore MIBs October 2009 STATUS current DESCRIPTION "A table of configuration files in the system." ::= { sfmConfig 5 } sfmConfigFileEntry OBJECT-TYPE SYNTAX SfmConfigFileEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A configuration file entry. Each entry consists of information of a configuration file." INDEX { sfmConfigFileIndex} ::= { sfmConfigFileTable 1 } SfmConfigFileEntry ::= SEQUENCE { sfmConfigFileIndex Integer32, sfmConfigFilePhysicalIndex PhysicalIndex, sfmConfigFileName DisplayString, sfmConfigFilePRI SysFilePRI, sfmConfigFileSize Integer32, sfmConfigFileLastChanged DateAndTime } sfmConfigFileIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Specifies an unique entry in the sfmConfigFileTable." ::= { sfmConfigFileEntry 1 } sfmConfigFilePhysicalIndex OBJECT-TYPE SYNTAX PhysicalIndex MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the entity index in which the config file resides. The physical index is the same as the entPhysicalIndex defined in ENTITY-MIB." ::= { sfmConfigFileEntry 2 } sfmConfigFileName OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates the full path name of the config file." Ban Expires April 9, 2010 [Page 34] Internet-Draft Backup and Restore MIBs October 2009 ::= { sfmConfigFileEntry 3 } sfmConfigFilePRI OBJECT-TYPE SYNTAX SysFilePRI MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates the reloading priority of the file." ::= { sfmConfigFileEntry 4 } sfmConfigFileSize OBJECT-TYPE SYNTAX Integer32 UNITS "Bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the size of the config file." ::= { sfmConfigFileEntry 5 } sfmConfigFileLastChanged OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The local time at which the config file was last changed. If the file is never changed, the value SHOULD be its created time." ::= { sfmConfigFileEntry 6 } -- image group sfmImageTable OBJECT-TYPE SYNTAX SEQUENCE OF SfmImageEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of image files in the system." ::= { sfmImage 2 } sfmImageEntry OBJECT-TYPE SYNTAX SfmImageEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An image file entry. Each entry consists of information of an image." INDEX { sfmImageIndex} ::= { sfmImageTable 1 } Ban Expires April 9, 2010 [Page 35] Internet-Draft Backup and Restore MIBs October 2009 SfmImageEntry ::= SEQUENCE { sfmImageIndex Integer32, sfmImagePhysicalIndex PhysicalIndex, sfmImageName DisplayString, sfmImageVersion DisplayString, sfmImagePRI SysFilePRI, sfmImageSize Integer32, sfmImageCreatedTime DateAndTime, } sfmImageIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Specifies an unique entry in the sfmImageTable." ::= { sfmImageEntry 1 } sfmImagePhysicalIndex OBJECT-TYPE SYNTAX PhysicalIndex MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the entity index in which the image resides. The physical index is the same as the entPhysicalIndex specified in ENTITY-MIB." ::= { sfmImageEntry 2 } sfmImageName OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates the full path name of the image." ::= { sfmImageEntry 3 } sfmImageVersion OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the version number of the image." ::= { sfmImageEntry 4 } sfmImagePRI OBJECT-TYPE SYNTAX SysFilePRI MAX-ACCESS read-write STATUS current Ban Expires April 9, 2010 [Page 36] Internet-Draft Backup and Restore MIBs October 2009 DESCRIPTION "Indicates the reloading priority of the image." ::= { sfmImageEntry 5 } sfmImageSize OBJECT-TYPE SYNTAX Integer32 UNITS "Bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the size of the image." ::= { sfmImageEntry 6 } sfmImageCreatedTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The local time at which the image was created." ::= { sfmImageEntry 7 } -- current information group sfmCurrentTable OBJECT-TYPE SYNTAX SEQUENCE OF SfmCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table which provides information about the files being used by the system." ::= { sfmCurrent 1 } sfmCurrentEntry OBJECT-TYPE SYNTAX SfmCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a particular file being used by the system." INDEX { sfmCurrentFileType, sfmCurrentFileIndexOrZero} ::= { sfmCurrentTable 1 } SfmCurrentEntry ::= SEQUENCE { sfmCurrentFileType SystemFileType, sfmCurrentFileIndexOrZero Integer32 } sfmCurrentFileType OBJECT-TYPE SYNTAX SystemFileType Ban Expires April 9, 2010 [Page 37] Internet-Draft Backup and Restore MIBs October 2009 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The type of the system file." ::= { sfmCurrentEntry 1 } sfmCurrentFileIndexOrZero OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "If the value of SystemFileType is 'config', this value identifies the config file specified by the same value of sfmConfigFileIndex. If the value of SystemFileType is 'image', this value identifies the image file specified by the same value of sfmImageIndex. If the value of SystemFileType is 'other' or 'unknown', this value SHOULD be zero." ::= { sfmCurrentEntry 2 } -- reload group sfmResetWithReloadIndexOrZero OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "Reset the system at once. If the value is set to zero, the system will be reset at once with the current startup config and image. The files here MAY be not the ones held in sfmCurrentTable because the file priority can be changed via sfmConfigFilePRI or sfmImagePRI. If this object has a non-zero value, it means that the reload task specified by the same value of sfmReloadIndex will be used. That is, the system will be reset at once with the config file and image specified by the task, regardless of sfmReloadScheduleTime. If there is no such task or there is an invalid parameter in the task, an error will be returned." ::= { sfmReload 1 } sfmReloadScheduleTable OBJECT-TYPE SYNTAX SEQUENCE OF SfmReloadScheduleEntry Ban Expires April 9, 2010 [Page 38] Internet-Draft Backup and Restore MIBs October 2009 MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of system reload tasks." ::= { sfmReload 2 } sfmReloadScheduleEntry OBJECT-TYPE SYNTAX SfmReloadScheduleEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A system reload task. The NMS wishing to create an entry SHOULD generate a random serial number to be used as the index to this sparse table. Once the appropriate instance of all the objects have been created, either by an explicit SNMP SET request or by default, the row status SHOULD be set to active to initiate the task. Note that this entire procedure SHOULD be initiated via a single SET request which specifies a row status of createAndGo as well as specifies valid values for the non-defaulted objects. Before reload the system will check the parameters of the task. If there is an invalid parameter, for example, the specified image or config file not exist, the reload won't be executed. Then the system will create a sfmReloadErrorEntry with the same index as this entry. And if sfmReloadSendErrorTrap is 'true', a smfReloadError notification will be sent. The NMS can query sfmReloadErrorTable to get the detailed error information about the reload. In order to prevent old entries from clogging the table, entries will be aged out. When the entry in this table is deleted, the corresponding entry in sfmReloadErrorTable SHOULD also be deleted in the same time." INDEX { sfmReloadIndex } ::= { sfmReloadScheduleTable 1 } SfmReloadScheduleEntry ::= SEQUENCE { sfmReloadIndex Integer32, sfmReloadPhysicalIndex PhysicalIndex, sfmReloadConfigIndexOrZero Integer32, sfmReloadImageIndex Integer32, sfmReloadTime DateAndTime, sfmReloadComments DisplayString, Ban Expires April 9, 2010 [Page 39] Internet-Draft Backup and Restore MIBs October 2009 sfmReloadSendErrorTrap TruthValue, sfmReloadRowStatus RowStatus } sfmReloadIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Specifies an unique entry in the sfmReloadScheduleTable. The NMS wishing to initiate a reload task SHOULD use a random value for this object when creating an instance of sfmReloadScheduleEntry." ::= { sfmReloadScheduleEntry 1 } sfmReloadPhysicalIndex OBJECT-TYPE SYNTAX PhysicalIndex MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates an physical entity to be reloaded in entPhysicalTable. The value of this object is same as entPhysicalIndex." ::= { sfmReloadScheduleEntry 2 } sfmReloadConfigIndexOrZero OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "The value indicates the config file used by this reload task, which is specified by the same value of sfmConfigFileIndex. The zero value means the factory default settings will be used by this reload task." ::= { sfmReloadScheduleEntry 3 } sfmReloadImageIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "The value indicates the image used by this reload task, which is specified by the same value of sfmImageIndex. The value can't be zero." ::= { sfmReloadScheduleEntry 4 } Ban Expires April 9, 2010 [Page 40] Internet-Draft Backup and Restore MIBs October 2009 sfmReloadTime OBJECT-TYPE SYNTAX DateAndTime (SIZE(8)) MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates the local time at which the reload action will occur. The system SHOULD only take octet strings with length 8 for this object. The date-time specification is shown as follows: field octets contents range ----- ------ -------- ----- 1 1-2 year 0..65536 2 3 month 1..12 3 4 day 1..31 4 5 hour 0..23 5 6 minutes 0..59 6 7 seconds 0..60 7 8 deci-seconds 0..9 For example, Tuesday September 15, 2009 at 1:30:15 PM would be returned as '07D9090F0D1E0F00'H and displayed as: 2009-9-15,13:30:15.0 If the object is set to '0000000000000000'H, the task will be run immediately. If the object is set to 'FFFFFFFFFFFFFFFF'H or the set time is previous to sfmLocalDateAndTime, the task won't be run. If the object is set to any valid octet strings other than the above cases the task will be run at the specified time. The tasks which the value of this object is 'FFFFFFFFFFFFFFFF'H won't be deleted for ever. The NMS must delete them with RowStatus explicitly." ::= { sfmReloadScheduleEntry 5 } sfmReloadComments OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only STATUS current DESCRIPTION "The comments for the reload." ::= { sfmReloadScheduleEntry 6 } Ban Expires April 9, 2010 [Page 41] Internet-Draft Backup and Restore MIBs October 2009 sfmReloadSendErrorTrap OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates whether or not a smfReloadError notification SHOULD be issued when an error occurs during system reload." DEFVAL { true } ::= { sfmReloadScheduleEntry 7 } sfmReloadRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The row status object controls the creation/deletion of rows in this table. Its semantics are the same as those for the RowStatus textual convention specified for SNMPv2." ::= { sfmReloadScheduleEntry 8 } sfmReloadErrorTable OBJECT-TYPE SYNTAX SEQUENCE OF SfmReloadErrorEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of reload error information." ::= { sfmReload 3 } sfmReloadErrorEntry OBJECT-TYPE SYNTAX SfmReloadErrorEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The error entries of reload tasks. Before reload the system SHOULD check the parameters of the task. If there is an invalid parameter, for example, the specified image or config file not exist, the reload won't be executed. Then a new entry of sfmReloadErrorEntry will be created. And if the value of sfmReloadSendErrorTrap is 'true', a smfReloadError notification will be sent. The table has the same index as sfmReloadScheduleTable. To get the detailed error information, the NMS SHOULD query this table with the corresponding value of sfmReloadIndex after receiving smfReloadError notification. Ban Expires April 9, 2010 [Page 42] Internet-Draft Backup and Restore MIBs October 2009 In order to prevent old entries from clogging the table, entries will be aged out. But an entry SHOULD never be deleted within 5 minutes of error occurring. When the entry in sfmReloadScheduleTable is deleted, the corresponding entry in this table SHOULD also be deleted in the same time." INDEX { sfmReloadIndex } ::= { sfmReloadErrorTable 1 } SfmReloadErrorEntry ::= SEQUENCE { sfmReloadErrorTime DateAndTime, sfmReloadErrorDescr DisplayString } sfmReloadErrorTime OBJECT-TYPE SYNTAX DateAndTime (SIZE(8)) MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the local time at which the error occurs. The system SHOULD only take octet strings with length 8 for this object. The date-time specification is shown as follows: field octets contents range ----- ------ -------- ----- 1 1-2 year 0..65536 2 3 month 1..12 3 4 day 1..31 4 5 hour 0..23 5 6 minutes 0..59 6 7 seconds 0..60 7 8 deci-seconds 0..9 For example, Tuesday September 15, 2009 at 1:30:15 PM would be returned as '07D9090F0D1E0F00'H and displayed as: 2009-9-15,13:30:15.0 " ::= { sfmReloadErrorEntry 1 } sfmReloadErrorDescr OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only STATUS current DESCRIPTION Ban Expires April 9, 2010 [Page 43] Internet-Draft Backup and Restore MIBs October 2009 "Indicates the detailed error information about the task." ::= { sfmReloadErrorEntry 2 } -- System File Management MIB Trap Definitions sfmMIBNotifications OBJECT IDENTIFIER ::= { sysFileManMIB 2 } smfConfigChangeTrap NOTIFICATION-TYPE OBJECTS { sfmLocalDateAndTime } STATUS current DESCRIPTION "When the system configuration is changed, the trap will be generated." ::= { sfmMIBNotifications 1 } smfReloadEntityIn5Min NOTIFICATION-TYPE OBJECTS { sfmReloadIndex, sfmReloadPhysicalIndex, sfmConfigFileName, sfmImageName, sfmReloadTime, sfmReloadComments } STATUS current DESCRIPTION "The trap indicates that an entity or the entire system is about to reset due to a reload task. The trap SHOULD be sent 5 minutes before the reset." ::= { sfmMIBNotifications 2 } smfReloadError NOTIFICATION-TYPE OBJECTS { sfmReloadIndex, sfmReloadPhysicalIndex, sfmConfigFileName, sfmImageName, sfmReloadErrorTime, sfmReloadErrorDescr } STATUS current DESCRIPTION "The system SHOULD check the task's parameters before reload. If there is an invalid parameter, for example, the specified image or config file not exist, the reload won't be executed. Then if the value of sfmReloadSendErrorTrap is 'true', a smfReloadError notification will be sent. Ban Expires April 9, 2010 [Page 44] Internet-Draft Backup and Restore MIBs October 2009 Otherwise, the notification won't be sent." ::= { sfmMIBNotifications 3 } -- conformance information sfmConformance OBJECT IDENTIFIER ::= { sysFileManMIB 3 } sfmCompliances OBJECT IDENTIFIER ::= { sfmConformance 1 } sfmGroups OBJECT IDENTIFIER ::= { sfmConformance 2 } -- compliance statements sfmCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for those that implements this MIB." MODULE MANDATORY-GROUPS { sfmConfigFileGroup, sfmImageGroup, sfmCurrentGroup, sfmReloadScheduleGroup, sfmReloadErrorGroup, sfmGeneralGroup, sfmNotificationsGroup } ::= { sfmCompliances 1 } -- MIB groupings sfmConfigFileGroup OBJECT-GROUP OBJECTS { sfmConfigFilePhysicalIndex, sfmConfigFileName, sfmConfigFilePRI, sfmConfigFileSize, sfmConfigFileLastChanged } STATUS current DESCRIPTION "The collection of objects providing the information about the configuration files on the device." ::= { sfmGroups 1 } sfmImageGroup OBJECT-GROUP OBJECTS { sfmImagePhysicalIndex, sfmImageName, sfmImageVersion, sfmImagePRI, sfmImageSize, Ban Expires April 9, 2010 [Page 45] Internet-Draft Backup and Restore MIBs October 2009 sfmImageCreatedTime } STATUS current DESCRIPTION "The collection of objects providing the information about the images on the device." ::= { sfmGroups 2 } sfmCurrentGroup OBJECT-GROUP OBJECTS { sfmCurrentFileType, sfmCurrentFileIndexOrZero } STATUS current DESCRIPTION "The collection of objects providing the information about the files being used by the device." ::= { sfmGroups 3 } sfmReloadScheduleGroup OBJECT-GROUP OBJECTS { sfmReloadPhysicalIndex, sfmReloadConfigIndexOrZero, sfmReloadImageIndex, sfmReloadTime, sfmReloadComments, sfmReloadSendErrorTrap, sfmReloadRowStatus } STATUS current DESCRIPTION "The collection of objects providing the ability to reload an entity or the entire system." ::= { sfmGroups 4 } sfmReloadErrorGroup OBJECT-GROUP OBJECTS { sfmReloadErrorTime, sfmReloadErrorDescr } STATUS current DESCRIPTION "The collection of objects providing the error information about a reload." ::= { sfmGroups 5 } sfmGeneralGroup OBJECT-GROUP OBJECTS { Ban Expires April 9, 2010 [Page 46] Internet-Draft Backup and Restore MIBs October 2009 sfmLocalDateAndTime, sfmSaveConfig, sfmSavedFileName, sfmRunningLastChanged, sfmRunningLastSaved, sfmResetWithReloadIndexOrZero } STATUS current DESCRIPTION "The collection of objects used to represent general management information." ::= { sfmGroups 6 } sfmNotificationsGroup NOTIFICATION-GROUP NOTIFICATIONS { smfConfigChangeTrap, smfReloadEntityIn5Min, smfReloadError } STATUS current DESCRIPTION "The collection of notifications used to indicate system file management MIB data consistency and general status information." ::= { sfmGroups 7 } END 8. Usage Examples The following examples show how to use the MIB modules: o To backup a config file at once. o To restore the running config at specified time. o To upgrade agent at once. o To reboot the system conditionally. To show the examples better this document assumes that: 1) The device supports FTP protocol. 2) The information of the backup server is: IP address: 192.0.2.10/24 FTP user name: tester FTP user pwd: test FTP port: default port 3) The entity index is '1', which the config files and images are reside in. 4) In the device there are three configuration files. And the first Ban Expires April 9, 2010 [Page 47] Internet-Draft Backup and Restore MIBs October 2009 file is the current startup config: +-------------------------------------------------------------------+ | Index |sfmConfigFile| sfmConfig |sfmConfig|sfmConfig|sfmConfigFile| | |PhysicalIndex| FileName |FilePRI |FileSize | LastChanged | +-------------------------------------------------------------------+ | 1 | 1 | flash:/ | primary | 600652 | 2009-9-24, | | | | conf1.cfn | | | 20:53:4.1 | +-------------------------------------------------------------------+ | 2 | 1 | flash:/ |secondary| 700652 | 2009-9-23, | | | | conf2.cfn | | | 20:53:4.1 | +-------------------------------------------------------------------+ | 3 | 1 | flash:/ |tertiary | 800652 | 2009-9-22, | | | | conf3.cfn | | | 20:53:4.1 | +-------------------------------------------------------------------+ 5) In the device there are two images. And the first image is being used: +-------------------------------------------------------------------+ | |sfmImage| |sfmImage|sfmImage |sfmImage|sfmImage | |Index|Physical|sfmImageName|Version |PRI |Size |CreatedTime| | |Index | | | | | | +-------------------------------------------------------------------+ | 1 | 1 |flash:/ | 5.20 | primary |60065200|2009-9-24, | | | |s75e_520.app| | | |20:53:4.1 | +-------------------------------------------------------------------+ | 2 | 1 |flash:/ | 5.10 |secondary|70065200|2009-9-23, | | | |s75e_510.app| | | |20:53:4.1 | +-------------------------------------------------------------------+ 8.1. To backup a config file at once The following example shows how to backup 'flash:/conf3.cfn' file at once. 1) The NMS generates a random serial number (for example 558) as the index. 2) Then the NMS creates a file-transfer task with the following parameters: ftScheduleProtocol.558 = ftp(2) ftScheduleServerAddressType.558 = ipv4(1) ftScheduleServerAddress.558 = 192.0.2.10 ftScheduleServerPort.558 = 0 ftScheduleDirection.558 = toServer(2) ftScheduleUserName.558 = tester ftScheduleUserPassword.558 = test Ban Expires April 9, 2010 [Page 48] Internet-Draft Backup and Restore MIBs October 2009 ftScheduleSrcFileName.558 = flash:/conf3.cfn ftScheduleDestFileName.558 = c:/20090924.cfn ftScheduleFileType.558 = startupConfigFile(2) ftScheduleTime.558 = 0000000000000000 ftScheduleRowStatus.558 = CreateAndGo(4) 3) The system will transfer the file immediately after the entry is created. A ftTransferCompletion notification will be sent to the NMS on completion of the transfer, through which the NMS can tell if the transfer is successful and the failed reason. 8.2. To restore the running config at specified time The following example shows how to restore the running config with the file 'c:/ 20090924.cfn' in the backup server at '2009-9-15,13:30:15.0'. 1) The NMS generates a random serial number (for example 559) as the index. 2) Then the NMS creates a file-transfer task with the following parameters: ftScheduleProtocol.559 = ftp(2) ftScheduleServerAddressType.559 = ipv4(1) ftScheduleServerAddress.559 = 192.0.2.10 ftScheduleServerPort.559 = 0 ftScheduleDirection.559 = fromServer(1) ftScheduleUserName.559 = tester ftScheduleUserPassword.559 = test ftScheduleSrcFileName.559 = c:/20090924.cfn ftScheduleFileType.559 = runningConfigFile(3) ftScheduleTime.559 = 07D9090F0D1E0F00 ftScheduleRowStatus.559 = CreateAndGo(4) 3) The system will transfer the file at the specified time. A ftTransferCompletion notification will be sent to the NMS on completion of the transfer, through which the NMS can tell if the transfer is successful and the failed reason. 8.3. To upgrade agent at once The following example shows how to upgrade agent immediately with the image 'c:/s75e_530.app' in the backup server. 1) The NMS generates a random serial number (for example 560) as the index. 2) Then the NMS creates a file-transfer task with the following parameters: Ban Expires April 9, 2010 [Page 49] Internet-Draft Backup and Restore MIBs October 2009 ftScheduleProtocol.560 = ftp(2) ftScheduleServerAddressType.560 = ipv4(1) ftScheduleServerAddress.560 = 192.0.2.10 ftScheduleServerPort.560 = 0 ftScheduleDirection.560 = fromServer(1) ftScheduleUserName.560 = tester ftScheduleUserPassword.560 = test ftScheduleSrcFileName. 560 = c:/s75e_530.app ftScheduleDestFileName.560 = flash:/s75e_530.app ftScheduleFileType.560 = imageFile(4) ftScheduleTime.560 = 0000000000000000 ftScheduleRowStatus.560 = CreateAndGo(4) 3) The system will transfer the image immediately after the entry is created. A ftTransferCompletion notification will be sent to the NMS on completion of the transfer, through which the NMS can tell if the transfer is successful and the failed reason. 4) If the transfer is successful, the sfmImagePRI object of the new sfmImageEntry will be set to 'primary' automatically. Then to reboot the system the NMS SHOULD set: sfmResetAtOnceWithRSIndexOrZero = 0 Agent upgrade succeeds after reboot. 8.4. To reboot the system conditionally The following example shows how to reboot the entire system with the config file 'flash:/conf2.cfn' and the image 'flash:/ s75e_520.app' at '2009-9-15,13:30:15.0'. 1) The NMS generates a random serial number (for example 561) as the index. 2) Then the NMS creates a system reload task with the following parameters: sfmReloadPhysicalIndex.561 = 1 (the entity to be reloaded) sfmReloadConfigIndexOrZero.561 = 2 sfmReloadImageIndex.561 = 1 sfmReloadTime.561 = 07D9090F0D1E0F00 sfmReloadComments.561 = 'reboot the system for some reason. ' sfmReloadRowStatus.561 = CreateAndGo(4) 3) The system will reboot the entire system at specified time. A smfReloadError notification will be sent to the NMS if the system reboot fails, through which the NMS can get the failed reason. Ban Expires April 9, 2010 [Page 50] Internet-Draft Backup and Restore MIBs October 2009 9. Security Considerations There are a number of management objects defined in the MIB modules with a MAX-ACCESS clause of read-write and/or read-create. Such objects MAY be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. The followings are the tables and objects and their sensitivity/vulnerability: o ftLogTableMaxSize: This object controls how many entries are held in the ftLogTable. Unauthorized modifications MAY cause either increased memory consumption (by setting this object to a large value) or disabled capability to log the transfer (by setting this object to zero). o ftScheduleTable: This table controls when and how to transfer the files. An unauthorized customer/user could download the images or configuration files or attack the system via uploading a large number of files to the system. o sfmReloadScheduleTable: This table controls when and how to reload the entity or the system. Unauthorized changes to the table MAY cause the system unable to correctly reload. For example, if the value of sfmReloadImageIndex or sfmReloadConfigIndexOrZero object is incorrect, the reload can not work. And if the value of sfmReloadTime is set to '0000000000000000', the entity of the system will be reloaded at once. o sfmLocalDateAndTime: This object controls the current local date and time of the system. Unauthorized modifications will change the local time of the system. o sfmSaveConfig and sfmSavedFileName: Through the two objects the NMS can save the running configuration immediately. Setting the two object frequently MAY cause the system creating many configuration files. o sfmResetWithReloadIndexOrZero: Unauthorized SET to the object will cause the entity or the system reload at once. o sfmConfigFileName and sfmImageName: Unauthorized changes to the two objects will modify the names of the configuration files or the images with no effect on the entire system. o sfmConfigFilePRI and sfmImagePRI: Unauthorized changes to the two objects will modify the priority of the configuration files or the images so that the system can't be reloaded correctly. Some of the readable objects in the MIB modules (i.e., objects with a MAX-ACCESS other than not-accessible) MAY be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. The followings are the tables and objects and Ban Expires April 9, 2010 [Page 51] Internet-Draft Backup and Restore MIBs October 2009 their sensitivity/vulnerability: o The ftProtocolCapabilities object exposes the protocols that are implemented by the device to transfer files. o The ftResultTable object exposes the result of the file-transfer requests. o The ftLogTable exposes the log information about the file-transfer requests. o The sfmRunningLastChanged and sfmRunningLastSaved object expose when the running configuration file was last changed and saved. o The sfmConfigFileTable exposes the information about the configuration files in the system. o The sfmImageTable exposes the information about the images in the system. o The sfmCurrentTable exposes the information about the files being used by the system. o The sfmReloadErrorTable exposes the error information about system reloading. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 10. IANA Considerations The IANA is requested to assign a value for "XXX" under the 'mib-2' subtree and to record the assignment in the SMI Numbers registry. When the assignment has been made, the RFC Editor is asked to replace "XXX" (here and in the MIB module) with the assigned value. Ban Expires April 9, 2010 [Page 52] Internet-Draft Backup and Restore MIBs October 2009 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J.Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC3291] Daniele, M., Haberman, B., Routhier, S. and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 3291, December 2001. [RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", RFC 3416, December 2002. [RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version 3)", RFC 4133, August 2005. 11.2. Informative References [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. Authors' Addresses Shimin Ban (editor) Hangzhou H3C Tech. Co., Ltd Oriental Electronic Bld., No.2, Chuangye Road, Shang-Di Information Industry Base, Hai-Dian District, Beijing, China(100085) Phone: +86 010 82774853 EMail: banshimin@h3c.com Ban Expires April 9, 2010 [Page 53]