idnits 2.17.1 draft-schoenw-snmp-tc-ext-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 8 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 102: '... MUST be specified so that ...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (18 November 1998) is 9289 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC2279' on line 73 looks like a reference -- Missing reference section? 'RFC1905' on line 104 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Juergen Schoenwaelder 2 Internet-Draft TU Braunschweig 3 Expires May 1999 18 November 1998 5 Textual Conventions Extension 1 7 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as ``work in progress.'' 21 To view the entire list of current Internet-Drafts, please check the 22 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 24 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 25 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 27 Distribution of this document is unlimited. Please send comments to 28 the SNMP Version 3 Working Group, . 30 Abstract 32 This memo defines new textual conventions that are considered to be 33 generally useful. This memo extends the set of textual conventions 34 defined in RFC 1903, which also defines the language used to define 35 textual conventions. 37 Table of Contents 39 1 Introduction ................................................. 2 40 2 Definitions .................................................. 2 41 3 Acknowledgments .............................................. 5 42 4 Authors' Address ............................................. 5 44 1. Introduction 46 This memo defines new textual conventions that are considered to be 47 generally useful. It extends the set of textual conventions defined 48 in RFC 1903. For more information about textual conventions, please 49 consult RFC 1903. 51 2. Definitions 53 SNMPv2-TC-EXT-01 DEFINITIONS ::= BEGIN 55 IMPORTS 56 MODULE-IDENTITY 57 FROM SNMPv2-SMI 58 TEXTUAL-CONVENTION 59 FROM SNMPv2-TC; 61 -- This module is not valid SMIv2. The author left out all the 62 -- administrative stuff in order to keep it small. 64 InternationalString ::= TEXTUAL-CONVENTION 65 DISPLAY-HINT "255t" 66 STATUS current 67 DESCRIPTION 68 "An octet string containing human-readable information. 70 To facilitate internationalization, this information is 71 represented using the ISO/IEC IS 10646-1 character set, 72 encoded as an octet string using the UTF-8 transformation 73 format described in [RFC2279]. 75 Since additional code points are added by amendments to the 76 10646 standard from time to time, implementations must be 77 prepared to encounter any code point from 0x00000000 to 78 0x7fffffff. Byte sequences that do not correspond to the 79 valid UTF-8 encoding of a code point or are outside this 80 range are prohibited. 82 The use of control codes should be avoided. When it is 83 necessary to represent a newline, the control code sequence 84 CR LF should be used. 86 For code points not directly supported by user interface 87 hardware or software, an alternative means of entry and 88 display, such as hexadecimal, may be provided. 90 For information encoded in 7-bit US-ASCII, the UTF-8 encoding 91 is identical to the US-ASCII encoding. 93 UTF-8 may require multiple bytes to represent a single 94 character / code point; thus the length of this object in 95 octets may be different from the number of characters 96 encoded. Similarly, size constraints refer to the number of 97 encoded octets, not the number of characters represented by 98 an encoding. 100 Note that when this TC is used for an object that is used or 101 envisioned to be used as an index, then a SIZE restriction 102 MUST be specified so that the number of sub-identifiers for 103 any object instance does not exceed the limit of 128, as 104 defined by [RFC1905]. 106 Note that the size of an InternationalString object is 107 measured in octets, not characters." 108 SYNTAX OCTET STRING (SIZE (0..255)) 110 TAddressOrZero ::= TEXTUAL-CONVENTION 111 STATUS current 112 DESCRIPTION 113 "Denotes a transport service address. A zero-length octet 114 string indicates that no transport address is known. 116 A TAddress value is always interpreted within the context of 117 a TDomain value. Thus, each definition of a TDomain value 118 must be accompanied by a definition of a textual convention 119 for use with that TDomain. Some possible textual conventions, 120 such as SnmpUDPAddress for snmpUDPDomain, are defined in the 121 SNMPv2-TM MIB module. Other possible textual conventions are 122 defined in other MIB modules. 124 Note, the definition of this textual convention is identical 125 to the TAddress definition in the SNMPv2-TM MIB module with 126 the only difference that this textual convention allows a 127 zero-length TAddress value." 128 SYNTAX OCTET STRING (SIZE (0..255)) 130 TAddressMask ::= 131 STATUS current 132 DESCRIPTION 133 "Denotes a transport service address mask. 135 A mask value is used to select which bits of a transport 136 address must match bits of the corresponding instance of 137 a TAddress object. The value of an instance of this textual 138 convention must always be an OCTET STRING whose length is 139 either zero or the same as that of the corresponding instance 140 of a TAddress object. 142 The matching algorithm is as follows: 144 Each bit of each octet in the TAddressMask value corresponds 145 to the same bit of the same octet in the TAddress value. For 146 bits that are set in the TAddressMask value (i.e. bits equal 147 to 1), the corresponding bits in the TAddress value must 148 match the bits in a given transport address. If all such bits 149 match, the transport address is matched. Otherwise, the match 150 fails." 151 SYNTAX OCTET STRING (SIZE (1..255)) 153 TAddressMaskOrZero ::= 154 STATUS 155 DESCRIPTION 156 "Denotes a transport service address mask. A zero-length octet 157 string indicates that the match always succeeds. 159 A mask value is used to select which bits of a transport 160 address must match bits of the corresponding instance of 161 a TAddress object. The value of an instance of this textual 162 convention must always be an OCTET STRING whose length is 163 either zero or the same as that of the corresponding instance 164 of a TAddress object. 166 The matching algorithm is as follows: 168 If the value of the TAddressMask is a zero-length OCTET 169 STRING, the mask value is ignored and the match succeeds. 171 Otherwise, each bit of each octet in the TAddressMask value 172 corresponds to the same bit of the same octet in the 173 TAddress value. For bits that are set in the TAddressMask 174 value (i.e. bits equal to 1), the corresponding bits in the 175 TAddress value must match the bits in a given transport 176 address. If all such bits match, the transport address is 177 matched. Otherwise, the match fails." 178 SYNTAX OCTET STRING (SIZE (0..255)) 179 END 181 3. Acknowledgments 183 The definitions in this memo are inspired by definitions found in 184 other RFCs and Internet-Drafts. Most of the text in the descriptions 185 is therefore copied from other sources. Special thanks go to David 186 Levi, Randy Presuhn and Keith McCloghrie for writing the original 187 descriptions. 189 4. Authors' Address 191 Juergen Schoenwaelder Email: schoenw@ibr.cs.tu-bs.de 192 TU Braunschweig Tel: +49 531 391-3283 193 Bueltenweg 74/75 194 38106 Braunschweig 195 Germany