One document matched: draft-montville-mile-enum-reference-format-01.txt

Differences from draft-montville-mile-enum-reference-format-00.txt

 



INTERNET-DRAFT                                         Adam W. Montville
Intended Status: Standards Track                        (Tripwire, Inc.)
Expires: May 10, 2013                                   November 6, 2012



                  IODEF Enumeration Reference Format 
             draft-montville-mile-enum-reference-format-01


Abstract

   Some standards, such as the Incident Object Description Exchange
   Format [IODEF], provide classes used to reference external entities
   (such as enumeration identifiers).  At the time of standardization,
   however, needed references may not be known, and the method of
   external entity identification is often left unstructured.  This
   document describes a method to provide structure after the fact for
   [IODEF].


Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html


Copyright and License Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors. All rights reserved.

 


Adam W. Montville         Expires May 10, 2013                  [Page 1]

INTERNET DRAFT     IODEF Enumeration Reference Format   November 6, 2012


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://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.



Table of Contents

   1  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1  Terminology . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Referencing External Enumerations  . . . . . . . . . . . . . .  3
   3  Security Considerations . . . . . . . . . . . . . . . . . . . .  5
   4  IANA Considerations . . . . . . . . . . . . . . . . . . . . . .  5
   5  References  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     5.1  Normative References  . . . . . . . . . . . . . . . . . . .  6
     5.2  Informative References  . . . . . . . . . . . . . . . . . .  6
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  6

























 


Adam W. Montville         Expires May 10, 2013                  [Page 2]

INTERNET DRAFT     IODEF Enumeration Reference Format   November 6, 2012


1  Introduction

   There is an identified need to specify a format to include relevant
   enumeration values in an IODEF document.  It is anticipated that this
   requirement will exist in other standardization efforts within
   several IETF Working Groups, but the scope of this document pertains
   to [IODEF].

1.1  Terminology

   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].


2.  Referencing External Enumerations

   The need is to place enumeration values and their references in
   [IODEF]'s Reference class.  There are several ways to accomplish this
   goal, but one that seems the most appropriate at this point is to
   require a specific format for the ReferenceName string of the [IODEF]
   Reference class, such that an IANA table can be used to catalog a
   variety of reference types.

      +------------------+
      | Reference        |
      +------------------+
      |                  |<>----------[ ReferenceName ]
      |                  |<>--{0..*}--[ URL           ]
      |                  |<>--{0..*}--[ Description   ]
      +------------------+

                   FIGURE 1: [IODEF] Reference Class 

   Per [IODEF] the ReferenceName is of type ML_STRING.  This becomes
   problematic when specific references, especially enumerations such as
   CEE, CVE, CCE, and so on, are referenced - how is an implementer to
   know which type of reference this is, and thus how to parse it? One
   solution, presented here, is to require that ReferenceName follow a
   particular format. 

 2.1 Reference Name Format

   The format of the ReferenceName MUST follow the form of

      id_type:id

   Where id_type is an IANA-registered type having the form
 


Adam W. Montville         Expires May 10, 2013                  [Page 3]

INTERNET DRAFT     IODEF Enumeration Reference Format   November 6, 2012


      <Abbreviation>_<Version>

   The IANA Considerations section of this document provides details for
   Abbreviation and Version.  By requiring that a specific type be
   prepended to the identifier, an implementer can look up the type in
   an IANA table to understand exactly what the identifier in
   ReferenceName is.


 2.2 Reference Example

   The operation of this method can be described using a fictitious
   example.  Assume a Reference class as described in the Section 2
   introduction and an enumeration of formatted strings used to identify
   Concept X.  Then, the string format of Concept X Identifiers would be
   registered with IANA (see Section 4), such that implementations of
   the Reference class understand how to handle the formatted string.


      <Reference>
         <ReferenceName>CXI_1.0:CXI-1234-XYZ</ReferenceName>
         <URL>http://cxi.example.com</URL>
         <Description>Foo</Description>
      </Reference>

   Information in the IANA table (see Section 4) would include:

      Full Name: Concept X Identifier
      Abbreviation: CXI
      Version: 1.0
      Specification URI: http://cxi.example.com/spec_url

 2.3 Reference Method Applicability

      While the scope of this document pertains to [IODEF], it should be
      readily apparent that any standard needing to reference an
      enumeration identified by a specially formatted string can use
      this method of providing structure after the standard has been
      published.  In effect, this method provides a standardized
      interface for enumerations, thus allowing a loose coupling between
      a given standard and the enumerations it needs to reference now
      and in the future.






 


Adam W. Montville         Expires May 10, 2013                  [Page 4]

INTERNET DRAFT     IODEF Enumeration Reference Format   November 6, 2012


3  Security Considerations

      None.


4  IANA Considerations

      This document specifies an identifier format for the [IODEF]
      ReferenceName string of the Reference class.

      Registration request for the IODEF Enumeration Reference Format:

      Name of the Registry: "Enumeration Reference Type Identifiers"

      The registry is intended to enable enumeration value additions to
      attributes of a given reference class of an IETF standard, for
      example, the Reference class of the IODEF schema.  Note that
      certain name requests should not be permitted as either Full Name
      or Abbreviation entries for the requested IANA table.  For
      example, the following list should not be permitted: foo, bar,
      example.com.  It is anticipated that the Expert Review process
      will flag any additional undesired Full Name or Abbreviation
      issues.

      Fields to record in the registry: 

         Full Name: The full name of the enumeration as a string

         Abbreviation: The abbreviation of the enumeration as a string

         Version: The version of the enumeration as a string

         Specification URI: A list of one or more URIs [RFC3986] from
         which the registered specification can be obtained.  The
         registered specification MUST be readily and publicly available
         from that URI.

      Initial registry contents: None.

      Allocation Policy: Expert Review [RFC5226] and Specification
      Required [RFC5226]

   The Designated Expert is expected to consult with the MILE (Managed
   Incident Lightweight Exchange) working group or its successor if any
   such WG exists (e.g., via email to the working group's mailing list).
   The Designated Expert is expected to review the request and validate
   the appropriateness of the enumeration for the attribute.  If a
   specification is associated with the request, it MUST be reviewed by
 


Adam W. Montville         Expires May 10, 2013                  [Page 5]

INTERNET DRAFT     IODEF Enumeration Reference Format   November 6, 2012


   the Designated Expert.


5  References

5.1  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [IODEF]    Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident
              Object Description Exchange Format", RFC 5070, December
              2007.

   [3986]     Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.


5.2  Informative References

              None.



Authors' Addresses


   Adam W. Montville
   Tripwire, Inc.
   101 SW Main Street
   Suite 1500
   Portland, OR 97204

   EMail: amontville@tripwire.com
















Adam W. Montville         Expires May 10, 2013                  [Page 6]