smilint output for ./PW-TC-STD-MIB

Messages:

PW-TC-STD-MIB

   1: -- extracted from draft-ietf-pwe3-pw-tc-mib-12.txt
   2: -- at Mon Sep 24 06:09:07 2007

   3: 
   4:    PW-TC-STD-MIB DEFINITIONS ::= BEGIN
   5: 
   6:    IMPORTS
   7:       MODULE-IDENTITY, Unsigned32, transmission
   8:          FROM SNMPv2-SMI               -- [RFC2578]
   9: 
  10:       TEXTUAL-CONVENTION
  11:          FROM SNMPv2-TC;               -- [RFC2579]
  12: 
  13:    pwTcStdMIB MODULE-IDENTITY
  14:       LAST-UPDATED "200709181200Z"  -- 18 September 2007 12:00:00 GMT
  15:       ORGANIZATION "Pseudowire Edge-to-Edge Emulation (PWE3) Working
  16:                     Group"
  17:       CONTACT-INFO
  18:       " Thomas D. Nadeau
  19:         Email:  tnadeau@cisco.com
  20: 
  21:         David Zelig
  22:         Email: davidz@corrigent.com
  23: 
  24:         Orly Nicklass
  25:         Email: orly.nicklass@SeabridgeNetworks.com
  26: 
  27:         The PWE3 Working Group (email distribution pwe3@ietf.org,
  28:         http://www.ietf.org/html.charters/pwe3-charter.html)
  29:        "
  30: 
  31:       DESCRIPTION
  32:            "This MIB module defines TEXTUAL CONVENTIONs
  33:             for concepts used in Pseudowire Edge-to-Edge
  34:             networks.
  35: 
  36:             Copyright (C) The IETF Trust (2007). The
  37:             initial version of this MIB module as published
  38:             in RFC YYYY. For full legal notices see the RFC
  39:             itself or see:
  40:             http://www.ietf.org/copyrights/ianamib.html
  41: 
  42:    -- RFC Editor: Please replace YYYY with the RFC number and remove
  43:    -- this note.
  44:                "
  45:       -- Revision history.
  46: 
  47:       REVISION "200709181200Z"  -- 18 September 2007 12:00:00 GMT
  48:       DESCRIPTION
  49:            "Original Version"
  50:          ::= { transmission XXXX }

  51:    -- RFC Editor: please replace XXXX with IANA assigned value and
  52:    -- delete this note.
  53: 
  54:    PwGroupID ::= TEXTUAL-CONVENTION

  55:       DISPLAY-HINT "d"
  56:       STATUS      current
  57:       DESCRIPTION
  58:            "An administrative identification for grouping a
  59:             set of service-specific pseudowire services."
  60:       SYNTAX  Unsigned32
  61: 
  62:    PwIDType ::= TEXTUAL-CONVENTION

  63:       DISPLAY-HINT "d"
  64:       STATUS      current
  65:       DESCRIPTION
  66:            "Pseudowire Identifier. Used to identify the PW
  67:             (together with some other fields) in the signaling
  68:             session."
  69:       SYNTAX  Unsigned32
  70: 
  71:    PwIndexType ::= TEXTUAL-CONVENTION

  72:       DISPLAY-HINT "d"
  73:       STATUS      current
  74:       DESCRIPTION
  75:            "Pseudowire Index. A unique value, greater than zero,
  76:            for each locally-defined PW for indexing
  77:            several MIB tables associated with the particular PW.
  78:            It is recommended that values are assigned contiguously
  79:            starting from 1.  The value for each PW MUST remain
  80:            constant at least from one re-initialization
  81:            to the next re-initialization."
  82:       SYNTAX  Unsigned32 (1..4294967295)
  83: 
  84:    PwIndexOrZeroType ::= TEXTUAL-CONVENTION

  85:       DISPLAY-HINT "d"
  86:       STATUS      current
  87:       DESCRIPTION
  88:            "This textual convention is an extension of the
  89:             PwIndexType convention.  The latter defines a greater-
  90:             than-zero value used to identify a Pseudowire
  91:             in the managed system.  This extension permits the
  92:             additional value of zero. The zero value is object-specific
  93:             and MUST therefore be defined as part of the description of
  94:             any object which uses this syntax.  Examples of the usage of
  95:             zero might include situations where Pseudowire was unknown,
  96:             or when none or all Pseudowires need to be referenced."
  97:        SYNTAX  Unsigned32 (0..4294967295)
  98: 
  99:    PwVlanCfg ::= TEXTUAL-CONVENTION

 100:       DISPLAY-HINT "d"
 101:       STATUS      current
 102:       DESCRIPTION
 103:            "VLAN configuration for Ethernet PW.
 104:             Values between 0 and 4095 indicate the actual VLAN field
 105:             value.
 106:             A value of 4096 indicates that the object refers to
 107:             untagged frames, i.e. frames without a 802.1Q field.
 108:             A value of 4097 indicates that the object is not
 109:             relevant."
 110: 
 111:       SYNTAX  Unsigned32 (0..4097)
 112: 
 113:    PwOperStatusTC ::= TEXTUAL-CONVENTION

 114:       STATUS      current
 115:       DESCRIPTION
 116:         "Indicates the operational status of the PW.
 117: 
 118:         - up(1):            Ready to pass packets.
 119:         - down(2):          If PW signaling is not yet finished, or
 120:                             indications available at the service
 121:                             level indicate that the PW is not
 122:                             passing packets.
 123:         - testing(3):       If AdminStatus at the PW level is set to
 124:                             test.
 125:         - dormant(4):       The PW is not in a condition to pass
 126:                             packets, but is in a 'pending' state,
 127:                             waiting for some external event.
 128:         - notPresent(5):    Some component is missing to accomplish
 129:                             the setup of the PW. It can be configuration
 130:                             error, incomplete configuration or missing
 131:                             of H/W component.
 132:         - lowerLayerDown(6):One or more of the lower-layer interfaces
 133:                             responsible for running the underlying PSN
 134:                             is not in OperStatus 'up' state."
 135:     SYNTAX   INTEGER {
 136:         up(1),
 137:         down(2),
 138:         testing(3),
 139:         dormant(4),
 140:         notPresent(5),
 141:         lowerLayerDown(6)
 142:         }
 143: 
 144:    PwAttachmentIdentifierType ::= TEXTUAL-CONVENTION

 145:       STATUS      current
 146:       DESCRIPTION
 147:          "An octet string used in the generalized FEC element for
 148:           identifying attachment forwarder and groups. A NULL
 149:           identifier is of zero length.
 150:          "
 151:      SYNTAX    OCTET STRING (SIZE (0..255))
 152: 
 153:    PwGenIdType ::= TEXTUAL-CONVENTION

 154:       STATUS      current
 155:       DESCRIPTION
 156:          "Represents the AGI Type and AII Type in generalized FEC
 157:           signaling and configuration.
 158:          "
 159: 
 160:      SYNTAX    Unsigned32( 0..254 )
 161: 
 162:    PwCwStatusTC ::= TEXTUAL-CONVENTION

 163:       STATUS      current
 164:       DESCRIPTION
 165:          "Indicates the status of the control word negotiation based
 166:           on the local configuration and the indications received from
 167:           the peer node.
 168: 
 169:           waitingForNextMsg(1) indicates that the node is waiting for
 170:           another label mapping from the peer.
 171: 
 172:           sentWrongBitErrorCode(2) indicates that the local node has
 173:           notified the peer about a mismatch in the C bit.
 174: 
 175:           rxWithdrawWithWrongBitErrorCode(3) indicates that a withdraw
 176:           message has been received with the wrong C-bit error code.
 177: 
 178:           illegalReceivedBit(4) indicates a C-bit configuration with
 179:           the peer which is not compatible with the PW type.
 180: 
 181:           cwPresent(5) indicates that the CW is present for this PW:
 182:           If signaling is used - the C bit is set and agreed between the
 183:           nodes, and for manualy-configured PW the local configuration
 184:           requires the use of the CW.
 185: 
 186:           cwNotPresent(6) indicates that the CW is not present for
 187:           this PW: If signaling is used - the C bit is reset and agreed
 188:           between the nodes, and for manualy-configured PW the local
 189:           configuration requires that the CW not be used.
 190: 
 191:           notYetKnown(7) indicates that a label mapping has not yet
 192:           been received from the peer.
 193:          "
 194:       REFERENCE
 195:          "Martini, et al, 'Pseudowire Setup and Maintenance using
 196:           the Label Distribution Protocol', [RFC4447]."
 197: 
 198:       SYNTAX    INTEGER {
 199:                  waitingForNextMsg (1),
 200:                  sentWrongBitErrorCode (2),
 201:                  rxWithdrawWithWrongBitErrorCode (3),
 202:                  illegalReceivedBit (4),
 203:                  cwPresent (5),
 204:                  cwNotPresent (6),
 205:                  notYetKnown(7)
 206:                  }
 207: 
 208:    PwStatus ::= TEXTUAL-CONVENTION

 209:       STATUS      current
 210:       DESCRIPTION
 211:          "Indicates the status of the PW and the interfaces affecting
 212:           this PW. If none of the bits are set, it indicates no faults
 213:           are reported.
 214:          "
 215:       SYNTAX   BITS {
 216:         pwNotForwarding (0),
 217:         servicePwRxFault (1),
 218:         servicePwTxFault (2),
 219:         psnPwRxFault  (3),
 220:         psnPwTxFault  (4)
 221:         }
 222: 
 223:    PwFragSize ::= TEXTUAL-CONVENTION

 224:       DISPLAY-HINT "d"
 225:       STATUS      current
 226:       DESCRIPTION
 227:          "If set to a value other than zero, it indicates the desired
 228:           fragmentation length in bytes. If set to zero,
 229:           fragmentation is not desired for PSN bound packets.
 230:          "
 231:       SYNTAX   Unsigned32
 232: 
 233:    PwFragStatus ::= TEXTUAL-CONVENTION

 234:       STATUS      current
 235:       DESCRIPTION
 236:          "Indicates the status of the fragmentation process based on
 237:           local configuration and peer capability.
 238: 
 239:           noFrag(0) bit indicates that local configuration is for no
 240:           fragmentation.
 241: 
 242:           cfgFragGreaterThanPsnMtu(1) bit indicates the local node
 243:           is set to fragment, but the fragmentation size is greater
 244:           than the MTU available at the PSN between the nodes.
 245:           Fragmentation is not done in this case.
 246: 
 247:           cfgFragButRemoteIncapable(2) bit indicates that the local
 248:           configuration indicates the desire for fragmentation but
 249:           the peer is not capable of fragmentation.
 250: 
 251:           remoteFragCapable(3) bit indicates that the remote node
 252:           is capable to accept fragmented PDUs.
 253: 
 254:           fragEnabled(4) bit indicates that fargmenteation will be used
 255:           on this PW. Fragmentation can be used if the local node was
 256:           configured for fragmentation, the peer has the cabability
 257:           to accept fragmented packets, and the CW is in use for this
 258:           PW."
 259: 
 260:       REFERENCE
 261:           "Malis, A. and M. Townsley, 'Pseudowire Emulation Edge-to-
 262:            Edge (PWE3) Fragmentation and Reassembly', [RFC4623]."
 263:       SYNTAX   BITS {
 264:          noFrag (0),
 265:          cfgFragGreaterThanPsnMtu (1),
 266:          cfgFragButRemoteIncapable (2),
 267:          remoteFragCapable (3),
 268:          fragEnabled (4)
 269:          }
 270: 
 271:    PwCfgIndexOrzero ::= TEXTUAL-CONVENTION

 272:       DISPLAY-HINT "d"
 273:       STATUS      current
 274:       DESCRIPTION
 275:            "Index in any of the relevant configuration tables for
 276:            supplement information regarding configuration of the
 277:            specific technology. Value 0 implies no additional
 278:            configuration information is applicable."
 279:       SYNTAX  Unsigned32 (0..4294967295)
 280:    END
 281: 
 282: -- 
 283: --    Copyright (C) The IETF Trust (2007).
 284: -- 
 285: --    This document is subject to the rights, licenses and restrictions
 286: --    contained in BCP 78, and except as set forth therein, the authors
 287: --    retain all their rights.
 288: -- 
 289: --    This document and the information contained herein are provided on an
 290: --    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 291: --    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
 292: --    THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
 293: --    OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 294: --    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 295: --    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 296: -- 
 297: -- 
 298: -- Intellectual Property
 299: -- 
 300: --    The IETF takes no position regarding the validity or scope of any
 301: --    Intellectual Property Rights or other rights that might be claimed to
 302: --    pertain to the implementation or use of the technology described in
 303: --    this document or the extent to which any license under such rights
 304: --    might or might not be available; nor does it represent that it has
 305: --    made any independent effort to identify any such rights.  Information
 306: --    on the procedures with respect to rights in RFC documents can be
 307: --    found in BCP 78 and BCP 79.
 308: -- 
 309: --    Copies of IPR disclosures made to the IETF Secretariat and any
 310: --    assurances of licenses to be made available, or the result of an
 311: --    attempt made to obtain a general license or permission for the use of
 312: --    such proprietary rights by implementers or users of this
 313: --    specification can be obtained from the IETF on-line IPR repository at
 314: --    http://www.ietf.org/ipr.
 315: -- 
 316: --    The IETF invites any interested party to bring to its attention any
 317: --    copyrights, patents or patent applications, or other proprietary
 318: --    rights that may cover technology that may be required to implement
 319: --    this standard.  Please address the information to the IETF at
 320: --    ietf-ipr@ietf.org.
 321: -- 
 322: -- 
 323: -- Acknowledgment
 324: -- 
 325: --    Funding for the RFC Editor function is provided by the IETF
 326: --    Administrative Support Activity (IASA).
 327: