RE: [openc2] SPLF CSD and Dates

I should have been more clear when I sent this inâor waited days to do so. I am fully supportive of the CSD being released.

This is a CSD, presumably about to receive public comments. This should be considered one of them

The TC can opt for each comment what to do:

Accept and Edit
Accept but opt for consideration at a later time
Give consideration and opt no change
Laugh and attempt to come up with a polite reply

This should not be a barrier to proceeding to public review. Or even, after that proceeding to a CS.

I sent it today, because I have extra time today, due to the business disturbance dur to the hurricane. If I had been eligible to vote, I would have voted for a CSD.

From: Dave Lemire <dave.lemire@g2-inc.com>
Sent: Friday, September 14, 2018 2:01 PM
To: Considine, Toby <Toby.Considine@unc.edu>
Cc: OASIS OpenC2 List <openc2@lists.oasis-open.org>
Subject: Re: [openc2] SPLF CSD and Dates

Toby,

Two questions:

1) how aligned / mis-aligned are the start / stop / duration parameters in the SLFP from what's in WS-Calendar (since I don't really have time at present to read up on the latter)?

2) Can this be left as a post-1.0 enhancement to our specifications? (AKA, not a show stopper).

Dave

David P. Lemire, CISSP
OpenC2 Technical Committee Executive Secretary
OpenC2 Implementation Considerations SC Co-chair
Contractor support to NSA
Email: dave.lemire@g2-inc.com
Office: 301-575-5190 / Mobile: 240-938-9350

On Fri, Sep 14, 2018 at 12:01 PM Considine, Toby <Toby.Considine@unc.edu> wrote:

New member here, not here long enough to be able to drop comments on the GoogleDocsâ.of the excellent CSD for Stateless Packet Filtering

I have a comment on dates and the use of dates and schedules.

An event, of course is characterized by a beginning, a duration, and an ending. Pick any two and you can compute the third. This is all defined in SPLF in a manner that is almost but not the same as in WS-Calendar. As we plunge deeper into events, we are likely to get recurring patterns of eventsâperhaps in a future version of OpenC2.

As a cartoon, imagine the deny outgoing FTP command illustrated in the appendix being a rule for ânon-business hoursâ, with a complementary rule for business hours. These recurring patterns are defined in the RFC for vAvailability, profiled for M2M use as Availability in WS-Calendar. There is a complement âunavailabiltyâ, as well as rules to overlay them (a holiday weekend, or from here in the Carolinas, temporary disruptions of the business cycle). These are complimented during discovery to include willingness to perform a service as well as the pattern of requesting the service.

I recommend that the the time/date portions of the Command Arguments (start-time, end-time, duration) and the associated processing rules be reviewed for alignment with OASIS WS-Calendar PIM (http://docs.oasis-open.org/ws-calendar/ws-calendar-pim/v1.0/ws-calendar-pim-v1.0.html)

WS-Calendar compatibility is even more useful as cybersecurity directives extend to Industrial Control Systems. Sponsors of this effort have strong parallel efforts in cybersecurity for ICS, (CI2P, et al.) and it would be good for these to be able to align. WS-Calendar conformance is included in new ASHRAE standards for Facilities Control as well as in standards for bringing distributed energy (power) logistics under IT control.

In particular, we should anticipate that future versions of this specification may include the Availability object, with overlays and templates, as addenda to the start/end/duration parameters.

tc

openc2 message