Subject: [mile] Should IODEF Enumeration Reference Format update 5070?

From: "Adam W. Montville" <[email-masked]>
Date: Mon, 10 Nov 2014 17:15:26 -0600

As David presented during today’s session at IETF 91, the latest submission of IODEF Enumeration Reference Format still indicates that it will update RFC 5070.  The IODEF Enumeration Reference Format has already been picked up in 5070bis.  

Open Question:  Are there any objections to modifying IODEF Enumeration Reference Format, such that it does NOT update 5070?

Please respond within 2 weeks (by November 24th).

Regards,

Adam

---

From: Eric Burger <[email-masked]>
Date: Tue, 11 Nov 2014 10:41:34 -0500

It depends on publication timing. Think of what you are saying - “I do not want to say Enum Format updates 5070, because 5070bis incorporates Enum Format and 5070bis replaces 5070.” That is the same as saying “I do not need to bother publishing Enum Format, because 5070bis incorporates it and it will be out soon.”

So, if we are going to publish the IODEF Enumeration Reference Format before 5070bis, then we need to have it update 5070. This is important so that someone implementing IODEF will know to look to the Enum Format document, because it will be listed on the RFC Editor site. If we are going to publish IODEF Enumeration Reference Format at about the same time or after 5070bis, then this document is an unnecessary distraction and should be off the agenda altogether.

On Nov 10, 2014, at 6:15 PM, Adam W. Montville <[email-masked]> wrote:

> _______________________________________________
> mile mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mile

---

From: "Adam W. Montville" <[email-masked]>
Date: Tue, 11 Nov 2014 10:56:24 -0600

> On Nov 11, 2014, at 9:41 AM, Eric Burger <[email-masked]> wrote:
> 

Is it?  In the 5070bis (-10) the Method class aggregates enum:Reference and points to the IODEF Enumeration Reference Format draft.  I agree that 5070bis incorporates Enum Format, but it does so by reference not by inclusion.

---

From: Eric Burger <[email-masked]>
Date: Tue, 11 Nov 2014 12:13:30 -0500

> Is it?  In the 5070bis (-10) the Method class aggregates enum:Reference and points to the IODEF Enumeration Reference Format draft.  I agree that 5070bis incorporates Enum Format, but it does so by…

That’s what I thought, but when I looked at the 5070bis draft, I could not find it. I just looked again, and did find it. So first off, I stand corrected. Thanks for pointing that out.

As for going forward, is there any reason not to just fold Enum Format into 5070bis? My inclination is to say that if we want current, 5070-based implementations to use the format, then the format must update 5070. Otherwise, no one besides us will know the format exists and we will not have interoperability.

---

From: "Adam W. Montville" <[email-masked]>
Date: Tue, 11 Nov 2014 11:25:33 -0600

> On Nov 11, 2014, at 11:13 AM, Eric Burger <[email-masked]> wrote:
> 
> 
> On Nov 11, 2014, at 11:56 AM, Adam W. Montville <[email-masked] <mailto:[email-masked]>> wrote:
> 
>>> 
>>> On Nov 11, 2014, at 9:41 AM, Eric Burger <[email-masked] <mailto:[email-masked]>> wrote:
>>> 

No problem.  I stand corrected more often than not, so this marks a rare occasion. ;-)

> As for going forward, is there any reason not to just fold Enum Format into 5070bis? My inclination is to say that if we want current, 5070-based implementations to use the format, then the format…

There is at least one reason I can think of: We are likely to leverage the Enum Format in other work, specifically SACM.  At least I can see it being useful there (others have as well, but I’ll not speak on their behalf).  

I agree with your observation, though.  If we want current implementations to understand the format, then we’re going to have to update 5070, which is the purpose of the line of questioning.  On the other hand, we might reasonably want 5070-based implementations to rev and be 5070bis-based, in which case the lack of interoperability might act as a forcing function to adopt 5070-bis in the field sooner rather than later.

>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/mile <https://www.ietf.org/mailman/listinfo/mile>

---

From: "Black, David" <[email-masked]>
Date: Tue, 11 Nov 2014 17:27:04 +0000

> As for going forward, is there any reason not to just fold Enum Format into 5070bis?

Good question - thanks for asking.

Yes, there is a reason to keep it separate - based on discussion in Toronto and before, this separate small schema should have value for reference format standardization beyond IODEFv2.  That's a major reason why this draft now defines its own XML schema instead of modifying an IODEF XML schema.

Thanks, --David +++Sent from Blackberry

---

From: Eric Burger <[email-masked]>
Date: Tue, 11 Nov 2014 14:09:10 -0500

The two are separable. If Enum Format needs to be its own document, it should be published. Moreover, if it updates 5070, it should say so. Just because one document updates another does not mean that document is tied to the old document. See, e.g., RFC3459.

---

From: "Black, David" <[email-masked]>
Date: Tue, 11 Nov 2014 19:34:10 +0000

> The two are separable. If Enum Format needs to be its own document, it should be published.

I agree.

> Moreover, if it updates 5070, it should say so.

The sense of the room in Honolulu (as I understood it) was that it should
not update 5070, and this is consistent with prior discussion on the list:

http://www.ietf.org/mail-archive/web/mile/current/msg01510.html

An update to 5070 would most likely involve a new version of the IODEF
XML schema (v1.00 -> v1.01) shortly before the publication of the 5070-bis
draft, which defines an IODEF v2 schema (particularly as the IODEF v1
extension mechanism is being deprecated by IODEF v2).  That v1.01 version
might not be a good idea if the goal is to encourage migration to IODEF v2.

Thanks,
--David

From: mile [mailto:[email-masked]] On Behalf Of Eric Burger
Sent: Tuesday, November 11, 2014 2:09 PM
To: Adam W. Montville
Cc: MILE IETF
Subject: Re: [mile] Should IODEF Enumeration Reference Format update 5070?

On Nov 11, 2014, at 12:25 PM, Adam W. Montville <[email-masked]<mailto:[email-masked]>> wrote:

There is at least one reason I can think of: We are likely to leverage the Enum Format in other work, specifically SACM.  At least I can see it being useful there (others have as well, but I'll not speak on their behalf).

I agree with your observation, though.  If we want current implementations to understand the format, then we're going to have to update 5070, which is the purpose of the line of questioning.  On the other hand, we might reasonably want 5070-based implementations to rev and be 5070bis-based, in which case the lack of interoperability might act as a forcing function to adopt 5070-bis in the field sooner rather than later.

---

From: Eric Burger <[email-masked]>
Date: Tue, 11 Nov 2014 14:47:21 -0500

I would buy that IIF the wheels are in motion to move 5070 to Historic. Chairs?

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Wed, 12 Nov 2014 05:51:29 +0900

Hi all,

Let me comment as an individual.

> The overall sense in the room was that this would NOT be a good idea and
would cause unnecessary work.

That was the understanding I have got during the session yesterday too.
I also have the same opinion since IODEFv2 is anyway not backward compatible
any more.

> IIF the wheels are in motion to move 5070 to Historic. Chairs?

In a sense, yes, but IMHO we need to consider some guideline that could
convert IODEFv1 to v2 and vice versa.
It could be done inside the guideline document or somewhere else.
(It would be the best if we have some xslt or the likes that can be used as
a conversion too.)
Since the number of organizations that use IODEF is not that much at this
moment, I guess we should treasure the current users of IODEFv1 so that we
do not discourage the use of IODEF.
That could help the migration from IODEF v1 to IODEF v2 as well.

Kind regards,
Take

From: mile [mailto:[email-masked]] On Behalf Of Eric Burger
Sent: Wednesday, November 12, 2014 4:47 AM
To: MILE IETF
Subject: Re: [mile] Should IODEF Enumeration Reference Format update 5070?

I would buy that IIF the wheels are in motion to move 5070 to Historic.
Chairs?

 
I agree.

 

Thanks,
--David

The two are separable. If Enum Format needs to be its own document, it
should be published. Moreover, if it updates 5070, it should say so. Just
because one document updates another does not mean that document is tied to
the old document. See, e.g., RFC3459.

On Nov 11, 2014, at 12:25 PM, Adam W. Montville <[email-masked]>
wrote:

As for going forward, is there any reason not to just fold Enum Format into
5070bis? My inclination is to say that if we want current, 5070-based
implementations to use the format, then the format must update 5070.
Otherwise, no one besides us will know the format exists and we will not
have interoperability.
 
There is at least one reason I can think of: We are likely to leverage the
Enum Format in other work, specifically SACM.  At least I can see it being
useful there (others have as well, but I’ll not speak on their behalf).  
 
I agree with your observation, though.  If we want current implementations
to understand the format, then we’re going to have to update 5070, which is
the purpose of the line of questioning.  On the other hand, we might
reasonably want 5070-based implementations to rev and be 5070bis-based, in
which case the lack of interoperability might act as a forcing function to
adopt 5070-bis in the field sooner rather than later.

---

From: Eric Burger <[email-masked]>
Date: Tue, 11 Nov 2014 16:33:26 -0500

Saying there are not many people using IODEF means it should be easy to declare the experiment (v1) a success, deprecate it, and publish the markup to use (v2). People entering the market today will implement IODEF v1 because it is the only standard out there (not counting STIX, OpenIOC, NMSG, et al.). Making it clear they should do v2 will avoid what we lived with in SIP (and a host of other protocols) where we perpetually said, “We cannot fix this fatal flaw because too many people depend on it.” Guess what - now those protocols are moribund because they have fatal flaws.

On Nov 11, 2014, at 3:51 PM, Takeshi Takahashi <[email-masked]> wrote:

> should be published.