Uploaded image for project: 'OASIS Common Security Advisory Framework (CSAF) TC'
  1. OASIS Common Security Advisory Framework (CSAF) TC
  2. CSAF-27

non-substantial enhancement - note ordering requirements solely on the containers and not on the contained

    XMLWordPrintable

    Details

    • Type: Task
    • Status: Applied
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Proposal:
      Hide

      We should as a non-substantial change (in an upcoming WD02) move all ordering constraints solely to the sections of the container elements and strip the ever so clunky ordering statements from the contained element requirements.

      Show
      We should as a non-substantial change (in an upcoming WD02) move all ordering constraints solely to the sections of the container elements and strip the ever so clunky ordering statements from the contained element requirements.

      Description

      We should as a non-substantial change (in an upcoming WD02) move all ordering constraints solely to the sections of the container elements and strip the ever so clunky ordering statements from the contained element requirements.

      Especially since we have so many optional elements this does not help the reader at all but only doubles on statement volume without adding further precision, but instead adding the risk of inconsistencies or hardly parseable statements.

      Besides the formal "service to the reader" and "optimal base selection for describing" there is another rationale (which for the reporter is of utmost importance among the three): Going format agnostic from an implementation specific model almost always has not one but two required steps to succeed before one can add "another" format:

      1. Extract the data model A from the specifics

      2. Triage the now domain specific implementation agnostic model A into:

      2.1 A.1 core requirements and rules

      2.2 A.2 possibly real domain requirements that are representable / enforceable only by some of the considered implementation formats

      2.3 A.3 ballast from overshoot "because we could with format A" do things like that

      Based on this refactoring and triage efforts, with the three buckets then we can (as the suggested processing model):

      1. Toss any A.3 (or move to requirements on conforming implementation of the applicable formats i.e. A.2) or maybe pull parts upstream into the general reqs A.1

      2. Keep and further straighten the (resulting) requirements in A.1 maybe with the freshened set, some get pushed (partially) down into A.2 ...

      3. Spend presumably some real work cycles on processing the (resulting) requirements from bucket A.2 to find the best fit place guided by the 2x2 matrix spanned by the dimensions cardinality(zero, one, more) and applicability(formats)

      Note: As important discussions off the CVSS v3 - "to enforce or not in v1.2" - question may deserve some time, and the editor has no practical opinion in this discussion plus the outcome of the discussion can easily be applied to the document, ... the reporting editor will use the time waiting for a settlement, to:

      Prepare a variant of the CSD01 WD01 containing the results of the step decoupling intra-container ordering requirements from the "my place among my siblings" statements of the contained elements.

      Thinking of JSON objects as possible containers with uniquely keyed members only - these container ordering statements are best isolated, as they mostly "smell" like A.3 candidates for above triage ...

        Attachments

          Activity

            People

            • Assignee:
              sdrees Stefan Hagen
              Reporter:
              sdrees Stefan Hagen
            • Watchers:
              1 Start watching this issue

              Dates

              • Due:
                Created:
                Updated:
                Resolved: