Modules

Summary

Description

This is the MIB module for the SNMP Agent Extensibility
Protocol (AgentX).  This MIB module will be implemented by
the master agent.

Details

Summary

Description

This MIB module contains differentiated services
specific managed objects to perform higher-level
configuration management.  This MIB allows policies
to use 'templates' to instantiate Differentiated
Services functional datapath configurations to
be assigned (associated with an interface and
direction) when a policy is activated.

Copyright (C) The Internet Society (2004).  This version
of this MIB module is part of RFC 3747;  see the RFC
itself for full legal notices.

Details

Summary

Details

Summary

Description

This MIB defines the objects necessary to manage a device that
uses the Differentiated Services Architecture described in RFC
2475. The Conceptual Model of a Differentiated Services Router
provides supporting information on how such a router is modeled.

Details

Summary

Details

Summary

Description

This MIB module defines a MIB which provides mechanisms to
schedule SNMP set operations periodically or at specific
points in time.

Details

Summary

Details

Summary

Description

The MIB module for representing multiple logical
entities supported by a single SNMP agent.

Copyright (C) The Internet Society (2005).  This
version of this MIB module is part of RFC 4133; see
the RFC itself for full legal notices.

Details

Summary

Description

This module defines Entity MIB extensions for physical
sensors.

Copyright (C) The Internet Society (2002). This version
of this MIB module is part of RFC 3433; see the RFC
itself for full legal notices.

Details

Summary

Description

This MIB defines a state extension to the Entity MIB.

Copyright (C) The Internet Society 2005.  This version
of this MIB module is part of RFC 4268; see the RFC
itself for full legal notices.

Details

Summary

Description

This MIB defines state textual conventions.

Copyright (C) The Internet Society 2005.  This version
of this MIB module is part of RFC 4268;  see the RFC
itself for full legal notices.

Details

Summary

Description

The MIB module to describe generic objects for
ethernet-like network interfaces.

The following reference is used throughout this
MIB module:

[IEEE 802.3 Std] refers to:
   IEEE Std 802.3, 2002 Edition: 'IEEE Standard

   for Information technology -
   Telecommunications and information exchange
   between systems - Local and metropolitan
   area networks - Specific requirements -
   Part 3: Carrier sense multiple access with
   collision detection (CSMA/CD) access method
   and physical layer specifications', as
   amended by IEEE Std 802.3ae-2002:
   'Amendment: Media Access Control (MAC)
   Parameters, Physical Layer, and Management
   Parameters for 10 Gb/s Operation', August,
   2002.

Of particular interest is Clause 30, '10 Mb/s,
100 Mb/s, 1000 Mb/s, and 10 Gb/s Management'.

Copyright (C) The Internet Society (2003).  This
version of this MIB module is part of RFC 3635;
see the RFC itself for full legal notices.

Details

Summary

Description

A MIB module containing textual conventions
for high capacity data types. This module
addresses an immediate need for data types not directly
supported in the SMIv2. This short-term solution
is meant to be deprecated as a long-term solution
is deployed.

Details

Summary

Description

This MIB is for use in managing host systems. The term
`host' is construed to mean any computer that communicates
with other similar computers attached to the internet and
that is directly used by one or more human beings. Although
this MIB does not necessarily apply to devices whose primary
function is communications services (e.g., terminal servers,
routers, bridges, monitoring equipment), such relevance is
not explicitly precluded.  This MIB instruments attributes
common to all internet hosts including, for example, both
personal computers and systems that run variants of Unix.

Details

Summary

Description

This MIB module registers type definitions for
storage types, device types, and file system types.

After the initial revision, this module will be
maintained by IANA.

Details

Summary

Details

Summary

Description

The MIB module registers object identifier values for
well-known programming and scripting languages. Every
language registration MUST describe the format used
when transferring scripts written in this language.

Any additions or changes to the contents of this MIB
module require Designated Expert Review as defined in
the Guidelines for Writing IANA Considerations Section
document. The Designated Expert will be selected by
the IESG Area Director of the OPS Area.

Note, this module does not have to register all possible
languages since languages are identified by object
identifier values. It is therefore possible to registered 
languages in private OID trees. The references given below are not
normative with regard to the language version. Other
references might be better suited to describe some newer 
versions of this language. The references are only
provided as `a pointer into the right direction'.

Details

Summary

Description

This MIB module defines the IANAipRouteProtocol and
IANAipMRouteProtocol textual conventions for use in MIBs
which need to identify unicast or multicast routing
mechanisms.

Any additions or changes to the contents of this MIB module
require either publication of an RFC, or Designated Expert
Review as defined in RFC 2434, Guidelines for Writing an
IANA Considerations Section in RFCs.  The Designated Expert 
will be selected by the IESG Area Director(s) of the Routing
Area.

Details

Summary

Description

This MIB module defines the IANAifType Textual
Convention, and thus the enumerated values of
the ifType object defined in MIB-II's ifTable.

Details

Summary

Description

This module contains a collection of generally useful derived
YANG data types for Internet addresses and related things.

Copyright (c) 2010 IETF Trust and the persons identified as
the document authors.  All rights reserved.

Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).

This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.

Details

Summary

Description

IPFIX/PSAMP Configuration Data Model

Copyright (c) 2010 IETF Trust and the persons identified as
the document authors.  All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).

Details

Summary

Description

NETCONF Protocol Data Types and RPC methods.

Copyright (c) 2010 IETF Trust and the persons identified as
the document authors.  All rights reserved.

Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).

This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.

Details

Summary

Description

NETCONF Monitoring Module.
All elements in this module are read-only.

Copyright (c) 2010 IETF Trust and the persons identified as
the document authors.  All rights reserved.

Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).

This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.

Details

Summary

Details

Summary

Description

This module defines a capability-based extension to the
NETCONF protocol that allows the NETCONF client to control
whether default values are part of NETCONF
<rpc-reply> messages or <copy-config> output to the target URL.


Copyright (c) 2010 IETF Trust and the persons identified as
the document authors.  All rights reserved.

Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).

This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.

Details

Summary

Description

This module contains a collection of generally useful derived
YANG data types.

Copyright (c) 2010 IETF Trust and the persons identified as
the document authors.  All rights reserved.

Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).

This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.

Details

Summary

Details

Summary

Description

The MIB module to describe generic objects for network
interface sub-layers.  This MIB is an updated version of
MIB-II's ifTable, and incorporates the extensions defined in
RFC 1229.

Details

Summary

Description

This MIB module defines textual conventions for
representing Internet addresses.  An Internet
address can be an IPv4 address, an IPv6 address,
or a DNS domain name.  This module also defines
textual conventions for Internet port numbers,
autonomous system numbers, and the length of an
Internet address prefix.

Copyright (C) The Internet Society (2005).  This version
of this MIB module is part of RFC 4001, see the RFC
itself for full legal notices.

Details

Summary

Details

Summary

Description

The MIB module for managing IP and ICMP implementations, but
excluding their management of IP routes.

Copyright (C) The Internet Society (2006).  This version of
this MIB module is part of RFC 4293; see the RFC itself for
full legal notices.

Details

Summary

Details

Summary

Details

Summary

Details

Summary

Details

Summary

Description

Remote network monitoring devices, often called
monitors or probes, are instruments that exist for
the purpose of managing a network. This MIB defines
objects for managing remote network monitoring devices.

Details

Summary

Description

The SNMP Management Architecture MIB

Copyright (C) The Internet Society (2002). This
version of this MIB module is part of RFC 3411;
see the RFC itself for full legal notices.

Details

Summary

Description

The MIB for Message Processing and Dispatching

Copyright (C) The Internet Society (2002). This
version of this MIB module is part of RFC 3412;
see the RFC itself for full legal notices.

Details

Summary

Description

This MIB module defines MIB objects which provide
mechanisms to remotely configure the parameters
used by an SNMP entity for the generation of
notifications.

Copyright (C) The Internet Society (2002). This
version of this MIB module is part of RFC 3413;
see the RFC itself for full legal notices.

Details

Summary

Description

This MIB module defines MIB objects which provide
mechanisms to remotely configure the parameters used
by an SNMP entity for the generation of SNMP messages.

Copyright (C) The Internet Society (2002). This
version of this MIB module is part of RFC 3413;
see the RFC itself for full legal notices.

Details

Summary

Description

Definitions of Object Identities needed for
the use of AES by SNMP's User-based Security
Model.

Copyright (C) The Internet Society (2004).

This version of this MIB module is part of RFC 3826;
see the RFC itself for full legal notices.
Supplementary information may be available on
http://www.ietf.org/copyrights/ianamib.html.

Details

Summary

Description

The MIB module for SNMP entities.

Copyright (C) The Internet Society (2002). This
version of this MIB module is part of RFC 3418;
see the RFC itself for full legal notices.

Details

Summary

Details

Summary

Description

The MIB module for SNMP transport mappings.

Copyright (C) The Internet Society (2002). This
version of this MIB module is part of RFC 3417;
see the RFC itself for full legal notices.

Details

Summary

Details

Summary

Description

This MIB module provides commonly used transport
address definitions.

Copyright (C) The Internet Society (2002). This version of
this MIB module is part of RFC 3419; see the RFC itself for
full legal notices.

Details

Summary

Details

Summary

Description

Command Line Interface for the NETCONF protocol: Client side

Usage:
   yangcli [parameters]


Normal Mode:
   An interactive CLI shell with command line history.

Autostart-mode:
   If the 'server' parameter is present, then yangcli will
   attempt to connect to that server upon startup.  If the
   'user' and 'password' parameters are also present, then
   the user will not be prompted before the connection
   is attempted.  This parameter will be processed first,
   if script-mode or batch-mode is used.

Script-mode:
   If the 'run-script' or 'run-command' parameter is present,
   then the specified script or command will be run 
   automatically upon startup.

Batch-mode:
   If the 'batch-mode' parameter is present, then either the
   'run-script' or 'run-command' parameter will be invoked, if
   present, and then the program will exit.

Autostart-mode:
   If the 'server' parameter is present, then yangcli will
    attempt to connect to that server upon startup.  If the
   'user' and 'password' parameters are also present, then
   the user will not be prompted before the connection 
   is attempted.

 Script-mode:
    If the 'run-script' parameter is present, then the
    specified script will be run automatically upon startup.

 

Details

Summary

Description

yangdiff compares the semantics and syntax between 
two revisions of the same YANG module.  The 
conceptual data model is compared, not the 
individual files.  

For example, unless statement order is significant,
changing the order is not considered a change, and 
is not reported.  Reformatted test (whitespace changes)
are also not reported.

If a data type definition is changed in form,
but not content, then a 'modify type' message
will be generated, but no additional sub-fields
will be reported.

INPUT FILES

   To compare one module, use the 'old' and 'new'
   parameters to specify YANG module files,
   each with a filespec string ending with the '.yang'
   file extension.  The filespecs must represent
   different files.  If the 'old' parameter represents
   a directory, then this directory will be searched
   for the 'new' filename.

   To compare all the modules in a subtree, use the 
   'old' and 'new' parameters to specify a directory
   to be searched for YANG modules to be processed.
   In this mode, each new module is compared to
   a corresponding file within the 'old' subtree.
   Also, dependency and include files
   will be kept separate, for each subtree.
   
   Unless the 'help' or 'version' parameters is entered, 
   the 'old' and 'new' parameters must be present.

SEARCH PATH

    When a module name is entered as input, or when a
    module or submodule name is specified in an import or include
    statement within the file, the following search algorithm
    is used to find the file:

    1) if the parameter for the file that generated the
       search request represents a subtree, search that
       subtree first.
    2) file is in the current directory
    3) YANG_MODPATH environment var (or set by modpath parameter)
    4) $HOME/modules directory
    5) $YANG_HOME/modules directory
    6) $YANG_INSTALL/modules directory OR
       default install module location, '/usr/share/yang/modules'

    By default, the entire directory tree for all locations
    (except step 1) will be searched, not just the specified
    directory.  The 'subdirs' parameter can be used to
    prevent sub-directories from being searched.

    Any directory name beginning with a dot character '.'
    will be skipped.  Also, any directory named 'CVS' will
    be skipped in directory searches.

OUTPUT MODES

    By default, any comparison output will be sent to STDOUT.

    The 'output' parameter can be used to specify the 
    full filespec of the output file,  or a
    complete directory specification to be combined
    with the default filename (yangdiff.log).

ERROR LOGGING

    By default, warnings and errors are sent to STDOUT.

    A log file can be specified instead with the 'log' parameter.
    Existing log files can be reused with the 'logappend'
    parameter, otherwise log files are overwritten.

    The logging level can be controlled with the 'log-level'
    parameter.  The default log level is 'info'.  The
    log-levels are additive:

       off:    suppress all errors (not recommended!)
	       A program return code of '1' indicates some error.
       error:  print errors
       warn:   print warnings
       info:   print generally interesting trace info
       debug:  print general debugging trace info
       debug2: print verbose debugging trace info

Details

Summary

Description

yangdump provides validation and translation of YANG data 
models. Information about a module or submodule can be 
generated as well.

INPUT FILES

   Operations can be performed on one or more files with 
   the 'module' parameter, or an entire directory tree 
   with the 'subtree' parameter.  Unless the 'help' or
   'version' parameters is entered, one of these input
   parameters must be present.

SEARCH PATH

    When a module name is entered as input, or when a
    module or submodule name is specified in an import or include
    statement within the file, the following search algorithm
    is used to find the file:

    1) file is in the current directory
    2) YUMA_MODPATH environment var (or set by modpath parameter)
    3) $HOME/modules directory
    4) $YUMA_HOME/modules directory
    5) $YUMA_INSTALL/modules directory OR
       default install module location, '/usr/share/yuma/modules'

    By default, the entire directory tree for all locations
    (except step 1) will be searched, not just the specified
    directory.  The 'subdirs' parameter can be used to
    prevent sub-directories from being searched.

    Any directory name beginning with a dot character '.'
    will be skipped.  Also, any directory named 'CVS' will
    be skipped in directory searches.

TRANSLATION MODES

    The 'format' parameter is used to select a translation output mode.
    If it is missing, then no translation will be done.
    This parameter can be used with the module reports parameters,
    but the translation output should be directed to a file
    instead of STDOUT to keep them separated.

    For XSD 1.0 translation, use the 'format=xsd' parameter.

    For XHTML 1.0 translation, use the 'format=html' parameter.

    For YIN translation, use the 'format=yin' parameter.

MODULE REPORTS

    For a 1 line output of the module name and version,
    use the 'modversion' parameter.

    For a listing of all the symbols that the file exports
    to other files, use the 'exports' parameter.

    For a listing of all the files that the file depends on,
    to compile, use the 'dependencies' parameter.

    For a listing of all the accessible object identifiers that
    the file contains, use the 'identifiers' parameter.

OUTPUT MODES

    By default, any translation output will be sent to STDOUT.

    The 'output' parameter can be used to specify the 
    full filespec of the output file,  or a
    partial directory specification to be combined
    with a default filename.

    The 'defnames' parameter can be used to generate a default
    filename in the current directory for the output, or
    in the 'output' directory, if one is specified.

    By default, an output filename will have the form:

	  <module-name>.<module-revision>.<ext>

    If the 'versionnames=false' parameter is used, then the
    default filename will have the form:

	  <module-name>.<ext>

    This parameter will also affect URL generation during
    HTML translation.

    When the 'subtree' input parameter is used for XSD or HTML
    translation, the 'defnames' parameter will be automatically
    set to 'true', to maintain well-formed XML documents when
    multiple translations are possible.

    If the 'unified' parameter is set to 'true', then all 
    submodules will be processed when the input is a main 
    module that includes any submodules.  For XSD and HTML
    translation, the submodule content will be generated
    instead of an 'include' statement.  Submodule files 
    will be skipped in 'subtree' mode.

ERROR LOGGING

    By default, warnings and errors are sent to STDOUT.

    A log file can be specified instead with the 'log' parameter.
    Existing log files can be reused with the 'logappend'
    parameter, otherwise log files are overwritten.

    The logging level can be controlled with the 'log-level'
    parameter.  The default log level is 'info'.  The
    log-levels are additive:

       off:    suppress all errors (not recommended!)
	       A program return code of '1' indicates some error.
       error:  print errors
       warn:   print warnings
       info:   print generally interesting trace info
       debug:  print general debugging trace info
       debug2: print verbose debugging trace info

Details

Summary

Details

Summary

Details

Summary

Details

Summary

Details

Summary

Description

This module contains definitions for 
Yuma Netconf extensions.

The elements will be present in appinfo elements,
used in YANG to XSD translation.

Details

Summary

Details

Summary

Details

Summary

Details

Summary

Details

Summary

Details