module org-openroadm-manifest-file {
  namespace "http://org/openroadm/manifest-file";
  prefix org-openroadm-manifest-file;

  organization
    "Open ROADM MSA";
  contact
    "OpenROADM.org";
  description
    "YANG definitions of sw-manifest-file
     
     Copyright of the Members of the Open ROADM MSA Agreement dated (c) 2017, 
     AT&T Intellectual Property.  All other rights reserved.
     
     Redistribution and use in source and binary forms, with or without modification, 
     are permitted provided that the following conditions are met:
     
     * Redistributions of source code must retain the above copyright notice, this 
       list of conditions and the following disclaimer.
     * Redistributions in binary form must reproduce the above copyright notice, 
       this list of conditions and the following disclaimer in the documentation and/or 
       other materials provided with the distribution.
     * Neither the Members of the Open ROADM MSA Agreement nor the names of its 
       contributors may be used to endorse or promote products derived from this software 
       without specific prior written permission.
     
     THIS SOFTWARE IS PROVIDED BY THE MEMBERS OF THE OPEN ROADM MSA  AGREEMENT ''AS IS'' 
     AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED 
     WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. 
     IN NO EVENT THE MEMBERS OF THE OPEN ROADM MSA  AGREEMENT BE LIABLE FOR ANY DIRECT, 
     INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT 
     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;  LOSS OF USE, DATA, 
     OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, 
     WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) 
     ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE 
     POSSIBILITY OF SUCH DAMAGE.
     
     Also contains code components extracted from IETF netconf.  These code components 
     are copyrighted and licensed as follows:
     
     Copyright (c) 2016 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 (http://trustee.ietf.org/license-info) in effect on the date of 
     publication of this document. Please review these documents carefully, as they 
     describe your rights and restrictions with respect to this document. Code Components 
     extracted from this document must include Simplified BSD License text as described in
     Section 4.e of the Trust Legal Provisions and are provided without warranty as 
     described in the Simplified BSD License.";

  revision 2017-12-15 {
    description
      "Version 2.2";
  }
  revision 2017-09-29 {
    description
      "Version 2.1";
    reference "This module serves as the manifest file reference.";
  }

  identity manifest-commands {
    description
      "base identity for defining manifest-commands.";
  }

  identity download-file {
    base manifest-commands;
    description
      "download-file (transfer from OWB-C to Device)";
  }

  identity upload-file {
    base manifest-commands;
    description
      "upload-file (transfer from Device to OWB-C)";
  }

  identity delete-file {
    base manifest-commands;
    description
      "delete-file from device";
  }

  identity sw-manifest-commands {
    base manifest-commands;
    description
      "base identity for defining manifest-commands specific to sw-manifest.";
  }

  identity sw-stage {
    base sw-manifest-commands;
    description
      "sw-stage sw-manifest-command";
  }

  identity sw-activate {
    base sw-manifest-commands;
    description
      "sw-activate sw-manifest-command";
  }

  identity db-backup-manifest-commands {
    base manifest-commands;
    description
      "base identity for defining manifest-commands specific to db-backup-manifest.";
  }

  identity db-backup {
    base db-backup-manifest-commands;
    description
      "db-backup db-backup-manifest-command";
  }

  identity db-restore-manifest-commands {
    base manifest-commands;
    description
      "base identity for defining manifest-commands specific to db-restore-manifest.";
  }

  identity db-restore {
    base db-restore-manifest-commands;
    description
      "db-restore db-restore-manifest-command";
  }

  identity db-activate {
    base db-restore-manifest-commands;
    description
      "db-activate db-restore-manifest-command";
  }

  grouping base-manifest {
    description
      "base set of variables in all manifest files";
    leaf vendor {
      type string;
      mandatory true;
      description
        "This field should match the /org-openroadm-device/info/vendor.
         It is assumed that the vendor value does not change during the
         processing of the manifest file.
         
         The controller agent would use the vendor and model to find the
         manifest for an Open ROADM NE. The controller agent would also
         use the vendor and model to validate that this is a valid manifest
         for the Open ROADM NE.
        ";
    }
    leaf model {
      type string;
      mandatory true;
      description
        "This field should match the /org-openroadm-device/info/model.
         It is assumed that the model value does not change during the
         processing of the manifest file.
         
         The controller agent would use the vendor and model to find the
         manifest for an Open ROADM NE. The controller agent would also
         use the vendor and model to validate that this is a valid manifest
         for the Open ROADM NE.
        ";
    }
    leaf sw-version {
      type string;
      description
        "This field should match the
             /org-openroadm-device/info/softwareVersion.
         This is the value in the info tree AFTER an upgrade.
        ";
    }
    leaf global-async-timeout {
      type uint16;
      default "900";
      description
        "global-async-timeout - time in seconds to wait for command processing to
         complete.
         
         Upon timeout, the controller may either:
           - assume success;
           - assume failure;
           - poll the device to determine success/failure of the operation
         
         This global-async-timeout applies to any asynchronous command.
        ";
    }
    leaf global-sync-timeout {
      type uint16;
      description
        "global-sync-timeout - time in seconds to wait for the rpc response for
         synchronous commands.
         
         This global-sync-timeout applies to any synchronous command.
         
         Upon timeout, the controller may either:
           - assume success;
           - assume failure;
           - poll the device to determine success/failure of the operation
         
         No default is modeled; if not provided, defaults to the global 
         timeout supported by the controller for rpc responses.
        ";
    }
  }

  grouping timeout-command {
    description
      "timeout-command is to be used by any manifest command supporting a timeout";
    leaf timeout {
      type uint16;
      description
        "See command for additional details.
         if command is async,
           - overrides the global-async-timeout;
           - defaults to the global-async-timeout if not provided.
         if command is sync,
           - overrides the global-sync-timeout;
           - defaults to the global-sync-timeout if not provided.
        ";
    }
  }

  grouping is-async-command {
    description
      "is-async-command is to be supported by all manifest commands even if only
       supported as sync or async. In such cases, a must statement should be 
       included to limit support to either sync or async.";
    leaf is-async {
      type boolean;
      default "true";
      description
        "command can be supported as either an async or sync command by a vendor.
         When supported as a sync command, the OWB-C will determine the success/failure
         of the command based on the RPC response instead of waiting for transient
         notifications from the device.";
    }
  }

  grouping transfer-command {
    description
      "transfer-command defines the common set of variables used by download-file
       and upload-file";
    leaf remote-filename {
      type string;
      mandatory true;
      description
        "See command for detailed description.";
    }
    leaf local-file-path {
      type string;
      mandatory true;
      description
        "See command for detailed description.";
    }
    uses timeout-command;
    uses is-async-command;
  }

  grouping file-command {
    description
      "file-command is used by all manifest files needing a filename";
    leaf filename {
      type string;
      description
        "filename is mandatory for delete-file; optional otherwise.
         See command for detailed description.";
    }
  }

  grouping command-reboot {
    description
      "command-reboot is used by manifest commands which result in a 
       device restart.";
    leaf auto-reboot {
      type uint16;
      mandatory true;
      description
        "See command for detailed description.";
    }
  }

  grouping download-file-command {
    description
      "down-file-command";
    container download-file {
      when "../command = 'download-file'";
      description
        "Transfer a file from the SFTP server to the device.
         format: download-file remote-filename local-file-path [timeout]
         where
           remote-filename is the filename of the file to transfer on the SFTP
           server. The filename can include a relative path that represents the
           subdirectory structure of the vendor's software directory. This file
           (and optional path) must exist in the software release directory on
           the SFTP server.
           
           local-file-path is the local path and filename to transfer the file on
           the device.
           
           timeout - see timeout-command grouping for basic details;
                     if command is async,
                       - Receipt of an in-progress (version 2)
                         transfer-notification resets the timeout.
           
         Maps to the transfer rpc with
            action = download
            local-file-path = local-file-path
            remote-file-path =
               sftp://user:password@host[:port]/path/remote-filename
           
            The remote-file-path attribute on the transfer command would be
            constructed by the software download agent by appending the sftp URL
            (which includes username, password, host, port, and path to the
            software release directory) with the remote_filename.
           
         In the context of the transfer, remote is the SFTP server (e.g., located
         on the software download agent) and local is on the Open ROADM device.
           
         Expected notifications: transfer-notification
        ";
      uses transfer-command;
    }
  }

  grouping upload-file-command {
    description
      "upload-file-command";
    container upload-file {
      when "../command = 'upload-file'";
      description
        "Transfer a file from the device to the SFTP server.
         format: upload-file remote-filename local-file-path [timeout]
         where
           remote-filename is the filename of the file to receive the upload
           on the SFTP server. The filename can include a relative path that
           represents the subdirectory structure of the vendor's software
           directory.
           
           local-file-path is the local path and filename of the file on
           the device to be uploaded to the SFTP server. This file must exist on
           the device.
           
           timeout - see timeout-command grouping for basic details;
                     if command is async,
                       - Receipt of an in-progress (version 2)
                         transfer-notification resets the timeout.
           
         Maps to the transfer rpc with
            action = upload
            local-file-path = local-file-path
            remote-file-path =
               sftp://user:password@host[:port]/path/remote-filename
           
            The remote-file-path attribute on the transfer command would be
            constructed by the software download agent by appending the sftp URL
            (which includes username, password, host, port, and path to the
            software release directory) with the remote_filename.
           
         In the context of the transfer, remote is the SFTP server (e.g., located
         on the software download agent) and local is on the Open ROADM device.
           
         Expected notifications: transfer-notification
        ";
      uses transfer-command;
    }
  }

  grouping delete-file-command {
    description
      "delete-file-command";
    container delete-file {
      when "../command = 'delete-file'";
      must "is-async != 'false'" {
        error-message "delete-file is only supported as sync command";
      }
      description
        "Delete a file from the device's file system.
         format: delete-file filename [timeout]
         where
           filename is the filename to be deleted from the device. The filename
           may include path information.
           
           timeout - overrides the global-sync-timeout; defaults to the
                     global-sync-timeout if not provided.
           
         Maps to the delete-file rpc:
            delete-file filename
        ";
      uses file-command {
        refine "filename" {
          mandatory true;
        }
      }
      uses timeout-command;
      uses is-async-command;
    }
  }

  grouping sw-stage-command {
    description
      "sw-stage-command";
    container sw-stage {
      when "../command = 'sw-stage'";
      description
        "Stage a file in the device.  The details of what a device does during
         the staging operation is vendor specific.  However, the vendor may
         initiate additional file transfers from the SFTP server during the
         staging operation.  It is expected that the files will only be
         transferred from the software release directory.
           
         format: sw-stage [filename] [timeout]
         where
           filename is the filename of the file to stage. If filename is not
           provided, the software download application will send the sw-stage
           command without a filename.
           
           timeout - overrides the global-async-timeout; defaults to the
                     global-async-timeout if not provided.
           
           
         Maps to the sw-stage rpc:
            sw-stage [filename]
           
         Expected notifications: sw-stage-notification
        ";
      uses file-command;
      uses timeout-command;
      uses is-async-command;
    }
  }

  grouping sw-activate-command {
    description
      "sw-activate-command";
    container sw-activate {
      when "../command = 'sw-activate'";
      must "is-async != 'true'" {
        error-message "sw-activate is only supported as async command";
      }
      description
        "Activate a software load in a device.  The details of what a device does
         during the activation phase is vendor specific.  The device initiates
         an automatic reboot as part of the activation.
           
         format:  sw-activate version [validation-timer] [timeout] auto-reboot
         where:
           version: The version of software that is being activated. (The current
           YANG model indicates that version is optional; however, version should
           be a mandatory attribute of the sw-activate command in the manifest
           file).
           
           validation-timer: Validation timer setting for the software activation.
           Format is expected to be in the form HH-MM-SS per the YANG model. The
           software download application expects this format in order to treat
           00-00-00 and no validation timer as the same use case.
           
           timeout - overrides the global-async-timeout; defaults to the
           global-async-timeout if not provided. This timer begins as soon as the
           sw-activate processing begins. timeout must be greater than the
           auto-reboot time.
           
           auto-reboot: time (in seconds) to wait to for the device to reboot.
           This is the device restart time (e.g. the length of time from device
           comm loss until the device is ready for login). This timer begins when
           the controller detects the comm-loss from the device. If login is not
           successful when this timer expires, the sw-activate is failed.
           
           NOTE: if controller swdl application is not doing the login directly,
           the controller may need to augment the auto-reboot timer to account for
           the login time.
           
         Maps to the sw-activate rpc:
           sw-activate version [validationTimer]
           
         Expected notifications: sw-activate-notification
           When no validation timer (or validation-timer = 00-00-00), two
           notifications will be expected: one for activate, the other for 
           commit. Otherwise, only the activate notification is expected.
           
           NOTE: the sw-activate-notifications (for activate) may be received
           before or after the reboot; it is assumed the sw-activate-notification
           (for commit) always occurs after the reboot. Any polling due to missed
           sw-activate-notifications (activate and/or commit) should not be done
           until after the reboot login; processing of sw-activate does not
           complete until after receipt of the notifications and the reboot login.
        ";
      leaf version {
        type string;
        mandatory true;
        description
          "Although version is optional in the sw-activate rpc, it is 
           mandatory in the manifest file command.";
      }
      leaf validation-timer {
        type string;
        description
          "hh-mm-ss";
      }
      uses timeout-command;
      uses command-reboot;
      uses is-async-command;
    }
  }

  grouping db-backup-command {
    description
      "db-backup-command";
    container db-backup {
      when "../command = 'db-backup'";
      description
        "Perform a database backup on the device.
           
         format: db-backup [filename] [timeout]
         where
           filename is the filename of the backup file to be generated on the
           device. If filename is not provided, the database backup application
           will send the db-backup command without a filename. It's possible the
           filename will not be statically provided in the manifest file, but
           provided by the database backup application.
           
           timeout - see timeout-command grouping for basic details;
           
         Maps to the db-backup rpc:
           db-backup [filename]
           
         Expected notifications: db-backup-notification
        ";
      uses file-command;
      uses timeout-command;
      uses is-async-command;
    }
  }

  grouping db-restore-command {
    description
      "db-restore-command";
    container db-restore {
      when "../command = 'db-restore'";
      description
        "Perform a database restore on the device.
         
         format: db-restore [filename] [node-id-check] [timeout]
         where
           filename is the filename of the file to be restored on the
           device. If filename is not provided, the database restore application
           will send the db-restore command without a filename. It's possible the
           filename will not be statically provided in the manifest file, but
           provided by the database restore application.
           
           node-id-check is a boolean indicating whether sysNameCheck is required.
           
           timeout - see timeout-command grouping for basic details;
           
         Maps to the db-restore rpc:
           db-restore [filename] [nodeIDCheck]
           
         Expected notifications: db-restore-notification
        ";
      uses file-command;
      leaf node-id-check {
        type string;
        default "true";
        description
          "Defined as an string here so that manifest file can parameterize
           the value for user input. __NODE-ID-CHECK is used for that purpose. Other valid
           values are true or false. Maps to a boolean value in the rpc invocation.";
      }
      uses timeout-command;
      uses is-async-command;
    }
  }

  grouping db-activate-command {
    description
      "db-activate-command";
    container db-activate {
      when "../command = 'db-activate'";
      must "is-async != 'true'" {
        error-message "db-activate is only supported as async command";
      }
      description
        "Activate a database on a device.  The details of what a device does
         during the activation phase is vendor specific.  The device initiates
         an automatic reboot as part of the activation.
           
         format:  db-activate [rollback-timer] [timeout] auto-reboot 
         where:
           rollback-timer: Rollback timer setting for the database activation.
           Format is expected to be in the form HH-MM-SS per the YANG model. The
           database activation application expects this format in order to treat
           00-00-00 and no validation timer as the same use case.
           
           timeout - overrides the global-async-timeout; defaults to the
           global-async-timeout if not provided. This timer begins as soon as the
           db-activate processing begins. timeout must be greater than the
           auto-reboot time.
           
           auto-reboot: time (in seconds) to wait to for the device to reboot.
           This is the device restart time (e.g. the length of time from device
           comm loss until the device is ready for login). This timer begins when
           the controller detects the comm-loss from the device. If login is not
           successful when this timer expires, the db-activate is failed.
           
           NOTE: if controller database application is not doing the login
           directly, the controller may need to augment the auto-reboot timer to
           account for the login time.
           
         Maps to the db-activate rpc:
           db-activate [rollBackTimer]
           
         Expected notifications: db-activate-notification
           When no rollback timer (or rollback-timer = 00-00-00), two
           notifications will be expected: one for activate, the other for 
           commit. Otherwise, only the activate notification is expected.
           
           NOTE: the db-activate-notifications (for activate) may be received
           before or after the reboot; it is assumed the db-activate-notification
           (for commit) always occurs after the reboot. Any polling due to missed
           db-activate-notifications (activate and/or commit) should not be done
           until after the reboot login; processing of db-activate does not
           complete until after receipt of the notifications and the reboot login.
        ";
      leaf rollback-timer {
        type string;
        description
          "hh-mm-ss";
      }
      uses timeout-command;
      uses command-reboot;
      uses is-async-command;
    }
  }

  container sw-manifest {
    presence "The sw-manifest instructions for swdl operations have been defined.";
    description
      "The manifest file provides instructions to a software download
       application to download and install a new software load into a vendor’s
       equipment.
       
       Software download files
           All vendor files for a software release should be stored in a
       separate directory. A unique directory would be used for each vendor,
       model and software release combination. This directory and all files in
       that directory will be accessible by the SFTP server.
           The software directory can be flat or hierarchical with
       subdirectories. The manifest file should be in the root directory of the
       software directory.
           A software directory must contain files for one and only one
       software release. 
       
       Manifest file name
           Each software release directory shall contain a manifest file for
       that release. The filename for the manifest file shall be sw-manifest.json.
      ";
    uses base-manifest {
      refine "sw-version" {
        mandatory true;
      }
    }
    list instruction-set {
      key "index";
      description
        "The instruction set for a list of sw-versions that can be upgraded to 
         the sw-version specified at the top of the manifest file.";
      leaf index {
        type uint8;
        description
          "The index for this instruction set.";
      }
      leaf-list from-sw-version {
        type string;
        description
          "The optional list of sw-versions that can be upgraded to the
           sw-version specified at the top of the sw-manifest file.
           
           If not specified, this instruction set is used to upgrade from
           any sw-version to the sw-version specified at the top of the
           sw-manifest file.
                               
           If multiple instruction sets are provided, from-sw-version
           should always be defined.";
      }
      leaf is-commit-sw-activate-async {
        type boolean;
        default "true";
        description
          "Is cancel-validation-timer (accept = true) supported as an
           async or sync command on the device? If supported as sync, the rpc response
           is used to determine success/failure instead of waiting for transient notifications
           of the result.
           NOTE: cancel-validation-timer (accept = false) requires a reboot so is
           always considered async";
      }
      leaf cancel-validation-timer-async-timeout {
        type uint16;
        description
          "timeout value to use for cancel-validation-timer when supported as
           an async command. If not specified, the global-async-timeout is used.";
      }
      leaf cancel-validation-timer-sync-timeout {
        type uint16;
        description
          "timeout value to use for cancel-validation-timer (accept = true) when
           supported as a sync command. If not specified, the global-sync-timeout
           is used.";
      }
      container sw-manifest-commands {
        description
          "The ordered list of commands to be processed. Since some yang
           implementations do not support ordered-by user, the list is also
           indexed by command-order. The commands should be processed
           in the order of command-order.
           
           Processing moves to the next command when:
           1. command is synchronous and rpc returns a successful result.
           2. command is asynchronous, the rpc returns a successful result,
           and
           2.1 expected successful notification(s) have been received; or
           2.2 timeout occurs.
           \t\t    
           Processing of the manifest file is aborted when:
           1. command is synchronous and rpc returns a failed result.
           2. command is asynchronous, and:
           2.1 the rpc returns a failed result; or
           2.2 a failed notification is received; or
           2.3 timeout occurs.
           \t\t     
           NOTE: behavior for timeouts (synchronous or asynchronous) may depend upon
           controller implementation per command. It may be considered either:
           - as a successful result
           - as a failed result
           - as a success or failure based on polling the device
          ";
        list sw-manifest-command {
          key "command-order";
          ordered-by user;
          description
            "The list of commands to be processed.";
          leaf command-order {
            type uint8;
            description
              "The order in which commands should be processed.";
          }
          leaf command {
            type identityref {
              base sw-manifest-commands;
            }
            mandatory true;
            description
              "The command to be processed.";
          }
          uses download-file-command;
          uses delete-file-command;
          uses sw-stage-command;
          uses sw-activate-command;
        }
      }
    }
  }
  container db-backup-manifest {
    presence "The db-backup-manifest template for db-backup operations has been defined.";
    description
      "The manifest file provides instructions to a database operations
       application to backup the database on a device.
       
       Since the files used for these operations are likely user selected,
       these manifest files are more likely used by the controller as a
       template to control the overall flow of a backup operation and provide
       a means of providing customized timeout values.
       
       The following strings will be recognized as parameters to be replaced
       by the user selected values: __LOCAL-FILE-PATH, __REMOTE-FILENAME.
       
       Manifest file name
           Each vendor/model combination can have a separate manifest file
       defined for backup. These shall be named db-backup-manifest.json.
      ";
    uses base-manifest;
    container db-backup-manifest-commands {
      description
        "The ordered list of commands to be processed. Since some yang
         implementations do not support ordered-by user, the list is also
         indexed by command-order. The commands should be processed
         in the order of command-order.
         
         Processing moves to the next command when:
            1. command is synchronous and rpc returns a successful result.
            2. command is asynchronous, the rpc returns a successful result,
               and
               2.1 expected successful notification(s) have been received; or
               2.2 timeout occurs.
                           
         Processing of the manifest file is aborted when:
            1. command is synchronous and rpc returns a failed result.
            2. command is asynchronous, and:
               2.1 the rpc returns a failed result; or
               2.2 a failed notification is received; or
               2.3 timeout occurs.
         
         NOTE: behavior for timeouts (synchronous or asynchronous) may depend upon
         controller implementation per command. It may be considered either:
             - as a successful result
             - as a failed result
             - as a success or failure based on polling the device
        ";
      list db-backup-manifest-command {
        key "command-order";
        ordered-by user;
        description
          "The list of commands to be processed.";
        leaf command-order {
          type uint8;
          description
            "The order in which commands should be processed.";
        }
        leaf command {
          type identityref {
            base db-backup-manifest-commands;
          }
          mandatory true;
          description
            "The command to be processed.";
        }
        uses upload-file-command;
        uses delete-file-command;
        uses db-backup-command;
      }
    }
  }
  container db-restore-manifest {
    presence "The db-restore-manifest template for db-restore operations has been defined.";
    description
      "The manifest file provides instructions to a database operations
       application to restore the database on a device.
       
       Since the files used for these operations are likely user selected,
       these manifest files are more likely used by the controller as a
       template to control the overall flow of a restore operation and provide
       a means of providing customized timeout and auto-reboot values.
       
       The following strings will be recognized as parameters to be replaced
       by the user selected values: __LOCAL-FILE-PATH, __REMOTE-FILENAME,
       __NODE-ID-CHECK.
       
       Manifest file name
           Each vendor/model combination can have a separate manifest file
       defined for restore. These shall be named db-restore-manifest.json.
      ";
    uses base-manifest;
    leaf is-commit-db-activate-async {
      type boolean;
      default "true";
      description
        "Is cancel-rollback-timer (accept = true) supported as an
         async or sync command on the device? If supported as sync, the rpc response
         is used to determine success/failure instead of waiting for transient notifications
         of the result.
         NOTE: cancel-rollback-timer (accept = false) requires a reboot so is
         always considered async";
    }
    leaf cancel-rollback-timer-async-timeout {
      type uint16;
      description
        "timeout value to use for cancel-rollback-timer when supported as
         an async command. If not specified, the global-async-timeout is used.";
    }
    leaf cancel-rollback-timer-sync-timeout {
      type uint16;
      description
        "timeout value to use for cancel-rollback-timer (accept = true) when
         supported as a sync command. If not specified, the global-sync-timeout
         is used.";
    }
    leaf database-init-sync-timeout {
      type uint16;
      description
        "timeout value to use for database-init command. If not specified,
         the global-sync-timeout is used.";
    }
    container db-restore-manifest-commands {
      description
        "The ordered list of commands to be processed. Since some yang
         implementations do not support ordered-by user, the list is also
         indexed by command-order. The commands should be processed
         in the order of command-order.
         
         Processing moves to the next command when:
            1. command is synchronous and rpc returns a successful result.
            2. command is asynchronous, the rpc returns a successful result,
               and
               2.1 expected successful notification(s) have been received; or
               2.2 timeout occurs.
                           
         Processing of the manifest file is aborted when:
            1. command is synchronous and rpc returns a failed result.
            2. command is asynchronous, and:
               2.1 the rpc returns a failed result; or
               2.2 a failed notification is received; or
               2.3 timeout occurs.
         
         NOTE: behavior for timeouts (synchronous or asynchronous) may depend upon
         controller implementation per command. It may be considered either:
             - as a successful result
             - as a failed result
             - as a success or failure based on polling the device
        ";
      list db-restore-manifest-command {
        key "command-order";
        ordered-by user;
        description
          "The list of commands to be processed.";
        leaf command-order {
          type uint8;
          description
            "The order in which commands should be processed.";
        }
        leaf command {
          type identityref {
            base db-restore-manifest-commands;
          }
          mandatory true;
          description
            "The command to be processed.";
        }
        uses download-file-command;
        uses delete-file-command;
        uses db-restore-command;
        uses db-activate-command;
      }
    }
  }
}
