Subject: [mile] IODEF Reference Format for Enumerations

From: Adam Montville <[email-masked]>
Date: Wed, 1 Aug 2012 18:33:00 +0000

Hello everyone,

During yesterday's mile meeting we started several options with respect to
referencing external enumeration - a topic that has been discussed on the
list previously.  I believe, but could be wrong, that the discussion we
had yesterday implicitly eliminates the first option, which leaves the
second and third options from which to choose.  I also believe that the
previous discussion on the list went toward option two.

Keeping in mind that the SCI draft is essentially stuck until this
referential issue is sorted out, I would like to propose that we move
forward with the second option or continue this discussion to drive to the
appropriate conclusion on relatively short order.  Choosing option two now
would preclude "opening" IODEF.

Here are the options again:

Option 1: Simple ID
===================
The first option would simply embed the relevant identifier in the
ReferenceName element of the Reference class.  This may look like the
following:

    <Reference>
        <ReferenceName>id</ReferenceName>
        <URL>http://www.example.com/path</URL>
<http://www.example.com/path%3C/URL%3E>
        <URL>http://www.otherexample.com/path</URL>
<http://www.otherexample.com/path%3C/URL%3E>
        <Description>Description</Description>
    </Reference>

Using this option, a variety of specific identifier formats could be
specified.  CVE, for example, would start with "CVE-" and this convention
may be registered in an IANA table.

No changes to IODEF are required for this option.

Option 2: ID with coupled ID type
=================================
The second option would prepend the identifier with it's type, which may
look something like the following.

    <Reference>
        <ReferenceName>id_type:id</ReferenceName>
        <URL>http://www.example.com/path</URL>
<http://www.example.com/path%3C/URL%3E>
        <URL>http://www.otherexample.com/path</URL>
<http://www.otherexample.com/path%3C/URL%3E>
        <Description>Description</Description>
    </Reference>

Using this option, a variety of specific identifier types could be
specified, such that the identifier itself would not necessarily be
constrained, nor would new identifier formats necessarily need to be
specified in the future.  An IANA table may be used for this solution as
well.

No changes to IODEF would be required for this option.

Option 3: ID with type expressed in Reference attribute
=======================================================
The third option would require opening IODEF to update the Reference class
with an attribute, which may look something like the following.

    <Reference registryId="id_type">
        <ReferenceName>id</ReferenceName>
        <URL>http://www.example.com/path</URL>
<http://www.example.com/path%3C/URL%3E>
        <URL>http://www.otherexample.com/path</URL>
<http://www.otherexample.com/path%3C/URL%3E>
        <Description>Description</Description>
    </Reference>

Changes to IODEF are required for this option.

Regards,

Adam

---

From: <[email-masked]>
Date: Wed, 1 Aug 2012 21:34:38 -0400

Adam,

I have one small addition from the mile meeting yesterday:

There was a debate about whether to require one of the URIs in whatever
option is chosen to refer to the spec that the identifier came from.

The clear conclusion from the meeting was to thoroughly rubbish and
discard that idea ... and as the original proposer of that idea,
I'm fine with that outcome ;-).

Thanks,
--David

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam
> Montville
> Sent: Wednesday, August 01, 2012 2:33 PM
> To: [email-masked]
> Subject: [mile] IODEF Reference Format for Enumerations
> 
> Hello everyone,
> 
> _______________________________________________
> mile mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mile

---

From: Adam Montville <[email-masked]>
Date: Thu, 2 Aug 2012 15:58:11 +0000

Thanks for that clarification, David.

Are there any opposed to moving forward with the second option?

Regards,

Adam