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

From: "Takeshi Takahashi" <[email-masked]>
Date: Wed, 22 Oct 2014 10:56:30 +0900

Hello Adam, David, and all,

I agree with the direction you have developed (developing separate schema
would be a good idea.)
I apologize my late response.

I can see several supportive comments on this draft change, and I can see no
negative comments on this.
So, I believe the community is happy to develop the draft to the direction
the authors did.

The last concern is the schema, IMHO.
We have already asked App area experts to review the newly changed schema,
but I think we have not received clear confirmation yet.

At the same time, I myself have a concern on the schema since it does not
extend any of the IODEF-related classes.
IODEF extension works usually extends extending IODEF ciass, so I wonder
whether the current schema of the enum draft is ok or not.

It could be that we cannot embed the ReferenceName element inside IODEF's
Reference class if we use the current schema.
I might be wrong, so confirmation would be appreciated.
One way I would think is extending the existing IODEF's Reference class.

Take

2014-08-19 2:27 GMT+09:00 Black, David <[email-masked]>:
> 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
>
>> -----Original Message-----
>> From: Adam W. Montville [mailto:[email-masked]]
>> Sent: Wednesday, August 06, 2014 11:00 AM
>> To: Black, David
>> Cc: Roman D. Danyliw; MILE IETF
>> Subject: Re: [mile] EnumRef Format to IODEF Extension Suggestion
>>
>>
>> On Aug 5, 2014, at 6:28 PM, Black, David <[email-masked]> wrote:
>>
>> > 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?
>>
>> 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
>> >
>> >
>> >> -----Original Message-----
>> >> 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!
>> >>
>> >>> -----Original Message-----
>> >>> 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
>> >>
>> >>>> -----Original Message-----
>> >>>> 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
>> >>>>
>> >>>> -----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
>> >>>>
>> >>>> _______________________________________________
>> >>>> mile mailing list
>> >>>> [email-masked]
>> >>>> https://www.ietf.org/mailman/listinfo/mile
>> >
>> > _______________________________________________
>> > mile mailing list
>> > [email-masked]
>> > https://www.ietf.org/mailman/listinfo/mile
>
> _______________________________________________
> mile mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mile

-- 
--
Takeshi Takahashi, Ph.D.
+81 80 3490 2971
http://www.taketaka.com/

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Wed, 22 Oct 2014 11:35:20 +0900

Ah, sorry, I have found the Apssdir review result against the v08 version.
http://www.ietf.org/mail-archive/web/mile/current/msg01522.html

My concern was also addressed there, so please ignore my previous email.
I am sorry for that.

Take

> From: Takeshi Takahashi [mailto:[email-masked]]
> Sent: Wednesday, October 22, 2014 10:57 AM
> To: [email-masked]'
> Cc: Adam W. Montville ([email-masked]); Black, David
> ([email-masked])
> would be a good idea.) I apologize my late response.
> 
> I can see several supportive comments on this draft change, and I can see
> no negative comments on this.
> >> 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,
> >> 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
> >
> >> >> 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:
> >> >
> >> > 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:
> >> >
> >> > [NB: I changed "ReferenceName" to "SpecReferenceName" with the
> >> > intent of enabling use of an unconstrained "ReferenceName" element
> >> > for other
> >> purposes.]
> >> >
> >> > 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.
> >> >
> >> 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
> >> >
> >> >
> >> >>> 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
> >> >> 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)".
> >> >>
> >> >> 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.
> >> >>
> >> >>> 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?
> >> >>
> >> >> 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 ]--
> >> >>>>
> >> >>>> MILE Working
> Group                                          A.
> >> >>>> Montville
> Internet-Draft
> >> >>>> Tripwire
> >> >>>>
> Obsoletes:
> >> >>>> D. Black Intended status: Standards
> Track
> >> >>>> EMC
> >> >>>> Expires: January 31, 2015
> >> >>>> August 2014
> >> >>>>
> >> >>>>   The IETF has been notified of intellectual property rights
> >> >>>> claimed in
> >> >>>>   and may be updated, replaced, or obsoleted by other documents
> >> >>>> at any
> >> >>>> Internet-Draft                IODEFv2 ENUM
> >> >>>> August 2014
> >> >>>>
> >> >>>>
> >> >>>>   extracted from this document must include Simplified BSD
> >> >>>> License text
> >> >>>>   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
> >> >>>> Internet-Draft                IODEFv2 ENUM
> >> >>>> August 2014
> >> >>>>
> >> >>>>
> >> >>>>   enumeration identified by the specIndex attribute.  The format
> >> >>>> of the
> >> >>>>   The corresponding information in the IANA table (see Section
> >> >>>> 4) would
> >> >>>>   include:
> >> >>>>
> >> >>>>   No change, but this should should be numbered 2.2 not 2.3 as
> >> >>>> in the
> >> >>>>   -07 draft.
> >> >>>>
> >> >>>> Internet-Draft                IODEFv2 ENUM
> >> >>>> August 2014
> >> >>>>
> >> >>>>
> >> >>>>   No change.
> >> >>>>
> >> >>>> 4.  IANA Considerations
> >> >>>>
> >> >>>>   Registration request for the IODEF enumeration reference
> >> >>>> format XML
> >> >>>>   schema:
> >> >>>>
> >> >>>> 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
> >> >>>>
> >> >>>>
> >> >>>> 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).
> >> >>>>