idnits 2.17.1 draft-montville-mile-enum-reference-format-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([IODEF]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 14, 2012) is 4150 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: 'RFC3986' is mentioned on line 195, but not defined == Missing Reference: 'RFC5226' is mentioned on line 203, but not defined ** Obsolete undefined reference: RFC 5226 (Obsoleted by RFC 8126) == Unused Reference: '3986' is defined on line 224, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5070 (ref. 'IODEF') (Obsoleted by RFC 7970) ** Obsolete normative reference: RFC 5226 (ref. '3986') (Obsoleted by RFC 8126) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Adam W. Montville 3 Intended Status: Standards Track (Tripwire, Inc.) 4 Expires: June 17, 2013 December 14, 2012 6 IODEF Enumeration Reference Format 7 draft-montville-mile-enum-reference-format-02 9 Abstract 11 The Incident Object Description Exchange Format [IODEF] provides a 12 Reference class used to reference external entities (such as 13 enumeration identifiers). However, the method of external entity 14 identification has been left unstructured. This document describes a 15 method to provide structure for referencing external entities for the 16 [IODEF] Reference class. 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/1id-abstracts.html 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 Copyright and License Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Referencing External Enumerations . . . . . . . . . . . . . . 3 59 3 Security Considerations . . . . . . . . . . . . . . . . . . . . 6 60 4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 61 5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 5.1 Normative References . . . . . . . . . . . . . . . . . . . 7 63 5.2 Informative References . . . . . . . . . . . . . . . . . . 7 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 66 1 Introduction 68 There is an identified need to specify a format to include relevant 69 enumeration values in an IODEF document. It is anticipated that this 70 requirement will exist in other standardization efforts within 71 several IETF Working Groups, but the scope of this document pertains 72 solely to [IODEF]. 74 1.1 Terminology 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in RFC 2119 [RFC2119]. 80 2. Referencing External Enumerations 82 The need is to place enumeration identifiers and their references in 83 [IODEF]'s Reference class. There are several ways to accomplish this 84 goal, but one that seems the most appropriate at this point is to 85 require a specific format for the ReferenceName string of the [IODEF] 86 Reference class, such that an IANA table can be used to catalog a 87 variety of reference types. 89 +------------------+ 90 | Reference | 91 +------------------+ 92 | |<>----------[ ReferenceName ] 93 | |<>--{0..*}--[ URL ] 94 | |<>--{0..*}--[ Description ] 95 +------------------+ 97 FIGURE 1: [IODEF] Reference Class 99 Per [IODEF] the ReferenceName is of type ML_STRING. This becomes 100 problematic when specific references, especially enumerations such as 101 CEE, CVE, CCE, and so on, are referenced - how is an implementer to 102 know which type of reference this is, and thus how to parse it? One 103 solution, presented here, is to require that ReferenceName follow a 104 particular format. 106 2.1 Reference Name Format 108 The format of the ReferenceName MUST follow the form of 110 id_type:version:id 112 Where id_type is an IANA-registered type having the form 113 115 And where version is an IANA-registered type having the form 117 119 And where id is the actual enumeration identifier string. 121 The IANA Considerations section of this document provides details for 122 and . This format allows the to be 123 associated with the id rather than the id_type. By requiring that a 124 specific type and version be associated with the identifier, an 125 implementer can look up the type in an IANA table to understand 126 exactly what the identifier in ReferenceName is and how s/he may 127 expect that identifier to be structured. 129 2.2 Reference Example 131 The operation of this method can be described using a fictitious 132 example. Assume a Reference class as described in the Section 2 133 introduction and an enumeration of formatted strings used to identify 134 Concept X. Then, the string format of Concept X Identifiers would be 135 registered with IANA (see Section 4), such that implementations of 136 the Reference class understand how to handle the formatted string. 138 139 CXI:1.0:CXI-1234-XYZ 140 http://cxi.example.com 141 Foo 142 144 Information in the IANA table (see Section 4) would include: 146 Full Name: Concept X Identifier 147 Abbreviation: CXI 148 Version: 1.0 149 Specification URI: http://cxi.example.com/spec_url 151 2.3 Reference Method Applicability 153 While the scope of this document pertains to [IODEF], it should be 154 readily apparent that any standard needing to reference an 155 enumeration identified by a specially formatted string can use 156 this method of providing structure after the standard has been 157 published. In effect, this method provides a standardized 158 interface for enumerations, thus allowing a loose coupling between 159 a given standard and the enumeration identifiers it needs to 160 reference now and in the future. 162 3 Security Considerations 164 None. 166 4 IANA Considerations 168 This document specifies an identifier format for the [IODEF] 169 ReferenceName string of the Reference class. 171 Registration request for the IODEF Enumeration Reference Format: 173 Name of the Registry: "Enumeration Reference Type Identifiers" 175 The registry is intended to enable enumeration value additions to 176 attributes of a given reference class of an IETF standard, for 177 example, the Reference class of the IODEF schema. Note that 178 certain name requests should not be permitted as either Full Name 179 or Abbreviation entries for the requested IANA table. For 180 example, the following list should not be permitted: foo, bar, 181 example.com. It is anticipated that the Expert Review process 182 will flag any additional undesired Full Name or Abbreviation 183 issues. 185 Fields to record in the registry: 187 Full Name: The full name of the enumeration as a string 189 Abbreviation: The abbreviation of the enumeration as a string, 190 e.g. a short initialization is encouraged 192 Version: The version of the enumeration as a string, e.g. dot- 193 separated numbers are a good idea 195 Specification URI: A list of one or more URIs [RFC3986] from 196 which the registered specification can be obtained. The 197 registered specification MUST be readily and publicly available 198 from that URI. 200 Initial registry contents: None. 202 Allocation Policy: Expert Review [RFC5226] and Specification 203 Required [RFC5226] 205 The Designated Expert is expected to consult with the MILE (Managed 206 Incident Lightweight Exchange) working group or its successor if any 207 such WG exists (e.g., via email to the working group's mailing list). 208 The Designated Expert is expected to review the request and validate 209 the appropriateness of the enumeration for the attribute. If a 210 specification is associated with the request, it MUST be reviewed by 211 the Designated Expert. 213 5 References 215 5.1 Normative References 217 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 218 Requirement Levels", BCP 14, RFC 2119, March 1997. 220 [IODEF] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident 221 Object Description Exchange Format", RFC 5070, December 222 2007. 224 [3986] Narten, T. and H. Alvestrand, "Guidelines for Writing an 225 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 226 May 2008. 228 5.2 Informative References 230 None. 232 Authors' Addresses 234 Adam W. Montville 235 Tripwire, Inc. 236 101 SW Main Street 237 Suite 1500 238 Portland, OR 97204 240 EMail: amontville@tripwire.com