Subject: [mile] EnumRef Format to IODEF Extension Suggestion

From: "Adam W. Montville" <[email-masked]>
Date: Fri, 25 Jul 2014 07:29:53 -0400

Hello,

During MILE’s session this week at IETF 90, Roman suggested that the enum reference format be changed from an update to 5070 to an IODEF extension.  This would require that the enum reference format draft be updated accordingly and that a full schema and namespace be considered for the format itself, rather than simply updating the IODEF schema.

The obvious drawback is that the enum reference document backpedals a bit and will take longer to complete.  A benefit is that this method of referencing enumeration identifier formats can be reused by other efforts (I’m confident that SACM could make use of the draft if we change it, for example).  

What are your thoughts/reactions to this proposal?  

Regards,

Adam

---

From: "Roman D. Danyliw" <[email-masked]>
Date: Sat, 26 Jul 2014 02:50:53 +0000

Hello!

To be more specific about what was proposed at IETF 90, please find inline a rough draft of modifications agathe -07 draft.  Beyond the boiler-plate, only sections with modified text are listed.

---[ snip ]-- 

MILE Working Group                                          A. Montville
Internet-Draft                                                  Tripwire
Obsoletes:                                                       D. Black
Intended status: Standards Track                                     EMC
Expires: January 31, 2015                                    August 2014

                   IODEF Enumeration Reference Format
              draft-ietf-mile-enum-reference-format-07-bis

Abstract

   [Keep first paragraph]

   [Modified second paragraph] This memo provides an extension to RFC
   5070 to include both the external specification and specific
   enumeration value in the IODEF Reference class.  This memo also
   establishes an IANA registry to manage external enumeration
   specifications for use by IODEF.

   The IETF has been notified of intellectual property rights claimed in
   regard to some or all of the specification contained in this
   document.  For more information consult the online list of claimed
   rights.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on January 31, 2015.

Copyright Notice

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

Montville & Black       Expires January 31, 2015                [Page 1]

Internet-Draft                IODEFv2 ENUM                   August 2014

   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.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Referencing External Enumerations  . . . . . . . . . . . . . .  2
     2.1.  ReferenceName Class  . . . . . . . . . . . . . . . . . . .  2
     2.2.  Reference Method Applicability . . . . . . . . . . . . . .  3
   3.  Security Considerations  . . . . . . . . . . . . . . . . . . .  3
   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  4
   5.  The ReferenceName Schema . . . . . . . . . . . . . . . . . . .  4
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  5

1.  Introduction

   No change.

1.1.  Terminology

   No change.

2.  Referencing External Enumerations

   No change.

2.1.  ReferenceName Class

Montville & Black       Expires January 31, 2015                [Page 2]

Internet-Draft                IODEFv2 ENUM                   August 2014

   The ReferenceName class provides the XML representation for
   identifying an enumeration and specifying a value from it.  A given
   enumeration is uniquely identified by the specIndex attribute.  Each
   specIndex value corresponds to an entry in the "Enumeration Reference
   Type Identifiers" IANA registry (see Section 4).  The child ID
   element represents a particular value from the corresponding
   enumeration identified by the specIndex attribute.  The format of the
   ID element is described in the IANA registry entry of the
   enumeration.

   +-------------------------+
   | ReferenceName           |
   +-------------------------+
   | INTEGER specIndex       |<>----------[ ID    ]
   +-------------------------+

   The aggregate classes that constitute ReferenceName:

   ID 
      One.  ID.  Name of the reference.

   The ReferenceName class has 1 attribute.

   specIndex 
      Required.  INTEGER.  Enumeration identifier.  This value
      corresponds to an entry in the  "Enumeration Reference Type
      Identifiers" IANA registry with an identical SpecIndex value.

   An example of such a reference is as follows:

      <iodef:Reference>
         <iodef-enum:ReferenceName specIndex="1">
            <iodef-enum:ID>CXI-1234-XYZ</iodef-enum:ID>
         </iodef-enum:ReferenceName>
         <iodef:URL>http://cxi.example.com</iodef:URL>
         <iodef:Description>Foo</iodef:Description>
      </iodef:Reference>

   The corresponding information in the IANA table (see Section 4) would
   include:

      Full Name: Concept X Identifier
      SpecIndex: 1
      Version: any
      Specification URI: http://cxi.example.com/spec_url

2.2.  Reference Method Applicability

   No change, but this should should be numbered 2.2 not 2.3 as in the
   -07 draft.

3.  Security Considerations

Montville & Black       Expires January 31, 2015                [Page 3]

Internet-Draft                IODEFv2 ENUM                   August 2014

   No change.

4.  IANA Considerations

   [after the existing text, the following should be added ...]

   This document uses URNs to describe XML namespaces and XML schemas
   conforming to a registry mechanism described in [RFC3688].

   Registration request for the IODEF enumeration reference format
   namespace:

   URI : urn:ietf:params:xml:ns:iodef-enum-1.0

   Registrant Contact : See the "Authors' Addresses" section of this
      document.

   XML : None.

   Registration request for the IODEF enumeration reference format XML
   schema:

   URI : urn:ietf:params:xml:schema:iodef-enum-1.0

   Registrant Contact See the "Authors' Addresses" section of this
      document.

   XML : See Section 6, "XML Schema", of this    document.

5.  The ReferenceName Schema

   <?xml version="1.0" encoding="UTF-8"?>
   <xs:schema attributeFormDefault="unqualified"
          elementFormDefault="qualified"
          targetNamespace="urn:ietf:params:xml:ns:iodef-enum-1.0"
          xmlns:xs="http://www.w3.org/2001/XMLSchema"
          xmlns:enum="urn:ietf:params:xml:ns:iodef-enum-1.0">
   
     <!--
     ==========================================================
     ===  ReferenceName                                     ===
     ==========================================================
      -->
     <xs:element name="ReferenceName">
       <xs:complexType>
         <xs:sequence>
           <xs:element name="ID" type="xs:NCName"/>
         </xs:sequence>
         <xs:attribute name="specIndex"
                       type="xs:integer" use="required"/>
       </xs:complexType>
     </xs:element>
   </xs:schema>

Montville & Black       Expires January 31, 2015                [Page 4]

Internet-Draft                IODEFv2 ENUM                   August 2014

6.  References

Authors' Addresses

   Adam W. Montville
   Tripwire
   USA
   
   Email: Adam's email

   David Black
   EMC
   USA
   
   Email: David's email

Montville & Black       Expires January 31, 2015                [Page 5]

--[ end ]--

Roman

-----Original Message-----
From: mile [mailto:[email-masked]] On Behalf Of Adam W. Montville
Sent: Friday, July 25, 2014 7:30 AM
To: MILE IETF
Subject: [mile] EnumRef Format to IODEF Extension Suggestion

Hello,

During MILE's session this week at IETF 90, Roman suggested that the enum reference format be changed from an update to 5070 to an IODEF extension.  This would require that the enum reference format draft be updated accordingly and that a full schema and namespace be considered for the format itself, rather than simply updating the IODEF schema.

The obvious drawback is that the enum reference document backpedals a bit and will take longer to complete.  A benefit is that this method of referencing enumeration identifier formats can be reused by other efforts (I'm confident that SACM could make use of the draft if we change it, for example).  

Regards,

Adam

---

From: "Black, David" <[email-masked]>
Date: Sun, 27 Jul 2014 13:47:20 -0400

Hello Roman,

This approach is interesting, although it looks like it would still require a
change to the IODEF Schema version.  I wonder whether we can go further than
arrange for the 5070bis draft to contain the only new version of the IODEF
schema beyond RFC 5070.  Towards that end, I have a couple of questions:

(1) Could the SpecIndex attribute be added to the ReferenceName class in the
IODEF v2 schema in 5070bis, as an optional attribute?  My thinking is that having
this new attribute be optional allows the IODEF v2 Reference class to continue to
be used for everything that it's used for in IODEF v1, but when the SpecIndex
attribute is present, it constrains the ReferenceName to follow the format in the
enumeration reference draft - the latter requirement would be imposed by
additional text in the 5070bis draft.

(2) The Reference class in the IODEF v1 schema (RFC 5070) is not extensible in
that schema, but that Reference class is contained in the Method class which can
be extended via use of the (optional) AdditionalData class.  Is there a reasonably
acceptable/usable approach to use of AdditionalData with Method to pull the
enumeration references into IODEF v1 without creating a new schema version,
or is this just asking for confusion?

Thanks,
--David

> From: mile [mailto:[email-masked]] On Behalf Of Roman D. Danyliw
> Sent: Friday, July 25, 2014 10:51 PM
> To: 'Adam W. Montville'; MILE IETF
> Subject: Re: [mile] EnumRef Format to IODEF Extension Suggestion
> 
> Hello!
> 
> To be more specific about what was proposed at IETF 90, please find inline a
> rough draft of modifications agathe -07 draft.  Beyond the boiler-plate, only
> sections with modified text are listed.
> 
> ---[ snip ]--
> 
> During MILE's session this week at IETF 90, Roman suggested that the enum
> reference format be changed from an update to 5070 to an IODEF extension.
> This would require that the enum reference format draft be updated accordingly
> and that a full schema and namespace be considered for the format itself,
> rather than simply updating the IODEF schema.
> 
> The obvious drawback is that the enum reference document backpedals a bit and
> will take longer to complete.  A benefit is that this method of referencing
> enumeration identifier formats can be reused by other efforts (I'm confident
> that SACM could make use of the draft if we change it, for example).
> 
> _______________________________________________
> mile mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mile

---

From: "Roman D. Danyliw" <[email-masked]>
Date: Thu, 31 Jul 2014 19:33:39 +0000

Hello David!

> From: Black, David [mailto:[email-masked]]
> Sent: Sunday, July 27, 2014 1:47 PM
> To: Roman D. Danyliw; MILE IETF
> Cc: Black, David
> Subject: RE: [mile] EnumRef Format to IODEF Extension Suggestion
> 
> Hello Roman,
> 
> change to the IODEF Schema version.  I wonder whether we can go further
> than arrange for the 5070bis draft to contain the only new version of the
> IODEF schema beyond RFC 5070.  Towards that end, I have a couple of
> questions:

I hadn't been thinking along these lines.  To use a software analogy, I didn't envision that we'd back-port the fix to a legacy version of the software (IODEFv1, RFC 5070).  Instead I figured we should make a library (an iodef enum extension) that the new version (IODEF v2, 5070bis) and alternate software (SACM) could use.  My thinking was if v1 is broken, upgrade to v2, not v1.01.

> (1) Could the SpecIndex attribute be added to the ReferenceName class in
> the IODEF v2 schema in 5070bis, as an optional attribute?  My thinking is that
> having this new attribute be optional allows the IODEF v2 Reference class to
> continue to be used for everything that it's used for in IODEF v1, but when
> the SpecIndex attribute is present, it constrains the ReferenceName to
> follow the format in the enumeration reference draft - the latter
> requirement would be imposed by additional text in the 5070bis draft.

That does provide maximum flexibility.  The thinking would be if you see the SpecIndex reference the enum draft to understand the semantics.  If there is not SpecIndex reference 5070.  This switch could also be handle with namespaces by defining a schema of "choice ( iodef-1.0:Reference, iodef-enum:Reference)".

We have to decide whether to specify a stand-alone schema, an IODEF extension, or both?  Would SACM only use the newer SpecIndex-based Reference class?

I feel that the implementers need to tell us how much backward compatibility needs to be maintained.  We've already broken compatibility in 5070bis on Node/Name, Node/DateTime, and Service@ip_protocol.  My feeling is that we should break it here again and force the "new improved" Reference in v2.  Perhaps we can add some escape value into SpecIndex to make the new ReferenceName/ID behave like a Description class.

> that schema, but that Reference class is contained in the Method class which
> can be extended via use of the (optional) AdditionalData class.  Is there a
> reasonably acceptable/usable approach to use of AdditionalData with
> Method to pull the enumeration references into IODEF v1 without creating a
> new schema version, or is this just asking for confusion?

If the enum draft was published to include an iodef extension no change at would be required to RFC5070.  An implementer would simply drop in the enum extension into Method/AdditionalData.  The only challenge would be that a Reference or Description child class are required.  Therefore to use AdditionalData you would have to "<Method><Description/><AdditionalData ...></Method>".

Roman
 
> > To be more specific about what was proposed at IETF 90, please find
> > inline a rough draft of modifications agathe -07 draft.  Beyond the
> > boiler-plate, only sections with modified text are listed.
> >
> > ---[ snip ]--
> >
> > During MILE's session this week at IETF 90, Roman suggested that the
> > enum reference format be changed from an update to 5070 to an IODEF
> extension.
> > This would require that the enum reference format draft be updated
> > accordingly and that a full schema and namespace be considered for the
> > format itself, rather than simply updating the IODEF schema.
> >
> > The obvious drawback is that the enum reference document backpedals a
> > bit and will take longer to complete.  A benefit is that this method
> > of referencing enumeration identifier formats can be reused by other
> > efforts (I'm confident that SACM could make use of the draft if we change
> it, for example).
> >