Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4780

Management Information Base for the Session Initiation Protocol (SIP)

Pages: 83
Proposed Standard
Part 1 of 3 – Pages 1 to 15
None   None   Next

Top   ToC   RFC4780 - Page 1
Network Working Group                                          K. Lingle
Request for Comments: 4780                           Cisco Systems, Inc.
Category: Standards Track                                      J-F. Mule
                                                               CableLabs
                                                                J. Maeng
                                                               D. Walker
                                                              April 2007


                    Management Information Base for
                 the Session Initiation Protocol (SIP)

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that are used to manage Session Initiation Protocol (SIP) entities, which include User Agents, and Proxy, Redirect and Registrar servers.
Top   ToC   RFC4780 - Page 2

Table of Contents

1. Introduction ....................................................2 2. Conventions .....................................................2 3. The Internet-Standard Management Framework ......................2 4. Overview ........................................................3 5. Structure of the SIP MIB ........................................3 5.1. Textual Conventions ........................................6 5.2. Relationship to the Network Services MIB ...................6 5.3. IMPORTed MIB Modules and REFERENCE Clauses ................10 6. Accommodating SIP Extension Methods ............................11 7. Definitions ....................................................12 7.1. SIP Textual Conventions ...................................12 7.2. SIP Common MIB Module .....................................15 7.3. SIP User Agent MIB Module .................................55 7.4. SIP Server MIB Module (Proxy, Redirect, and Registrar Servers) ........................................59 8. IANA Considerations ............................................77 9. Security Considerations ........................................78 10. Contributor Acknowledgments ...................................80 11. References ....................................................80 11.1. Normative References .....................................80 11.2. Informative References ...................................81

1. Introduction

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that are used to manage Session Initiation Protocol (SIP) entities, which include User Agents, and Proxy, Redirect and Registrar servers. The managed objects defined in this document are intended to provide basic SIP protocol management for SIP entities. The management of application-specific or service-specific SIP configuration is out of scope.

2. 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 RFC 2119 [RFC2119].

3. 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].
Top   ToC   RFC4780 - Page 3
   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 set
   of MIB modules that are compliant to the SMIv2, which is described in
   STD 58, comprised of RFC 2578 [RFC2578], RFC 2579 [RFC2579], and RFC
   2580 [RFC2580].

4. Overview

SIP [RFC3261] is an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. This MIB provides some managed objects for SIP entities defined in RFC 3261 [RFC3261] - User Agents (UA), and Proxy, Redirect, and Registrar servers. It is intended to provide management of the basic SIP entities. It provides for monitoring of status and protocol statistics, as well as for configuration of SIP entities.

5. Structure of the SIP MIB

Four MIB modules are specified: SIP-COMMON-MIB, SIP-SERVER-MIB, SIP- UA-MIB, and SIP-TC-MIB. SIP-COMMON-MIB contains common MIB objects used in all the SIP entities. SIP-SERVER-MIB contains objects specific to Proxy, Redirect, and Registrar servers. SIP-UA-MIB includes objects specific to User Agents. SIP-TC-MIB defines the textual conventions used throughout the MIB modules. The MIB modules contain the following groups of objects: SIP-COMMON-MIB: Management objects common to all the SIP entities o sipCommonMIBObjects * sipCommonCfgBase: This object group defines configuration objects common to all SIP entities, including the SIP protocol version, the type of SIP entity (UA, proxy, redirect, registrar servers), the operational and administrative status, the SIP organization name, the maximum number of SIP transactions an entity can manage, etc. * sipCommonCfgTimer: This object group defines timer configuration objects applicable to SIP user agent and stateful SIP proxy entities.
Top   ToC   RFC4780 - Page 4
      *  sipCommonSummaryStats: This object group defines a table
         containing the summary statistics objects applicable to all SIP
         entities, including the total number of all SIP requests and
         responses in/out and the total number of transactions.

      *  sipCommonMethodStats: This object group defines a table
         containing the SIP method statistics objects applicable to all
         SIP entities, including the number of outbound and inbound
         requests on a per method basis.  Retransmissions, where
         appropriate, are also included in these statistics.

      *  sipCommonStatusCode: This object group defines a table
         indicating the number of SIP responses (in and out) that the
         SIP entity has been requested to monitor on a per-method basis
         (100, 200, 302, etc.).

      *  sipCommonStatsTrans: This object group defines a table
         containing a gauge reflecting the number of transactions
         currently awaiting definitive responses by the managed SIP
         entity.

      *  sipCommonStatsRetry: This object group defines statistic
         objects indicating the number of retransmissions sent on a
         per-method basis.

      *  sipCommonOtherStats: This object group defines additional
         statistics objects including the number of SIP requests
         received with unsupported URIs, the number of requests received
         with unsupported SIP methods, and the number of discarded
         messages.

      *  sipCommonNotifObjects: This object group defines objects
         accessible only via a notification (MAX ACCESS clause of
         accessible-for-notify): they are related to the SNMP
         notifications defined in this MIB module.

   The SIP-COMMON-MIB also contains notifications, including:

   o  sipCommonStatusCodeNotif: indicates that a specific status code
      has been sent or received by the system.

   o  sipCommonStatusCodeThreshExceededNotif: indicates that a specific
      status code has been sent or received by the system frequently
      enough to exceed the configured threshold.
Top   ToC   RFC4780 - Page 5
   SIP-SERVER-MIB: Groups of objects for SIP Proxy, Redirect, and
   Registrar servers

   o  sipServerMIBObjects

      *  sipServerCfg: This object group defines common server
         configuration objects including the SIP server host address.

      *  sipServerProxyCfg: This object group defines configuration
         objects for SIP Proxy Servers including the proxy mode of
         operation (stateless, stateful, call stateful), the proxy
         authentication method(s), realm, etc.

      *  sipServerProxyStats: This object group defines a table
         containing the statistics objects applicable to SIP Proxy
         Servers.  It includes the number of occurrences of unsupported
         options being specified in received Proxy-Require headers.

      *  sipServerRegCfg: This object group defines common configuration
         objects for SIP Registrar servers, including the ability to
         accept third-party registrations, such as the maximum
         registration expiry that may be requested by user agents, the
         maximum number of users the registrar can support, the number
         of currently registered users, per contact registration
         information, etc.

      *  sipServerRegStats: This object group contains summary
         statistics objects for SIP Registrar servers.  Precisely, it
         contains the number of REGISTER requests that have been
         accepted or rejected.

   SIP-UA-MIB: Group of objects for SIP User Agents

   o  sipUAMIBObjects

      *  sipUACfgServer: This object group specifies SIP server
         configuration objects applicable to SIP user agents including
         the Internet address of the SIP Server the UA uses to register,
         proxy, or redirect calls.

   To conform with this specification, an SNMP agent MUST implement the
   SIP-TC-MIB module, plus the SIP-COMMON-MIB module and one of the SIP
   entity-type-specific MIB modules (SIP-SERVER-MIB or SIP-UA-MIB) as
   applicable for each instance of a SIP entity being managed.  If a
   device has more than one SIP entity or multiple instances of the same
   entity type, it MUST implement multiple SIP modules.  Section 5.2
   describes handling of multiple instances in detail.
Top   ToC   RFC4780 - Page 6

5.1. Textual Conventions

The data types SipTCTransportProtocol, SipTCEntityRole, SipTCOptionTagHeaders, and SipTCMethodName are defined in the SIP- TC-MIB module and used as Textual Conventions in this document.

5.2. Relationship to the Network Services MIB

In the design of the SIP MIB, the authors considered the following requirement: the SIP MIB must allow a single system with a single SNMP agent to support multiple instances of various SIP MIB modules. This requirement is met by using the framework provided by the Network Services Monitoring MIB, NETWORK-SERVICES-MIB, RFC 2788 [RFC2788]. A device implementing the SIP MIB MUST support the NETWORK-SERVICES- MIB and, at a minimum, MUST support the index and name objects (applIndex and applName) in the application table (applTable). In order to allow each instance of a SIP entity to be managed as a separate network service application, a naming convention SHOULD be used to make the application name unique. For example, if a system is running 2 SIP UAs that need to be managed as 2 separate SIP entities, by convention, the application names used in the Network Services Monitoring MIB application table should be "sip_ua1" and "sip_ua2". This convention allows each instance to have its own row in the application table (applTable). It is therefore RECOMMENDED that the following application name conventions be adopted: o for a SIP Proxy entity, the applName value SHOULD be equal to a character string starting with "sip_proxy" followed by a unique application instance identifier, for example, "sip_proxy1", "sip_proxy17". o for a SIP Registrar entity, the applName value SHOULD be equal to a character string starting with "sip_registrar" followed by a unique application instance identifier, for example, "sip_registrar1", "sip_registrar2". o for a SIP User Agent entity, the applName value SHOULD be equal to a character string starting with "sip_ua" followed by a unique application instance identifier, for example, "sip_ua1", "sip_ua2".
Top   ToC   RFC4780 - Page 7
   o  for any combination of Proxy, Registrar, or Redirect Server being
      managed as a single aggregate entity, the applName value for the
      combined server entity SHOULD reflect the appropriate combination
      followed by a unique application instance identifier.  In order to
      facilitate consistent agent behavior and management application
      expectations, the following order of names is RECOMMENDED:

         *  if Proxy exists, list first.
         *  if Proxy and Redirect exists, list Redirect second.
         *  if Registrar exists, always list last.

      For example "sip_proxy1", "sip_proxy_registrar1",
      "sip_proxy_redirect5", "sip_proxy_redirect_registrar2", or
      "sip_registrar1".

   o  Note: the value of the network service application index
      (applIndex) may be different from the instance identifier used in
      the system (the applIndex is dynamically created and is the value
      assigned by the SNMP agent at the creation of the table entry,
      whereas the value of the instance identifier to be used in the
      application name is provided as part of the application name
      applName by the system administrator or configuration files of the
      SIP entity).  This note is illustrated in the first example
      provided below.

   Finally, the SNMP agent MAY support any combination of the other
   attributes in applTable.  If supported, the following objects SHOULD
   have values populated as follows:

   o  applVersion: version of the SIP application.

   o  applUptime: the value of applUptime MUST be identical to the value
      of sipCommonCfgServiceStartTime defined in the SIP-COMMON-MIB
      module.

   o  applOperStatus: the value of applOperStatus SHOULD reflect the
      operational status of sipCommonCfgServiceOperStatus, at least by
      means of a mapping.

   o  applLastChange: the value of applLastChange MUST be identical to
      the value of sipCommonCfgServiceLastChange defined in the SIP-
      COMMON module.

   A number of other objects are defined as part of the applTable.  They
   are not included for the sake of brevity and due to the fact that
   they do not enhance the concept being presented.
Top   ToC   RFC4780 - Page 8
   Example 1:

   The tables below illustrate how a system acting as both Proxy and
   Registrar server might be configured to maintain separate SIP-
   COMMON-MIB instances.

   The NETWORK-SERVICES-MIB applTable might be populated as follows:

            +-----------+-------------------+----------------------+
            | applIndex |      applName     |    applDescription   |
            +-----------+-------------------+----------------------+
            |     1     |   "sip_proxy10"   |   "ACME SIP Proxy"   |
            |     2     | "sip_registrar17" | "ACME SIP Registrar" |
            +-----------+-------------------+----------------------+

   The SIP-COMMON-MIB sipCommonCfgTable would have two rows: one for the
   proxy (applIndex=1) and one for the registrar (applIndex=2).  The
   SIP-SERVER-MIB tables would, however, only be populated with one row
   indexed by applIndex=1 and applIndex=2, respectively, if the server
   provides either proxy or registrar.

   The SIP-COMMON-MIB sipCommonCfgTable might be populated as:

   +---------+------------------------+--------------------------+-----+
   |applIndex| sipCommonCfgProtocol   | sipCommonCfgServiceOper  | ... |
   |         | Version                | Status                   |     |
   +---------+------------------------+--------------------------+-----+
   |    1    |        "SIP/2.0"       |           up(1)          |     |
   |    2    |        "SIP/2.0"       |       restarting(4)      |     |
   +---------+------------------------+--------------------------+-----+

   while the sipServerProxyCfgTable in SIP-SERVER-MIB might be populated
   as:

            +-----------+-------------------------------+-----+
            | applIndex | sipServerCfgProxyStatefulness | ... |
            +-----------+-------------------------------+-----+
            |     1     |          stateless(1)         |     |
            +-----------+-------------------------------+-----+
Top   ToC   RFC4780 - Page 9
   and the sipServerRegUserTable in SIP-SERVER-MIB might be populated
   as:

      +-----------+-----------------------+---------------------+-----+
      | applIndex | sipServerRegUserIndex | sipServerRegUserUri | ... |
      +-----------+-----------------------+---------------------+-----+
      |     2     |           1           |   bob@example.com   |     |
      |     2     |           2           |  alice@example.com  |     |
      |     2     |           3           |   jim@example.com   |     |
      |     2     |           4           |   john@example.com  |     |
      +-----------+-----------------------+---------------------+-----+

   Example 2:

   This example illustrates how to represent a system acting as both
   Proxy and Registrar server, where the two entities share a single
   instance of SIP-COMMON-MIB.

   The NETWORK-SERVICES-MIB applTable might be populated as follows:

   +-----------+------------------------+------------------------------+
   | applIndex |        applName        |        applDescription       |
   +-----------+------------------------+------------------------------+
   |     1     | "sip_proxy_registrar1" |      "ACME SIP Proxy and     |
   |           |                        |          Registrar"          |
   +-----------+------------------------+------------------------------+

   The SIP-COMMON-MIB sipCommonCfgTable would have only one row to cover
   both the proxy and the registrar.

   The SIP-COMMON-MIB sipCommonCfgTable might be populated as:

  +----------+---------------------------+-----------------------------+
  |applIndex |sipCommonCfgProtocolVersion|sipCommonCfgServiceOperStatus|
  +----------+---------------------------+-----------------------------+
  |     1    |         "SIP/2.0"         |            up(1)            |
  +----------+---------------------------+-----------------------------+
Top   ToC   RFC4780 - Page 10
   while the sipServerRegUserTable in SIP-SERVER-MIB might be populated
   as:

      +-----------+-----------------------+---------------------+-----+
      | applIndex | sipServerRegUserIndex | sipServerRegUserUri | ... |
      +-----------+-----------------------+---------------------+-----+
      |     2     |           1           |   bob@example.com   |     |
      |     2     |           2           |  alice@example.com  |     |
      |     2     |           3           |  kevin@example.com  |     |
      |     2     |           4           |    jf@example.com   |     |
      +-----------+-----------------------+---------------------+-----+

   The NETWORK-SERVICES-MIB assocTable is not considered a requirement
   for SIP systems.  It is not a mandatory group for compliance with the
   NETWORK-SERVICES-MIB module.

   The relationship between the value of applOperStatus and
   sipCommonCfgServiceOperStatus is as follows:

   +-------------------------------+---------------+-------------------+
   | sipCommonCfgServiceOperStatus |       --      |   applOperStatus  |
   |                               |  corresponds  |                   |
   |                               |     to -->    |                   |
   +-------------------------------+---------------+-------------------+
   |               up              |      -->      |         up        |
   |              down             |      -->      |        down       |
   |           congested           |      -->      |     congested     |
   |           restarting          |      -->      |     restarting    |
   |           quiescing           |      -->      |     quiescing     |
   |            testing            |      -->      |         up        |
   |            unknown            |      -->      | --indeterminate-- |
   +-------------------------------+---------------+-------------------+

   If the sipOperStatus is 'unknown', there is no corresponding value of
   applOperStatus.  Therefore, the last known value of applOperStatus
   SHOULD be maintained until the sipOperStatus transitions to a value
   that can be mapped appropriately.

5.3. IMPORTed MIB Modules and REFERENCE Clauses

The SIP MIB modules defined in this document IMPORT definitions normatively from the following MIB modules, beyond [RFC2578], [RFC2579], and [RFC2580]: INET-ADDRESS-MIB [RFC4001], NETWORK- SERVICES-MIB [RFC2788], SNMP-FRAMEWORK-MIB [RFC3411]. This MIB module also includes REFERENCE clauses that normatively refer to SIP [RFC3261] and INET-ADDRESS-MIB [RFC4001].
Top   ToC   RFC4780 - Page 11
   Finally, this MIB module makes informative references to several RFCs
   in some of the examples described in the DESCRIPTION clauses,
   including Reliability of Provisional Responses in SIP [RFC3262] and
   SIP over SCTP [RFC4168].

6. Accommodating SIP Extension Methods

The core set of SIP methods is defined in RFC 3261 [RFC3261]. Other IETF RFCs define additional methods. In the future, additional methods may be defined. In order to avoid having to update the SIP- COMMON-MIB module to accommodate these extension methods, we use a method identifier name (SipTCMethodName TEXTUAL-CONVENTION) to represent all SIP methods registered with IANA. For example, the sipCommonMethodSupportedTable is the main table for listing all of the SIP methods supported by a system, including the SIP methods defined in RFC 3261 [RFC3261] and other SIP methods registered with IANA. The table is informational in nature and populated by the system. Entries cannot be added or deleted by an SNMP manager. The SIP specification (RFC 3261 [RFC3261], Section 27.4) establishes the sub-registries for SIP Methods and Response Codes under http://www.iana.org/assignments/sip-parameters. This document uses the existing sub-registry for the names of registered SIP methods. For example, in the sipCommonMethodSupportedTable of SIP-COMMON-MIB, the sipCommonMethodSupportedName values can be represented as follows: +------------------------------+ | sipCommonMethodSupportedName | +------------------------------+ | "ACK" | | "BYE" | | "CANCEL" | | "INVITE" | | "OPTIONS" | +------------------------------+
Top   ToC   RFC4780 - Page 12

7. Definitions

7.1. SIP Textual Conventions

SIP-TC-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, mib-2 FROM SNMPv2-SMI -- RFC 2578 TEXTUAL-CONVENTION FROM SNMPv2-TC; -- RFC 2579 sipTC MODULE-IDENTITY LAST-UPDATED "200704200000Z" ORGANIZATION "IETF Session Initiation Protocol Working Group" CONTACT-INFO "SIP WG email: sip@ietf.org Co-editor Kevin Lingle Cisco Systems, Inc. postal: 7025 Kit Creek Road P.O. Box 14987 Research Triangle Park, NC 27709 USA email: klingle@cisco.com phone: +1 919 476 2029 Co-editor Joon Maeng email: jmaeng@austin.rr.com Co-editor Jean-Francois Mule CableLabs postal: 858 Coal Creek Circle Louisville, CO 80027 USA email: jf.mule@cablelabs.com phone: +1 303 661 9100 Co-editor Dave Walker email: drwalker@rogers.com" DESCRIPTION "Session Initiation Protocol (SIP) MIB TEXTUAL-CONVENTION module used by other SIP-related MIB Modules. Copyright (C) The IETF Trust (2007). This version of this MIB module is part of RFC 4780; see the RFC itself for
Top   ToC   RFC4780 - Page 13
        full legal notices."
    REVISION     "200704200000Z"
    DESCRIPTION
       "Initial version of the IETF SIP-TC-MIB module.  This version
        published as part of RFC 4780."
     ::= { mib-2 148 }

--
-- Textual Conventions
--

SipTCTransportProtocol ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION
       "This convention is a bit map.  Each bit represents a transport
        protocol.  If a bit has value 1, then that selected transport
        protocol is in some way dependent on the context of the object
        using this convention.  If a bit has value 0, then that
        transport protocol is not selected.  Combinations of bits can
        be set when multiple transport protocols are selected.

        bit 0: a protocol other than those defined here
        bit 1: User Datagram Protocol
        bit 2: Transmission Control Protocol
        bit 3: Stream Control Transmission Protocol
        bit 4: Transport Layer Security Protocol over TCP
        bit 5: Transport Layer Security Protocol over SCTP
       "
    REFERENCE "RFC 3261, Section 18 and RFC 4168"
    SYNTAX      BITS {
                  other(0),  -- none of the following
                  udp(1),
                  tcp(2),
                  sctp(3),   -- RFC4168
                  tlsTcp(4),
                  tlsSctp(5) -- RFC 4168
                }

SipTCEntityRole ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION
       "This convention defines the role of a SIP entity.  Examples of
        SIP entities are proxies, user agents, redirect servers,
        registrars, or combinations of the above.

        User Agent (UA): A logical entity that can act as both a user
        agent client and user agent server.
Top   ToC   RFC4780 - Page 14
        User Agent Client (UAC): A logical entity that creates a new
        request, and then uses the client transaction state machinery
        to send it.  The role of UAC lasts only for the duration of
        that transaction.  In other words, if a piece of software
        initiates a request, it acts as a UAC for the duration of that
        transaction.  If it receives a request later, it assumes the
        role of a user agent server for the processing of that
        transaction.

        User Agent Server (UAS): A logical entity that generates a
        response to a SIP request.  The response accepts, rejects,
        or redirects the request.  This role lasts only for the
        duration of that transaction.  In other words, if a piece of
        software responds to a request, it acts as a UAS for the
        duration of that transaction.  If it generates a request
        later, it assumes the role of a user agent client for the
        processing of that transaction.

        Proxy, Proxy Server: An intermediary entity that acts as both
        a server and a client for the purpose of making requests on
        behalf of other clients.  A proxy server primarily plays the
        role of routing, which means its job is to ensure that a
        request is sent to another entity 'closer' to the targeted
        user.  Proxies are also useful for enforcing policy.  A proxy
        interprets and, if necessary, rewrites specific parts of a
        request message before forwarding it.

        Redirect Server: A redirect server is a user agent server that
        generates 3xx responses to requests it receives, directing the
        client to contact an alternate set of URIs.

        Registrar: A registrar is a server that accepts REGISTER
        requests and places the information it receives in those
        requests into the location service for the domain it handles."
    REFERENCE
       "RFC 3261, Section 6"
    SYNTAX      BITS {
                  other(0),
                  userAgent(1),
                  proxyServer(2),
                  redirectServer(3),
                  registrarServer(4)
                }

SipTCOptionTagHeaders ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION
       "This convention defines the header fields that use the option
Top   ToC   RFC4780 - Page 15
        tags per Section 19.2 of RFC 3261.  These tags are used in
        Require (Section 20.32), Proxy-Require (Section 20.29),
        Supported (Section 20.37), and Unsupported (Section 20.40)
        header fields."
    REFERENCE
       "RFC 3261, Sections 19.2, 20.32, 20.29, 20.37, and 20.40"
    SYNTAX      BITS {
                  require(0),       -- Require header
                  proxyRequire(1),  -- Proxy-Require header
                  supported(2),     -- Supported header
                  unsupported(3)    -- Unsupported header
                }

SipTCMethodName ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION
       "This TEXTUAL-CONVENTION is a string that uniquely identifies a
        SIP method.  The scope of uniqueness is the context of all
        defined SIP methods.

        Experimental support of extension methods is acceptable and
        expected.  Extension methods are those defined in
        Internet-Draft documents but not yet allocated and
        officially sanctioned by IANA.

        To support experimental extension methods, any object using
        this TEXTUAL-CONVENTION as syntax MAY return/accept a method
        identifier value other than those sanctioned by IANA.  That
        system MUST ensure no collisions with officially assigned
        method names."
    REFERENCE
       "RFC 3261, Section 27.4"
    SYNTAX      OCTET STRING (SIZE (1..100))

END



(page 15 continued on part 2)

Next Section