Subject: Re: [mile] EnumRef Format to IODEF Extension Suggestion

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Tue, 5 Aug 2014 19:09:37 +0000

I support this effort, even though it will delay the enum document adoption.
Backwards compatibility is an issue, but give all the updates of IODEF-bis this does not pose a huge concern.
Panos

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

What are your thoughts/reactions to this proposal?  

Regards,

Adam

---

From: "Black, David" <[email-masked]>
Date: Tue, 5 Aug 2014 19:28:26 -0400

Hello Roman,

This is helpful (thanks):

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

Well, the current draft is an incompatible back-port because it updates
the IODEFv1 schema version to "1.01".  I understand both you and Panos to
be characterizing that as a bad idea (on which I defer to your expertise),
so I'd like to explore alternatives.

My next question is "what sort of library?".  The email below proposes what
is effectively a reusable XML (sub-schema) that can be included in other
XML schemas.

I wonder whether instead of supplying the (sub-)schema as a "library" that
can be used at runtime, can we supply the XML schema snippet for enum
reference formats for use in XML schema design along with the IANA registry.

One more question:

Is there a case to be made for use of the same XML (sub-)schema (iodef-enum
below) in multiple containing schemas, e.g., IODEFv2, SACM, etc., or is it
sufficient to use the same XML syntax to represent the enumeration values?

For "same XML syntax", the draft could recommend that anyone who wants to use
an enumeration reference value put the following XML snippet in their schema:

      <xs:element name="SpecReferenceName">
       <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>

[NB: I changed "ReferenceName" to "SpecReferenceName" with the intent of
enabling use of an unconstrained "ReferenceName" element for other purposes.]

The enum-reference-format draft could further recommend that documentation
of any schema that includes that snippet include a reference to the IANA
registry (created by the enum-reference-format draft) that defines the
specIndex values.

That ought to simplify adding this to the IODEFv2 (5070bis) schema.

Thoughts?

Thanks,
--David

> From: Roman D. Danyliw [mailto:[email-masked]]
> Sent: Thursday, July 31, 2014 3:34 PM
> To: Black, David; MILE IETF
> Subject: RE: [mile] EnumRef Format to IODEF Extension Suggestion
>
> 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,
> >
> > 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:
>
> 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.
>
> > (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?
>
> 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
>
> > > 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 ]--
> > >
> > > 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
> > >
> > > 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: "Adam W. Montville" <[email-masked]>
Date: Wed, 6 Aug 2014 10:00:28 -0500

> That ought to simplify adding this to the IODEFv2 (5070bis) schema.

If we encourage pasting the above into other schemas, is there then a policing effort to ensure that documentation references are correct and that the schema is correct?  It seems better for wider adoption to go with the inbuilt XML constructs of namespaces to allow IODEFv2 to simply reference an enum ref namespace at the appropriate location, then define the enum ref schema once, which will be associated with just one document detailing the IANA registry and the expert review, etc.

---

From: "Black, David" <[email-masked]>
Date: Mon, 18 Aug 2014 13:27:28 -0400

On XML snippet vs. schema:

> If we encourage pasting the above [XML snippet] into other schemas, is there
> then a policing
> effort to ensure that documentation references are correct and that the schema
> is correct?  It seems better for wider adoption to go with the inbuilt XML
> constructs of namespaces to allow IODEFv2 to simply reference an enum ref
> namespace at the appropriate location, then define the enum ref schema once,
> which will be associated with just one document detailing the IANA registry
> and the expert review, etc.

Well, the IANA registry and its associated review procedures get defined once in
one document, independent of what we do.

OTOH, the namespace separation and related discipline of using a separate schema
for the enumeration references are useful and the proverbial "right thing to do,"
plus Roman's provided much (if not all of the text) needed, so I'm fine with that
approach.

Thanks,
--David

> From: Adam W. Montville [mailto:[email-masked]]
> Sent: Wednesday, August 06, 2014 11:00 AM
> To: Black, David
> Cc: Roman D. Danyliw; MILE IETF
> If we encourage pasting the above into other schemas, is there then a policing
> effort to ensure that documentation references are correct and that the schema
> is correct?  It seems better for wider adoption to go with the inbuilt XML
> constructs of namespaces to allow IODEFv2 to simply reference an enum ref
> namespace at the appropriate location, then define the enum ref schema once,
> which will be associated with just one document detailing the IANA registry
> and the expert review, etc.
>
>
> >
> > Thanks,
> > --David
> >
> >