idnits 2.17.1 draft-tesink-urn-clei-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 319. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 296. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 303. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 309. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 325), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 39. ** Found boilerplate matching RFC 3979, Section 5, paragraph 1 (on line 296), which is fine, but *also* found old RFC 2026, Section 10.4A text on line 237. ** Found boilerplate matching RFC 3979, Section 5, paragraph 3 (on line 309), which is fine, but *also* found old RFC 2026, Section 10.4B text on line 243. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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? == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC3406]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == In addition to RFC 3979, Section 5, paragraph 1 boilerplate, a section with a similar start was also found: The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. == In addition to RFC 3979, Section 5, paragraph 3 boilerplate, a section with a similar start was also found: The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. The document has an RFC 3978 Section 5.2(a) Derivative Works Limitation clause. == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (December 31, 2004) is 7055 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: '213a' is mentioned on line 203, but not defined ** Obsolete normative reference: RFC 3406 (Obsoleted by RFC 8141) -- Possible downref: Non-RFC (?) normative reference: ref. 'GR485' Summary: 11 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Kaj Tesink 3 Robert H. Fox 4 Telcordia Technologies 5 December 31, 2004 7 A Uniform Resource Name (URN) Namespace for the CLEI Code 8 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet- Drafts as reference 25 material or to cite them other than as "work in progress". 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This document may not be modified, and derivative works of it may not 34 be created, except to publish it as an RFC and to translate it into 35 languages other than English. 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). All Rights Reserved. 41 Abstract 43 This document describes a Uniform Resource Name (URN) namespace 44 [RFC3406] that is managed by Telcordia Technologies, Inc., as the 45 maintenance agent for ANSI T1.213 [T1.213], for the assignment of the 46 CLEI Code, for usage within messages standardized by ANSI. The CLEI 47 code is a globally unique, ten-character alphanumeric intelligent 48 code assigned by Telcordia Technologies at the request of equipment 49 suppliers. The CLEI code identifies communications equipment by 50 specifying product type and features. There is a one-to-one 51 relationship between a CLEI Code and supplier�s Product ID 52 (Manufacturer's name, part number along with it's version number). 54 Table of Contents 56 1 Introduction .............................................. 3 57 2 Specification Template .................................... 3 58 3 Examples .................................................. 5 59 4 Namespace and Community Considerations .................... 5 60 5 Security Considerations ................................... 6 61 6 IANA Considerations ....................................... 6 62 7 Intellectual Property ..................................... 6 63 8 Acknowledgments ........................................... 6 64 9 Normative References ...................................... 7 66 1. Introduction 68 Many circuit cards used in the global telecommunications network have 69 a CLEI Code assigned and have a bar code or two-dimensional symbol on 70 a label affixed to the front of that circuit card. Service providers 71 utilize the CLEI Code to: 73 o Track inventory, both working and spare 75 o Logistics (movement of circuit cards, along with the serial 76 number) 78 o Provision equipment 80 o Maintain asset records (accounting information) 82 The goal of the CLEI namespace is to ensure the stability and 83 uniqueness of the names of various (specific) items that are used 84 within the messages exchanged between equipment used in the global 85 telecommunications network. 87 The assigned maintenance agent for the CLEI Code, Telcordia 88 Technologies, is responsible for assigning certain equipment and 89 other identifiers (e.g., location, manufacturer/supplier) for the 90 telecommunications industry. The code assignment process identifies 91 the structure and intelligence of the CLEI Code to identify the 92 circuit card's form, fit, functions, and features. Equipment may 93 exist in multiple physical locations with the exact same form, fit, 94 functions, and features and will have the same CLEI Code if their 95 Product ID is the same. 97 2. Specification Template 99 Namespace ID: 101 "CLEI" 103 Registration Information: 105 Version 1 106 Date: 2004-12-31 108 Declared registrant of the namespace: 110 Telcordia Technologies, Inc. 111 Customer Support Center 112 8 Corporate Place 113 Piscataway, NJ 08854 114 U.S.A. 115 +1.732.699.5577 116 http://www.commonlanguage.com 118 Declaration of syntactic structures: 120 The structure of the Namespace Specific String is a flat space of 121 10 characters as defined in [T1.213][T1.213a]. 123 Relevant ancillary Documentation: 125 [T1.213] and [T1.213a]. 127 Identifier uniqueness considerations: 129 Identifiers are assigned by Telcordia URN registration that 130 guarantees Uniqueness for items with different form, fit, 131 functions, and features. This is simply achieved by keeping track 132 of already assigned names and comparing all new proposed names to 133 the database ones. If the name already exists a new one is 134 created per the rules of the process. See [T1.213][T1.213a] for 135 assignment examples. 137 Identifiers persistence considerations: 139 The process defined by ANSI and the CLEI maintenance agent ensure 140 the binding between the name and its resource is permanent, and 141 that names are not reassigned. 143 Process of identifiers assignment: 145 A CLEI Code is an intelligent code that consists of 10 146 alphanumeric characters with 4 data elements. The first data 147 element is considered the basic code with the first 2 characters 148 indicating the technology or equipment type with the third and 149 fourth characters denoting the functional sub-category. The 150 second data element represents the features and its three 151 characters denote functional capabilities or changes. The third 152 data element has one character and denotes a reference to 153 manufacturer, system ID, specification or drawing. The fourth data 154 element consists of two characters and contains complementary 155 data. These two characters provide a means of differentiating or 156 providing uniqueness between the eight character CLEI Codes by 157 identifying the manufacturing vintage of the product. Names are 158 assigned via procedures defined in [GR485]. 160 Process for identifier resolution: 162 Telcordia URNs are resolved via Telcordia resolvers run under 163 Telcordia responsibility. For further information see 164 www.commonlanguage.com. 166 Rules for lexical equivalence: 168 Lexical equivalence of two CLEI URN namespace specific strings is 169 defined as an exact, case-insensitive string match. CLEI codes 170 are assigned in a case-insensitive fashion, so that there will not 171 be two CLEI codes that differ only in case. See [T1.213] and 172 [T1.213a] for further information. 174 Conformance with URN syntax: 176 No special consideration. 178 Validation mechanism: 180 None specified. 182 Scope: 184 Global. 186 3. Examples 188 The following three examples are based on the examples provided in 189 [T1.213a], and correspond with three different sets of features by 190 three different manufacturers (Nortel Networks, Lear and Lucent 191 Technologies) producing "D4CE" (a particular D4 channel bank type) 192 equipment. The fourth example refers to a SONET power unit convertor 193 of Alcatel. 195 URN:CLEI:D4CE18B7AA 196 URN:CLEI:D4CE4248AA 197 URN:CLEI:D4CE363PAB 198 URN:CLEI:SNPWBBC7AA 200 4. Namespace and Community Considerations 202 CLEI codes have historically been used in a variety of communications 203 equipment (see examples above and [213a]). There are circumstances 204 where entities with CLEI codes need to be managed or exposed in a 205 larger context, such as the general Internet. In these cases, the use 206 of the CLEI URN namespace will provide general interoperability 207 benefits to the Internet at large, as well as to specific internets. 209 5. Security Considerations 211 There are no additional security considerations other than those 212 normally associated with the use and resolution of URNs in general. 214 It is noted however that attempting to resolve a Telcordia URN 215 through a resolver other than the one provided by Telcordia is not 216 considered authoritative. 218 6. IANA Considerations 220 The IANA has registered formal URN namespace ????, to Telcordia 221 within the IANA registry of URN NIDs. 223 7. Intellectual Property 225 The IETF takes no position regarding the validity or scope of any 226 intellectual property or other rights that might be claimed to 227 pertain to the implementation or use of the technology described in 228 this document or the extent to which any license under such rights 229 might or might not be available; neither does it represent that it 230 has made any effort to identify any such rights. Information on the 231 IETF's procedures with respect to rights in standards-track and 232 standards-related documentation can be found in BCP-11. Copies of 233 claims of rights made available for publication and any assurances of 234 licenses to be made available, or the result of an attempt made to 235 obtain a general license or permission for the use of such 236 proprietary rights by implementors or users of this specification can 237 be obtained from the IETF Secretariat. 239 The IETF invites any interested party to bring to its attention any 240 copyrights, patents or patent applications, or other proprietary 241 rights which may cover technology that may be required to practice 242 this standard. Please address the information to the IETF Executive 243 Director. 245 8. Acknowledgments 247 The contributions of the Entity MIB Working Group members are 248 gratefully acknowledged. Special thanks go to Mike Heard, Juergen 249 Schoenwaelder, Dave Perkins and Dan Romascanu. 251 9. Normative References 253 [RFC3406] Daigle, L., van Gulik, D., Iannella, R. and P. Faltstrom, 254 "Uniform Resource Name (URN) Namespace Definition 255 Mechanisms", BCP 66, RFC 3406, October 2002. 257 [T1.213] ATIS T1.213-2001, Coded Identification of Equipment Entities 258 in the North American Telecommunications System for 259 Information Exchange, 2001, www.ansi.org 261 [T1.213a] ATIS T1.213a, Supplement to T1.213-2001, Coded 262 Identification of Equipment Entities in the North American 263 Telecommunications System for Information Exchange, to 264 correct the representation of the Basic Code in Figure B.1, 265 2001, www.ansi.org 267 [GR485] GR-485-CORE, COMMON LANGUAGE Equipment Codes (CLEI Codes), 268 Generic Requirements for Processes And Guidelines, Issue 5, 269 Telcordia Technologies, April 2004. 271 Authors' addresses 273 Kaj Tesink 274 One Telcordia Drive 275 Piscataway, NJ 08854 276 USA 277 Phone: +1 732 699-6068 278 EMail: kaj@research.telcordia.com 280 Robert H. Fox 281 3545 S.Ocean Blvd, #417 282 Palm Beach, FL 33480-5715 283 USA 284 Phone: +1 732 699-8968 285 EMail: rfox@telcordia.com 287 Intellectual Property Statement 289 The IETF takes no position regarding the validity or scope of any 290 Intellectual Property Rights or other rights that might be claimed to 291 pertain to the implementation or use of the technology described in 292 this document or the extent to which any license under such rights 293 might or might not be available; nor does it represent that it has 294 made any independent effort to identify any such rights. Information 295 on the procedures with respect to rights in RFC documents can be 296 found in BCP 78 and BCP 79. 298 Copies of IPR disclosures made to the IETF Secretariat and any 299 assurances of licenses to be made available, or the result of an 300 attempt made to obtain a general license or permission for the use of 301 such proprietary rights by implementers or users of this 302 specification can be obtained from the IETF on-line IPR repository at 303 http://www.ietf.org/ipr. 305 The IETF invites any interested party to bring to its attention any 306 copyrights, patents or patent applications, or other proprietary 307 rights that may cover technology that may be required to implement 308 this standard. Please address the information to the IETF at ietf- 309 ipr@ietf.org. 311 Disclaimer of Validity 313 This document and the information contained herein are provided on an 314 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 315 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 316 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 317 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 318 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 319 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 321 Copyright Statement 323 Copyright (C) The Internet Society (2004). This document is subject 324 to the rights, licenses and restrictions contained in BCP 78, and 325 except as set forth therein, the authors retain all their rights. 327 Acknowledgment 329 Funding for the RFC Editor function is currently provided by the 330 Internet Society. 332 ************************************************************ 333 * NOTES TO RFC Editor (to be removed prior to publication) * 334 * * 335 * Please replace "????" in the IANA Considerations section * 336 * with an IANA-assigned URN NID. * 337 * * 338 ************************************************************