Network Working Group Y. Li, Ed. Internet-Draft Huawei Technologies Intended status: Standards Track May 17, 2007 Expires: November 18, 2007 Datatypes for Netconf Data Models draft-romascanu-netconf-datatypes-02.txt Status of This Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 18, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This memo defines an initial set of reusable NetConf datatypes. Some of them inherit textual conventions of SNMP. Li Expires November 18, 2007 [Page 1] Internet-Draft Datatypes for Netconf Data Models May 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 2. NetConf Core Datatypes . . . . . . . . . . . . . . . . . . . . 3 2.1. Considerations for Reusing SNMP Textual Conventions . . . 4 2.1.1. Boolean . . . . . . . . . . . . . . . . . . . . . . . 4 2.1.2. Enumerated Integer . . . . . . . . . . . . . . . . . . 4 2.1.3. Numeric Integer . . . . . . . . . . . . . . . . . . . 4 2.1.4. Date and Time . . . . . . . . . . . . . . . . . . . . 4 2.1.5. String . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.6. Address . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.7. BITS . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.8. OID . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.9. SNMP-Specific Textual Conventions . . . . . . . . . . 5 2.2. NetConf Datatype definitions . . . . . . . . . . . . . . . 6 3. Security Considerations . . . . . . . . . . . . . . . . . . . 37 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37 6. Normative References . . . . . . . . . . . . . . . . . . . . . 38 Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 39 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 40 Li Expires November 18, 2007 [Page 2] Internet-Draft Datatypes for Netconf Data Models May 2007 1. Introduction NETCONF [RFC4741] configuration protocol defines Extensible Markup Language [ref.XML] based mechanisms to install, manipulate, and delete the configuration of network devices. The NETCONF protocol can be conceptually partitioned into four layers: Layer Example +-------------+ +-----------------------------+ | Content | | Configuration data | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ | Operations | | , | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ | RPC | | , | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ | Application | | BEEP, SSH, SSL, console | | Protocol | | | +-------------+ +-----------------------------+ The framework for Netconf Data Models [NETMOD] provides guidance for the creation of Netconf data model. This document defines an initial set of core datatypes that will be useful in defining the NETCONF content. Figure 1 1.1. 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]. Sections requiring further editing are identified by [todo] markers in the text. Points requiring further WG research and discussion are identified by [discuss] markers in the text. 2. NetConf Core Datatypes The Netconf architecture supports a clear separation between content and protocol. There are major advantages to ensuring that every data model writer do not have to invent new datatypes. Li Expires November 18, 2007 [Page 3] Internet-Draft Datatypes for Netconf Data Models May 2007 SNMP has defined a rich set of textual conventions. Some of them can be reused by NETCONF. 2.1. Considerations for Reusing SNMP Textual Conventions 2.1.1. Boolean There is a TruthValue textual convention in the SNMPv2-TC, which uses an enumerated integer to represent true and false. However, there is a build-in boolean datatype in the XML Schema Datatypes [ref.XMLSchema]. Therefore TruthValue is not needed by NETCONF. [discuss] Is the EnabledStatus (P-BRIDGE-MIB) needed? It likes TruthValue. It uses 1 and 2 to represent enabled and disabled respectively. 2.1.2. Enumerated Integer In an enumerated integer textual conventions, each number has a label, which represents the meaning of the number. For the sake of human readability, the number will be discarded, only the label will be retained. Thus the enumerated string simpleType will replace the enumerated integer. 2.1.3. Numeric Integer A numeric integer often represents a quantity, such as a counter, a gauge; or an identifier, such as an InterfaceIndex. A majority of textual conventions of numeric integer can be directly mapped to build-in integer datatype or derived datatypes from integer. But in some case, an invalid value is used to represent a special meaning. For instance, VlanIdOrAny, 4095 is not a valid VlanId, however it represents any VLAN. For this case, an union of integer and enumerated string will be used. 2.1.4. Date and Time The time-class textual convention usually is defined as a numeric integer in units of 0.01 seconds, sometimes in units of second. Both of them represent a period of time, so the sort of textual conventions should be mapped to build-in duration datatype or derived datatypes from duration. The DateAndTime textual convention and build-in dateTime datatype have the same meaning. So the DateAndTime textual convention is not needed any more. Li Expires November 18, 2007 [Page 4] Internet-Draft Datatypes for Netconf Data Models May 2007 2.1.5. String Apart from binary string, all of human readable strings can be directly mapped to build-in string datatype or derived datatypes from string. [discuss] Can the non-UTF8 string be accepted by an XML file in NETCONF? 2.1.6. Address All kinds of addresses can be represented as a string with a specific pattern. 2.1.7. BITS The BITS is something like the enumerated integer, each bit in a BITS string has a name, which represents the meaning of the bit. Multiple bits can be set simultaneously. It is equivalent to a multi-choice enumerated string. So it is represented as a list of enumerated string. 2.1.8. OID The OID has two functions in the SNMP world: o It serves as a pointer, which points to a certain managed object or entry. For instance, RowPointer. In this case, the OID should be replaced by an XPath expression. o It serves as an identifier, which often denotes a type and allows users to define new value for the type. For instance, TransportDomain. In this case, the OID should be replaced by an URI. 2.1.9. SNMP-Specific Textual Conventions 2.1.9.1. TestAndIncr An object of TestAndIncr is a spinlock. Although NETCONF has defined and operations to avoid concurrent access from multiple sessions, The TestAndIncr is still required, because it is able to implement fine-grained lock control. Furthermore, the NETCONF data model may be accessed by multiple network management protocols that have no lock mechanism, such as SNMP and CLI. If TestAndIncr is retained, access collisions between these protocols can be avoided. Li Expires November 18, 2007 [Page 5] Internet-Draft Datatypes for Netconf Data Models May 2007 2.1.9.2. RowStatus and EntryStatus A RowStatus or EntryStatus object is treated like a verb in SNMP. They are used to create or delete a specific table entry instance. They are able to temporarily make a table entry instance invalid instead of deleting it, so it may be needed. 2.1.9.3. StorageType A StorageType object indicates the store medium and read/write status of a conceptual row. It allows a conceptual row be stored permanently. So it is useful for NETCONF, it should be retained. 2.2. NetConf Datatype definitions The following are an initial set of reusable datatypes. The semantics of datatypes in the following XSD are quoted from the following documents: +---------------------------------------------+---------------------+ | Datatypes | Document | +---------------------------------------------+---------------------+ | DisplayString PhysAddress MacAddress | RFC 2579 [RFC2579] | | TestAndIncr RowStatus TimeStamp | | | TimeInterval StorageType | | | SnmpAdminString | RFC 3411 [RFC3411] | | Utf8String LongUtf8String | RFC 2287 [RFC2287] | | InetAddressType InetAddress | RFC 4001 [RFC4001] | | InetAddressPrefixLength InetPortNumber | | | InetAutonomousSystemNumber InetScopeType | | | InetZoneIndex InetVersion | | | TransportAddressType TransportAddress | RFC 3419 [RFC3419] | | ZeroBasedCounter32 | RFC 4502 [RFC4502] | | ZeroBasedCounter64 CounterBasedGauge64 | RFC 2856 [RFC2856] | | InterfaceIndex InterfaceIndexOrZero | RFC 2863 [RFC2863] | | PhysicalIndex PhysicalIndexOrZero | RFC 4133 [RFC4133] | | PerfCurrentCount PerfIntervalCount | RFC 3593 [RFC3593] | | PerfTotalCount | | | HCPerfValidIntervals HCPerfInvalidIntervals | RFC 3705 [RFC3705] | | HCPerfTimeElapsed HCPerfIntervalThreshold | | | HCPerfCurrentCount HCPerfIntervalCount | | | HCPerfTotalCount | | | ItuPerceivedSeverity ItuTrendIndication | RFC 3877 [RFC3877] | | EntityAdminState EntityOperState | RFC 4268 [RFC4268] | | EntityUsageState EntityAlarmStatus | | | EntityStandbyStatus | | | VlanId VlanIdOrAny VlanIdOrNone | RFC 4363 [RFC4363] | +---------------------------------------------+---------------------+ Li Expires November 18, 2007 [Page 6] Internet-Draft Datatypes for Netconf Data Models May 2007 The descriptions reference 'UTF-8, a transformation format of ISO 10646' [RFC3629] NetConf Datatypes Schema Represents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. Li Expires November 18, 2007 [Page 7] Internet-Draft Datatypes for Netconf Data Models May 2007 Represents integer-valued information used for atomic operations. When the management protocol is used to specify that an object instance having this syntax is to be modified, the new value supplied via the management protocol must precisely match the value presently held by the instance. If not, the management protocol set operation fails with an error of `inconsistentValue'. Otherwise, if the current value is the maximum value of 2^31-1 (2147483647 decimal), then the value held by the instance is wrapped to zero; otherwise, the value held by the instance is incremented by one. (Note that regardless of whether the management protocol set operation succeeds, the variable- binding in the request and response PDUs are identical.) The value of the ACCESS clause for objects having this syntax is either `read-write' or `read-create'. When an instance of a columnar object having this syntax is created, any value may be supplied via the management protocol. When the network management portion of the system is re- initialized, the value of every object instance having this syntax must either be incremented from its value prior to the re-initialization, or (if the value prior to the re- initialization is unknown) be set to a pseudo-randomly generated value. Represents a pointer to an element instance. The value is an absolut XPath expression that points to the instance. [discuss] Is it allowed that the XPath expression points to multiple instances of an element? [todo] The pattern of the XPath expression needs to be designed. Reference to the definition of the RowStatus textual convention in RFC 2579. The value of the sysUpTime object at which a specific occurrence happened. The sysUpTime object is that the time (in hundredths of a second) since the network management portion of the system was last re-initialized. The specific occurrence must be defined in the description of any object defined using this type. If sysUpTime is reset to zero as a result of a re- initialization of the network management (sub)system, then the values of all TimeStamp objects are also reset. However, after approximately 497 days without a re- initialization, the sysUpTime object will reach 2^^32-1 and then increment around to zero; in this case, existing values of TimeStamp objects do not change. This can lead to ambiguities in the value of TimeStamp objects. [discuss] Is the maximum of 42949672.96 seconds needed? The TimeTicks datatype is essentially an integer in SNMP, thus it has the maximum. Li Expires November 18, 2007 [Page 9] Internet-Draft Datatypes for Netconf Data Models May 2007 A period of time, measured in units of 0.01 seconds. [discuss] Is the maximum of 21474836.47 seconds needed? The TimeTicks datatype is essentially an integer in SNMP, thus it has the maximum. Describes the memory realization of a conceptual row. A row which is volatile is lost upon reboot. A row which is either nonVolatile, permanent or readOnly, is backed up by stable storage. A row which is permanent can be changed but not deleted. A row which is readOnly cannot be changed nor deleted. If the value of an object with this syntax is either permanent or readOnly, it cannot be written. Conversely, if the value is either other, volatile or nonVolatile, it cannot be modified to be permanent or readOnly. Every usage of this datatype is required to specify the columnar objects which a permanent row must at a minimum allow to be writable. Li Expires November 18, 2007 [Page 10] Internet-Draft Datatypes for Netconf Data Models May 2007 An octet string containing administrative information, preferably in human-readable form. To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in RFC3629. Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited. The use of control codes should be avoided. When it is necessary to represent a newline, the control code sequence CR LF should be used. The use of leading or trailing white space should be avoided. For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided. For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding. UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding. Note that the size of an SnmpAdminString object is measured in octets, not characters. Li Expires November 18, 2007 [Page 11] Internet-Draft Datatypes for Netconf Data Models May 2007 To facilitate internationalization, this datatype represents information taken from the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 character encoding scheme described in RFC 2044. For strings in 7-bit US-ASCII, there is no impact since the UTF-8 representation is identical to the US-ASCII encoding. To facilitate internationalization, this datatype represents information taken from the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 character encoding scheme described in RFC 2044. For strings in 7-bit US-ASCII, there is no impact since the UTF-8 representation is identical to the US-ASCII encoding. This datatype describes an object which counts events with the Li Expires November 18, 2007 [Page 12] Internet-Draft Datatypes for Netconf Data Models May 2007 following semantics: objects of this type will be set to zero(0) on creation and will thereafter count appropriate events, wrapping back to zero(0) when the value 2^32 is reached. Provided that an application discovers the new object within the minimum time to wrap it can use the initial value as a delta since it last polled the table of which this object is part. It is important for a management station to be aware of this minimum time and the actual time between polls, and to discard data if the actual time is too long or there is no defined minimum time. Typically this datatype is used in tables where the INDEX space is constantly changing and/or the TimeFilter mechanism is in use. This datatype describes an object which counts events with the following semantics: objects of this type will be set to zero(0) on creation and will thereafter count appropriate events, wrapping back to zero(0) when the value 2^64 is reached. Provided that an application discovers the new object within the minimum time to wrap it can use the initial value as a delta since it last polled the table of which this object is part. It is important for a management station to be aware of this minimum time and the actual time between polls, and to discard data if the actual time is too long or there is no defined minimum time. Typically this datatype is used in tables where the INDEX space is constantly changing and/or the TimeFilter mechanism is in use. Note that this datatype does not retain all the semantics of the Counter64 base type. Specifically, a Counter64 has an arbitrary initial value, but objects defined with this datatype are required to start at the value zero. This behavior is not likely to have any adverse effects on management applications which are expecting Counter64 semantics. Li Expires November 18, 2007 [Page 13] Internet-Draft Datatypes for Netconf Data Models May 2007 This datatype represents a non-negative integer, which may increase or decrease, but shall never exceed a maximum value, nor fall below a minimum value. The maximum value can not be greater than 2^64-1 (18446744073709551615 decimal), and the minimum value can not be smaller than 0. The value of a CounterBasedGauge64 has its maximum value whenever the information being modeled is greater than or equal to its maximum value, and has its minimum value whenever the information being modeled is smaller than or equal to its minimum value. If the information being modeled subsequently decreases below (increases above) the maximum (minimum) value, the CounterBasedGauge64 also decreases (increases). Note that this datatype is not strictly supported in SMIv2, because the 'always increasing' and 'counter wrap' semantics associated with the Counter64 base type are not preserved. It is possible that management applications which rely solely upon the (Counter64) ASN.1 tag to determine object semantics will mistakenly operate upon objects of this type as they would for Counter64 objects. A unique value, greater than zero, for each interface or interface sub-layer in the managed system. It is recommended that values are assigned contiguously starting from 1. The value for each interface sub-layer must remain constant at least from one re-initialization of the entity's network management system to the next re-initialization. Li Expires November 18, 2007 [Page 14] Internet-Draft Datatypes for Netconf Data Models May 2007 Object-specific, it be defined as part of the description of any object that uses this syntax. This datatype is an extension of the InterfaceIndex datatype. The latter defines a greater than zero value used to identify an interface or interface sub-layer in the managed system. This extension permits the additional value of zero. the value zero is object-specific and must therefore be defined as part of the description of any object which uses this syntax. Examples of the usage of zero might include situations where interface was unknown, or when none or all interfaces need to be referenced. An arbitrary value that uniquely identifies the physical entity. The value should be a small, positive integer. Index values for different physical entities are not necessarily contiguous. Li Expires November 18, 2007 [Page 15] Internet-Draft Datatypes for Netconf Data Models May 2007 This datatype is an extension of the PhysicalIndex datatype, which defines a greater than zero value used to identify a physical entity. This extension permits the additional value of zero. The semantics of the value zero are object-specific and must, therefore, be defined as part of the description of any object that uses this syntax. Examples of the usage of this extension are situations where none or all physical entities need to be referenced." Represents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. A value that represents a type of Internet address. unknown An unknown address type. This value MUST be used if the value of the corresponding InetAddress object is a zero-length string. It may also be used to indicate an IP address that is not in one of the formats defined below. ipv4 An IPv4 address as defined by the InetAddressIPv4 datatype. ipv6 An IPv6 address as defined by the Li Expires November 18, 2007 [Page 16] Internet-Draft Datatypes for Netconf Data Models May 2007 InetAddressIPv6 datatype. ipv4z A non-global IPv4 address including a zone index as defined by the InetAddressIPv4z datatype. ipv6z A non-global IPv6 address including a zone index as defined by the InetAddressIPv6z datatype. dns A DNS domain name as defined by the InetAddressDNS datatype. Each definition of a concrete InetAddressType value must be accompanied by a definition of a datatype for use with that InetAddressType. To support future extensions, the InetAddressType datatype SHOULD NOT be sub-typed in object type definitions. It MAY be sub-typed in compliance statements in order to require only a subset of these address types for a compliant implementation. Implementations must ensure that InetAddressType objects and any dependent objects (e.g., InetAddress objects) are consistent. In particular, InetAddressType/InetAddress pairs must be changed together if the address type changes (e.g., from ipv6 to ipv4). Denotes a generic Internet address. An InetAddress value is always interpreted within the context of an InetAddressType value. Every usage of the InetAddress datatype is required to specify the InetAddressType Li Expires November 18, 2007 [Page 17] Internet-Draft Datatypes for Netconf Data Models May 2007 object that provides the context. It is suggested that the InetAddressType object be logically registered before the object(s) that use the InetAddress datatype, if they appear in the same logical row. The value of an InetAddress object must always be consistent with the value of the associated InetAddressType object. Attempts to set an InetAddress object to a value inconsistent with the associated InetAddressType must fail. Represents an IPv4 network address. This datatype SHOULD NOT be used directly in object definitions, as it restricts addresses to a specific format. However, if it is used, it MAY be used either on its own or in conjunction with InetAddressType, as a pair." A zone index identifies an instance of a zone of a specific scope. The zone index MUST disambiguate identical address values. For link-local addresses, the zone index will typically be the interface index (ifIndex as defined in the IF-MIB) of the interface on which the address is configured. Li Expires November 18, 2007 [Page 18] Internet-Draft Datatypes for Netconf Data Models May 2007 The zone index may contain the special value 0, which refers to the default zone. The default zone may be used in cases where the valid zone index is not known (e.g., when a management application has to write a link-local IPv6 address without knowing the interface index value). The default zone SHOULD NOT be used as an easy way out in cases where the zone index for a non-global IPv6 address is known. Represents a non-global IPv4 network address, together with its zone index. The corresponding InetAddressType value is 'ipv4z'. The zone index is used to disambiguate identical address values on nodes that have interfaces attached to different zones of the same scope. The zone index may contain the special value 0, which refers to the default zone for each scope. This datatype SHOULD NOT be used directly in object definitions, as it restricts addresses to a specific format. However, if it is used, it MAY be used either on its own or in conjunction with InetAddressType, as a pair. Li Expires November 18, 2007 [Page 19] Internet-Draft Datatypes for Netconf Data Models May 2007 Represents an IPv6 network address. The corresponding InetAddressType value is 'ipv6'. This datatype SHOULD NOT be used directly in object definitions, as it restricts addresses to a specific format. However, if it is used, it MAY be used either on its own or in conjunction with InetAddressType, as a pair. Represents a non-global IPv6 network address, together with its zone index. The corresponding InetAddressType value is 'ipv6z'. The zone index is used to disambiguate identical address values on nodes that have interfaces Li Expires November 18, 2007 [Page 20] Internet-Draft Datatypes for Netconf Data Models May 2007 attached to different zones of the same scope. The zone index may contain the special value 0, which refers to the default zone for each scope. This datatype SHOULD NOT be used directly in object definitions, as it restricts addresses to a specific format. However, if it is used, it MAY be used either on its own or in conjunction with InetAddressType, as a pair. Represents a DNS domain name. The name SHOULD be fully qualified whenever possible. The corresponding InetAddressType is dns. The DESCRIPTION clause of InetAddress objects that may have InetAddressDNS values MUST fully describe how (and when) these names are to be resolved to IP addresses. The resolution of an InetAddressDNS value may require to query multiple DNS records (e.g., A for IPv4 and AAAA for IPv6). The order of the resolution process and which DNS record takes precedence depends on the configuration of the resolver. This datatype SHOULD NOT be used directly in object definitions, as it restricts addresses to a specific format. However, if it is used, it MAY be used either on its own or in conjunction with InetAddressType, as a pair. Li Expires November 18, 2007 [Page 21] Internet-Draft Datatypes for Netconf Data Models May 2007 Denotes the length of a generic Internet network address prefix. A value of n corresponds to an IP address mask that has n contiguous 1-bits from the most significant bit (MSB), with all other bits set to 0. An InetAddressPrefixLength value is always interpreted within the context of an InetAddressType value. Every usage of the InetAddressPrefixLength datatype is required to specify the InetAddressType object that provides the context. It is suggested that the InetAddressType object be logically registered before the object(s) that use the InetAddressPrefixLength datatype, if they appear in the same logical row. InetAddressPrefixLength values larger than the maximum length of an IP address for a specific InetAddressType are treated as the maximum significant value applicable for the InetAddressType. The maximum significant value is 32 for the InetAddressType 'ipv4' and 'ipv4z' and 128 for the InetAddressType 'ipv6' and 'ipv6z'. The maximum significant value for the InetAddressType 'dns' is 0. The value zero is object-specific and must be defined as part of the description of any object that uses this syntax. Examples of the usage of zero might include situations where the Internet network address prefix is unknown or does not apply. The upper bound of the prefix length has been chosen to be consistent with the maximum size of an InetAddress. Represents a 16 bit port number of an Internet transport layer protocol. Port numbers are assigned by IANA. A current list of all assignments is available from <http://www.iana.org/>. Li Expires November 18, 2007 [Page 22] Internet-Draft Datatypes for Netconf Data Models May 2007 The value zero is object-specific and must be defined as part of the description of any object that uses this syntax. Examples of the usage of zero might include situations where a port number is unknown, or when the value zero is used as a wildcard in a filter. Represents an autonomous system number that identifies an Autonomous System (AS). An AS is a set of routers under a single technical administration, using an interior gateway protocol and common metrics to route packets within the AS, and using an exterior gateway protocol to route packets to other ASes'. IANA maintains the AS number space and has delegated large parts to the regional registries. Autonomous system numbers are currently limited to 16 bits (0..65535). There is, however, work in progress to enlarge the autonomous system number space to 32 bits. Therefore, this datatype uses an unsignedInt value without a range restriction in order to support a larger autonomous system number space. Represents a scope type. This datatype can be used in cases where a MIB has to represent different scope types and there is no context information, such as an InetAddress object, that implicitly defines the scope type. Note that not all possible values have been assigned yet, but they may be assigned in future revisions of this specification. Li Expires November 18, 2007 [Page 23] Internet-Draft Datatypes for Netconf Data Models May 2007 Applications should therefore be able to deal with values not yet assigned. A value representing a version of the IP protocol. unknown An unknown or unspecified version of the IP protocol. ipv4 The IPv4 protocol as defined in RFC 791 (STD 5). ipv6 The IPv6 protocol as defined in RFC 2460. Note that this datatype SHOULD NOT be used to distinguish different address types associated with IP protocols. The InetAddressType has been designed for this purpose. An URI that represents a transport domain. Li Expires November 18, 2007 [Page 24] Internet-Draft Datatypes for Netconf Data Models May 2007 A value that represents a transport domain. The enumerated values have the following meaning: unknown unknown transport address type udpIpv4 transportDomainUdpIpv4 udpIpv6 transportDomainUdpIpv6 udpIpv4z transportDomainUdpIpv4z udpIpv6z transportDomainUdpIpv6z tcpIpv4 transportDomainTcpIpv4 tcpIpv6 transportDomainTcpIpv6 tcpIpv4z transportDomainTcpIpv4z tcpIpv6z transportDomainTcpIpv6z sctpIpv4 transportDomainSctpIpv4 sctpIpv6 transportDomainSctpIpv6 sctpIpv4z transportDomainSctpIpv4z sctpIpv6z transportDomainSctpIpv6z local transportDomainLocal udpDns transportDomainUdpDns tcpDns transportDomainTcpDns sctpDns transportDomainSctpDns This datatype can be used to represent transport domains in situations where a syntax of TransportDomain is unwieldy (for example, when used as an index). The usage of this textual convention implies that additional transport domains can only be supported by updating this MIB module. This extensibility restriction does not apply for the TransportDomain datatype which allows data model authors to define additional transport domains independently in other data model modules. Li Expires November 18, 2007 [Page 25] Internet-Draft Datatypes for Netconf Data Models May 2007 Denotes a generic transport address. A TransportAddress value is always interpreted within the context of a TransportAddressType or TransportDomain value. Every usage of the TransportAddress datatype MUST specify the TransportAddressType or TransportDomain object which provides the context. Furthermore, data model authors SHOULD define a separate TransportAddressType or TransportDomain object for each TransportAddress object. It is suggested that the TransportAddressType or TransportDomain is logically registered before the object(s) which use the TransportAddress datatype if they appear in the same logical row. The value of a TransportAddress object must always be consistent with the value of the associated TransportAddressType or TransportDomain object. Attempts to set a TransportAddress object to a value which is inconsistent with the associated TransportAddressType or TransportDomain must fail with an error. MD5 Message Digest Li Expires November 18, 2007 [Page 26] Internet-Draft Datatypes for Netconf Data Models May 2007 ITU-T E.164 Number E.164 Subscriber Number A counter associated with a performance measurement in a current 15 minute measurement interval. The value of this counter starts from zero and is increased when associated events occur, until the end of the 15 minute interval. At that time the value of the counter is stored in the first 15 minute history interval, and the CurrentCount is restarted at zero. In the case where the agent has no valid data available for the current interval the corresponding object instance is not available and upon a retrieval request a corresponding error message shall be returned to indicate that this instance does not exist. Li Expires November 18, 2007 [Page 27] Internet-Draft Datatypes for Netconf Data Models May 2007 A counter associated with a performance measurement in a previous 15 minute measurement interval. In the case where the agent has no valid data available for a particular interval the corresponding object instance is not available and upon a retrieval request a corresponding error message shall be returned to indicate that this instance does not exist. In a system supporting a history of n intervals with IntervalCount(1) and IntervalCount(n) the most and least recent intervals respectively, the following applies at the end of a 15 minute interval: - discard the value of IntervalCount(n) - the value of IntervalCount(i) becomes that of IntervalCount(i-1) for n >= i > 1 - the value of IntervalCount(1) becomes that of CurrentCount - the TotalCount, if supported, is adjusted. A counter associated with a performance measurements aggregating the previous valid 15 minute measurement intervals. (Intervals for which no valid data was available are not counted) Li Expires November 18, 2007 [Page 28] Internet-Draft Datatypes for Netconf Data Models May 2007 The number of near end intervals for which data was collected. The value of an object with an HCPerfValidIntervals syntax will be 96 unless the measurement was (re-)started within the last 1440 minutes, in which case the value will be the number of complete 15 minute intervals for which the agent has at least some data. In certain cases (e.g., in the case where the agent is a proxy) it is possible that some intervals are unavailable. In this case, this interval is the maximum interval number for which data is available. The number of near end intervals for which no data is available. The value of an object with an HCPerfInvalidIntervals syntax will typically be zero except in cases where the data for some intervals are not available (e.g., in proxy situations). The number of seconds that have elapsed since the beginning of the current measurement period. If, for some reason, such as an adjustment in the system's time-of-day clock or the addition of a leap second, the duration of the current interval exceeds the maximum value, the agent will return the maximum value. Li Expires November 18, 2007 [Page 29] Internet-Draft Datatypes for Netconf Data Models May 2007 For 15 minute intervals, the range is limited to (0..899). For 24 hour intervals, the range is limited to (0..86399). This convention defines a range of values that may be set in a fault threshold alarm control. As the number of seconds in a 15-minute interval numbers at most 900, objects of this type may have a range of 0...900, where the value of 0 disables the alarm. A gauge associated with a performance measurement in a current 15 minute measurement interval. The value of an object with an HCPerfCurrentCount syntax starts from zero and is increased when associated events occur, until the end of the 15 minute interval. At that time the value of the gauge is stored in the first 15 minute history interval, and the gauge is restarted at zero. In the case where the agent has no valid data available for the current interval, the corresponding object instance is not available and upon a retrieval request a corresponding error message shall be returned to indicate that this instance does not exist. This count represents a non-negative integer, which may increase or decrease, but shall never exceed 2^64-1 (18446744073709551615 decimal), nor fall below 0. The value of an object with HCPerfCurrentCount syntax assumes its maximum value whenever the underlying count exceeds 2^64-1. If the underlying count subsequently Li Expires November 18, 2007 [Page 30] Internet-Draft Datatypes for Netconf Data Models May 2007 decreases below 2^64-1 (due, e.g., to a retroactive adjustment as a result of entering or exiting unavailable time), then the object's value also decreases. A gauge associated with a performance measurement in a previous 15 minute measurement interval. In the case where the agent has no valid data available for a particular interval, the corresponding object instance is not available and upon a retrieval request a corresponding error message shall be returned to indicate that this instance does not exist. Let X be an object with HCPerfIntervalCount syntax. Let Y be an object with HCPerfCurrentCount syntax. Let Z be an object with HCPerfTotalCount syntax. Then, in a system supporting a history of n intervals with X(1) and X(n) the most and least recent intervals respectively, the following applies at the end of a 15 minute interval: - discard the value of X(n) - the value of X(i) becomes that of X(i-1) for n >= i > 1 - the value of X(1) becomes that of Y. - the value of Z, if supported, is adjusted. This count represents a non-negative integer, which may increase or decrease, but shall never exceed 2^64-1 (18446744073709551615 decimal), nor fall below 0. The value of an object with HCPerfIntervalCount syntax assumes its maximum value whenever the underlying count exceeds 2^64-1. If the underlying count subsequently decreases below 2^64-1 (due, e.g., to a retroactive adjustment as a result of entering or exiting unavailable time), then the value of the object also decreases. Li Expires November 18, 2007 [Page 31] Internet-Draft Datatypes for Netconf Data Models May 2007 A gauge representing the aggregate of previous valid 15 minute measurement intervals. Intervals for which no valid data was available are not counted. This count represents a non-negative integer, which may increase or decrease, but shall never exceed 2^64-1 (18446744073709551615 decimal), nor fall below 0. The value of an object with HCPerfTotalCount syntax assumes its maximum value whenever the underlying count exceeds 2^64-1. If the underlying count subsequently decreases below 2^64-1 (due, e.g., to a retroactive adjustment as a result of entering or exiting unavailable time), then the object's value also decreases. ITU perceived severity values. ITU trend indication values for alarms. Li Expires November 18, 2007 [Page 32] Internet-Draft Datatypes for Netconf Data Models May 2007 Represents the various possible administrative states. A value of 'locked' means the resource is administratively prohibited from use. A value of 'shuttingDown' means that usage is administratively limited to current instances of use. A value of 'unlocked' means the resource is not administratively prohibited from use. A value of 'unknown' means that this resource is unable to report administrative state. Represents the possible values of operational states. A value of 'disabled' means the resource is totally inoperable. A value of 'enabled' means the resource is partially or fully operable. A value of 'testing' means the resource is currently being tested and cannot therefore report whether it is operational or not. A value of 'unknown' means that this resource is unable to report operational state. Li Expires November 18, 2007 [Page 33] Internet-Draft Datatypes for Netconf Data Models May 2007 Represents the possible values of usage states. A value of 'idle' means the resource is servicing no users. A value of 'active' means the resource is currently in use and it has sufficient spare capacity to provide for additional users. A value of 'busy' means the resource is currently in use, but it currently has no spare capacity to provide for additional users. A value of 'unknown' means that this resource is unable to report usage state. Represents the possible values of alarm status. An Alarm , as defined in RFC3877, is a persistent indication of an error or warning condition. When no bits of this attribute are set, then no active alarms are known against this entity and it is not under repair. When the 'value of underRepair' is set, the resource is currently being repaired, which, depending on the implementation, may make the other values in this bit string not meaningful. When the value of 'critical' is set, one or more critical alarms are active against the resource. When the value of 'major' is set, one or more major alarms are active against the resource. When the value of 'minor' is set, one or more minor alarms are active against the resource. When the value of 'warning' is set, one or more warning alarms are active against the resource. When the value of 'indeterminate' is set, one or more alarms of whose perceived severity cannot be determined are active against this resource. Li Expires November 18, 2007 [Page 34] Internet-Draft Datatypes for Netconf Data Models May 2007 A value of 'unknown' means that this resource is unable to report alarm state. Represents the possible values of standby status. A value of 'hotStandby' means the resource is not providing service, but it will be immediately able to take over the role of the resource to be backed up, without the need for initialization activity, and will contain the same information as the resource to be backed up. A value of 'coldStandy' means that the resource is to back up another resource, but will not be immediately able to take over the role of a resource to be backed up, and will require some initialization activity. A value of 'providingService' means the resource is providing service. A value of 'unknown' means that this resource is unable to report standby state. Li Expires November 18, 2007 [Page 35] Internet-Draft Datatypes for Netconf Data Models May 2007 The VLAN-ID that uniquely identifies a VLAN. This is the 12-bit VLAN-ID used in the VLAN Tag header. Any VLAN. The VLAN-ID that uniquely identifies a specific VLAN, or any VLAN. The value of 'any' is used to indicate a wildcard, i.e., any VLAN. This can be used in any situation where an object or table entry must refer either to a specific VLAN or to any VLAN. Note that a managed object that is defined using this datatype should clarify the meaning of 'any VLAN'. No VLAN. Li Expires November 18, 2007 [Page 36] Internet-Draft Datatypes for Netconf Data Models May 2007 The VLAN-ID that uniquely identifies a specific VLAN, or no VLAN. The value of 'none' is used to indicate that no VLAN-ID is present or used. This can be used in any situation where an object or a table entry must refer either to a specific VLAN, or to no VLAN. Note that a managed object that is defined using this datatype should clarify the meaning of 'no VLAN'. 3. Security Considerations To be determined once specific aspects of this solution are better understood. 4. IANA Considerations TBD. 5. Acknowledgements Thanks to Dan Romascanu, Subrata Mazumdar and Sandeep Adwankar for submitting the first two revisions of this document. This document is a result of discussions at IETF 59 and 60, as well as on the mailing list by the following people: Sharon Chisholm, David Harrington, Ray Atarashi, Yoshifumi Atarashi, Bert Wijnen, Andy Bierman, Randy Presuhn, Chris Lonvick, Eliot Lear, Avri Doria, Juergen Schoenwaelder, Rob Ennes, Faye Ly and Andre Westerinen. Li Expires November 18, 2007 [Page 37] Internet-Draft Datatypes for Netconf Data Models May 2007 6. Normative References [NETMOD] Chisholm, S. and S. Adwankar, "Framework for Netconf Data Models", ID draft-chisholm-netconf-model-06, June 2005. [RFC2119] Bradner, s., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2287] Krupczak, C. and J. Saperia, "Definitions of System- Level Managed Objects for Applications", RFC 2287, February 1998. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2856] Bierman, A., McCloghrie, K., and R. Presuhn, "Textual Conventions for Additional High Capacity Data Types", RFC 2856, June 2000. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3411] Wijnen, B., Harrington, D., and R. Presuhn, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3419] Daniele, M. and J. Schoenwaelder, "Textual Conventions for Transport Addresses", RFC 3419, December 2002. [RFC3593] Tesink, K., "Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals", RFC 3593, September 2003. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [RFC3705] Ray, B. and R. Abbi, "High Capacity Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals", RFC 3705, February 2004. [RFC3877] Chisholm, S. and D. Romascanu, "Alarm Management Information Base (MIB)", RFC 3877, September 2004. Li Expires November 18, 2007 [Page 38] Internet-Draft Datatypes for Netconf Data Models May 2007 [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. [RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version 3)", RFC 4133, August 2005. [RFC4268] Chisholm, S. and D. Perkins, "Entity State MIB", RFC 4268, November 2005. [RFC4363] Levi, D., Harrington, D., Ngai, V., Bell, L., Smith, A., Langille, P., Rijhsinghani, A., and K. McCloghrie, "Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering, and Virtual LAN Extensions", RFC 4363, January 2006. [RFC4502] Waldbusser, S., "Remote Network Monitoring Management Information Base Version 2 using SMIv2", RFC 4502, May 2006. [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006. [ref.XML] World Wide Web Consortium, "Extensible Markup Language (XML) 1.0", W3C XML, February 1998, . [ref.XMLSchema] World Wide Web Consortium, "XML Schema Part 2: Datatypes Second Edition", W3C XML Schema, October 2004, . Appendix A. Open Issues o Is the EnabledStatus (P-BRIDGE-MIB) needed? It likes TruthValue. It uses 1 and 2 to represent enabled and disabled respectively. o Can the non-UTF8 string be accepted by an XML file in NETCONF? o Is it allowed that the XPath expression points to multiple instances of an element? o Is the maximum of 42949672.96 seconds needed? The TimeTicks datatype is essentially an integer in SNMP, thus it has the maximum. o Is the maximum of 21474836.47 seconds needed? The TimeTicks datatype is essentially an integer in SNMP, thus it has the maximum. Li Expires November 18, 2007 [Page 39] Internet-Draft Datatypes for Netconf Data Models May 2007 Appendix B. Change Log Changes from -01- to -02- o Updated references to NETCONF RFCs o Added analysis of base SMI types versus base XML types o Copied DESCRIPTION text from TCs to improve ease of use o Analyzed and translated common TCs from OPS web page o Expanded datatypes to support reading MIB objects with TC syntax via NETCONF o Moved original author names to Acknowledgements, in keepng with http://www.rfc-editor.org/policy.html#policy.auth2, and by agreement with original authors. Author's Address Yan Li (editor) Huawei Technologies No.3 Xinxi Road, Shangdi Information Industry Base Beijing, HaiDian District 100085 P.R.China Phone: +86 10 8288 2008 EMail: liyan_77@huawei.com Li Expires November 18, 2007 [Page 40] Internet-Draft Datatypes for Netconf Data Models May 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Li Expires November 18, 2007 [Page 41]