I have remarks to Gabe's remarks, but I add them to Watson's reply, so
the thread doesn't bifurcate.
On 10. 08. 20 10:22, Watson Sato wrote:
On Sat, Aug 8, 2020 at 12:10 AM Gabe Alford <redhatrises(a)gmail.com
<mailto:redhatrises@gmail.com>> wrote:
Anything that is metadata should conform to the Dublin Core per
the XCCDF specification for the .profile files, or it can be a
commented out section at the top of the .profile.
As the purpose is to record key properties of the profile, I am not in
favor of specifying them as comments - one can't parse them reliably,
and as we would like this to save us some work, we want to have at most
one schema that can be approached by computers.
Next, the schema presented by Watson reflects what we think is useful to
record. I wouldn't compromise here because of the Dublin thing. I
understand this as a resource for content authors, it could possibly be
inserted as a table into the profile description, and we could have a
test that key profiles have this record. Putting this info into profile
XCCDF metadata makes sense, but I wouldn't use this as a factor that
would restrict the data set that we would like to record.
I didn't envision this metadata to be included in the built XCCDF
profile, so I didn't look into the formal syntax.
And it is laid out as yaml to ease any eventual build system future
automation.
Alternatively, a single file like maintainers or profile
maintainers would be better as a single source of truth.
That could work too, in this case I would make the file per product,
to keep them simple.
I don't get the single source of truth thing -
wouldn't it be the
respective profile file? Typically, one is interested in who maintains a
particular profile, not in how many profiles one person maintains. But
more importantly, I think it is important to see who maintains the
profile when one edits the profile file, or when one reviews the change.
Having two files - one with the profile definition, and the other one
that may or may not contain information about possible profile
stakeholders - is cumbersome.
nitpick: I think that "comes_into_force" should be something else
like "when", "applicability", or
"profile_enforcement".
Thank you for the suggestions, I was not sure what would be a good
name for the field.
But this also makes me wonder if tracking this is even necessary
as technically in all compliance regimes a newly released profile
becomes applicable on release.
The core of this field is clarity and understanding how the policy is
applied in practice, if it is the case that all policies and profiles
are instantly unusable when a new version is released,
this field is unnecessary.
The proposal for "comes_into_force" assumed that the organizations
implementing and/or enforcing the policy don't update instantly, and
have a time frame to adapt.
I see this as a possibility to at least loosely define shape of profiles
- if a stakeholder claims that they expect the profile to be behind at
most six months, then comparison of a couple of numbers can quickly tell
us whether the profile is good, on track, or whether it was left behind.
Below is a draft proposal of a set of *optional* metadata to be added
to the ".profile" file. Everything is pretty much free form and optional.
* policy_hub: (URL pointing to page or organization that publishes
the policy)
* version: (version of the policy implemented)
* comes_into_force: (text stating when a policy starts being
enforced, in other words, when a policy version is in practice
obsolete)
* maintainers: (contact of policy SME, stakeholder, or person
responsible for the profile, can be in form of GitHub handle for
example)
I see an issue with maintainers - we can mix up at least GH usernames
and e-mails - what about considering it a list of dicts, so we could
have e.g.
maintainers:
- github: redhatrises
- github: yuumasato
email: wsato(a)redhat.com
On Fri, Aug 7, 2020 at 9:21 AM Watson Sato <wsato(a)redhat.com
<mailto:wsato@redhat.com>> wrote:
...