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.


  tc
From:  Dave Lemire <>
  Sent:  Friday, September 14, 2018 2:01 PM
To:  Considine, Toby <>
Cc:  OASIS OpenC2 List <>
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:  
Office: 301-575-5190 /
Mobile: 240-938-9350

On Fri, Sep 14, 2018 at 12:01 PM Considine, Toby < 
> 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