Repository navigation
Replace Utility with Automatable in Deployer Tree #238
Description
Activity
feature/fix_238 has work in progress.
So far I've updated the generator script and the CSV file.
The new csv file is /data/csvs/deployer-options_v2_1.csv
In creating the new CSV, I used the following logic to choose the priority decision:
- If
v2.Utility == laboriousthenv2_1.Automatable = no(36 leaf nodes) - If
v2.Utility == super effectivethenv2_1.Automatable = yes(36 leaf nodes) - If
v2.Utility == efficientthen drop the row from the table (36 leaf nodes)
Note that this is consistent with the logic of Utility in version 2.0. This method seemed to retain as much information as possible from the v2 tree (108 leaf nodes) into the smaller v2.1 tree (72 leaf nodes).
I have made no attempt to adjust any priorities from what they would have been in the v2 deployer tree.
Because the remaining changes to the
.jsonand.texfiles are derived from the.csv, we should to decide if the CSV is sufficient as-is before proceeding with further modifications. I'm comfortable with that, but comments are hereby encouraged.- If
On second thought, the
.tex(and subsequent.pdf) changes were easy enough, so they're in the feature/fix_238 branch now too.Once we decide to proceed, I'll most likely need to hand this issue off to @sei-vsarvepalli for the necessary
.jsonchanges.- So the child_tree for
Human Impactremains as-is, is that correct?
https://github.com/CERTCC/SSVC/blob/feature/fix_238/data/csvs/child_trees/human-impact_v2.csv
- Does the
Utilitychild tree still exists? or is it only to support deployer v2 situations ?
https://github.com/CERTCC/SSVC/blob/feature/fix_238/data/csvs/child_trees/utility_v2.csv
- Deployer version currently is 2.0.0 using semantic like versioning. Should we bump that to 2.1.0 ?
- So the child_tree for
I have made the necessary changes and pushed it to the feature/fix_238 branch . The calculator with the new Deployer Tree versioned 2.1.0 is at https://certcc.github.io/SSVC/ssvc-calc/ ready for testing/review. It has the 72 decisions and 103 nodes that seem to resemble what was generated as PDF.
However..
I think there is still a bit of referencing of Utility and Value Density in various places that need to be reviewed and updated as it relates to Deployer tree. Like in
./doc/md_src_files/080_workedExample.mdand in./doc/ssvc_v2-0.html. We should probably move all the older Deployer tree to anarchivefolder so it is not confusing.Vijay
Noting necessity to
- change the logic example at the beginning of Prioritization since it specifically refers to the deployer tree.
- fix
080_worked_example.md
I think there is still a bit of referencing of Utility and Value Density in various places that need to be reviewed and updated as it relates to Deployer tree. Like in
./doc/md_src_files/080_workedExample.mdand in./doc/ssvc_v2-0.html.Since the ssvc_v2-0.html file is generated from the markdown, we should focus on fixing the markdown and the html will eventually be taken care of when it's regenerated.
We should probably move all the older Deployer tree to an
archivefolder so it is not confusing.I deleted the
deployer-options_v2.csvin this branch because we don't seem to have preserved previous versions as commits move on. The repository itself serves as a sufficient (IMO) archive of previous versions, so we can always go to the tagged 2.0 or 1.0 releases to retrieve the.csvor.jsonfiles from their respective versions. I don't think it's necessary to maintain an archive folder too, it just seems like extra version control and I'm ok with just letting git be git and leave the obsolete versions accessible via the commit history.This does raise the side issue of whether we should be including version numbers in file names at all though -- because traceability of the git history could get wonky over time if every new version of a file has a different file name. I'll create a separate issue for that though.
I agree that (#246 aside) the git repository is an adequate version history of file changes. It will be important to determine how folks are recommended to provide a stable reference / link to whatever version of a suggested tree they worked from / are using. But git already provides that technical capability. We can refine semantic versioning norms in #246.
2. Does the
Utilitychild tree still exists? or is it only to support deployer v2 situations ?Utility is still a composite decision point anywhere that it gets used.
I have made no attempt to adjust any priorities from what they would have been in the v2 deployer tree.
The logic here makes sense. If we want to review the recommended actions for the tree, that should be a separate issue, anyway. So I think this is a fine way to solve the issue at hand.
See Discussion #221 for background discussion.
The change is to replace Utility in the Deployer Tree with Automatable.
This will require updates to at least: