OASIS Energy Interoperation TCIcon indicating the project type

OASIS Energy Interoperation TC

Uploaded image for project: 'OASIS Energy Interoperation TC'
  1. OASIS Energy Interoperation TC
  2. ENERGYINTEROP-287 644: ISO's need to comply with NERC CIP, which should be clear in the example
  3. ENERGYINTEROP-288

715: Information classification for NERC CIP is in-scope for the IRC

    Details

    • Type: Sub-task
    • Status: Closed
    • Priority: Critical
    • Resolution: Fixed
    • Affects Version/s: csd01 - Public Review Draft
    • Fix Version/s: wd25
    • Component/s: spec
    • Labels:
      None
    • Proposal:
      Hide

      Accept recommendations

      Show
      Accept recommendations
    • Resolution:
      Hide

      Accept recommendations. See ENERGYINTEROP-287.

      Include an optional attribute (cardinality [0..1]) in each message. The definition will mirror the IRC proposal, i.e., three topics, and high medium or low for each.

      Show
      Accept recommendations. See ENERGYINTEROP-287 . Include an optional attribute (cardinality [0..1] ) in each message. The definition will mirror the IRC proposal, i.e., three topics, and high medium or low for each.

      Description

      The IRC Information Model describes a suggested way to classify information for each of the XML Schemas for the 35 Demand Response Interactions.

        Attachments

          Activity

          Ascending order - Click to sort in descending order
          Hide
          Permalink
          david.holmberg David Holmberg (Inactive) added a comment -

          Toby talk to Edgardo to discuss best resolution. Perhaps including NERC CIPs in an example would help.

          Show
          david.holmberg David Holmberg (Inactive) added a comment - Toby talk to Edgardo to discuss best resolution. Perhaps including NERC CIPs in an example would help.
          Hide
          Permalink
          william.cox William Cox (Inactive) added a comment - - edited

          The information structure correctly describes the information classification for NERC CIP, but including the "value" of the message in the message seems to increase risk by flagging more valuable messages. (From discussion with CSWG members)

          This would be a useful "deployment descriptor", rather than a message component.

          This seems to be relevant information in deciding what security/reliability to compose for specific types of interactions.

          Show
          william.cox William Cox (Inactive) added a comment - - edited The information structure correctly describes the information classification for NERC CIP, but including the "value" of the message in the message seems to increase risk by flagging more valuable messages. (From discussion with CSWG members) This would be a useful "deployment descriptor", rather than a message component. This seems to be relevant information in deciding what security/reliability to compose for specific types of interactions.
          Hide
          Permalink
          edgardo.luzcando Edgardo Luzcando (Inactive) added a comment -

          I am open to suggestions in how to best manage this according to the CSWG. The IRC suggestion is to include a the CIA (Confidentiality, Integrity, and Availability) for each interaction with a high,medium, low. However, I thought that these would be optional in any interaction. Would that satisfy the concern about including the "value"? I understand that calling out this information within an interaction might increase risk, but there is the risk that the same information with no "values" (or labels) can be exposed because its information classification is not understood. As long at EI addresses the NERC-CIP requirement somehow, the IRC's requirements should be satisfied.

          Show
          edgardo.luzcando Edgardo Luzcando (Inactive) added a comment - I am open to suggestions in how to best manage this according to the CSWG. The IRC suggestion is to include a the CIA (Confidentiality, Integrity, and Availability) for each interaction with a high,medium, low. However, I thought that these would be optional in any interaction. Would that satisfy the concern about including the "value"? I understand that calling out this information within an interaction might increase risk, but there is the risk that the same information with no "values" (or labels) can be exposed because its information classification is not understood. As long at EI addresses the NERC-CIP requirement somehow, the IRC's requirements should be satisfied.
          Hide
          Permalink
          william.cox William Cox (Inactive) added a comment -

          I've tried to address this in the resolution for the parent task, ENERGYINTEROP-287, by having a reference to a message type to which the NERC-CIP levels would apply. I think that this satisfies the IRC issue, but better to look at the proposed implementation when its complete.

          Show
          william.cox William Cox (Inactive) added a comment - I've tried to address this in the resolution for the parent task, ENERGYINTEROP-287 , by having a reference to a message type to which the NERC-CIP levels would apply. I think that this satisfies the IRC issue, but better to look at the proposed implementation when its complete.
          Hide
          Permalink
          toby.considine Toby Considine (Inactive) added a comment -

          No change recommended during meeting

          Show
          toby.considine Toby Considine (Inactive) added a comment - No change recommended during meeting
          Hide
          Permalink
          toby.considine Toby Considine (Inactive) added a comment -

          As voted in meeting

          Show
          toby.considine Toby Considine (Inactive) added a comment - As voted in meeting

            People

            • Assignee:
              edgardo.luzcando Edgardo Luzcando (Inactive)
              Reporter:
              edgardo.luzcando Edgardo Luzcando (Inactive)
            • Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: