Extend scs-0003: more context and process (resolves issues/#343)

[mbuechse]

• added lots of context in the introduction
• introduced the distinction between "certificate" and "certificate type"
• improved misleading wording in the motivation
• rectified incorrect section levels
• added process description (governance)

[garloff]

/lgtm
Thanks @mbuechse

[mbuechse]

@alexander-diab This PR is good to be merged; Kurt is satisfied, apparently highly so. Do you have any objections?

[anjastrunk]

Isn't this of type Procedural and not of Decision Record?

Suggested change

	This decision record establishes a mechanism (by means of the YAML file) with the following three main objectives:
	This standard establishes a mechanism (by means of the YAML file) with the following three main objectives:

[mbuechse]

The verbiage in question didn't stem from me. Anyway, following your argumentation, we should change "decision record" into "procedural", right? However, I suppose "decision record" could be construed as a kind of general term (a superset) that includes Standards, Procedurals, and any other document. From this point of view, every standard is a decision record, but not every decision record is a standard. If we expressly designate a document as "decision record" in the header, then this mostly means that it doesn't fit into any of the subcategories. Just one way of looking at it.

[anjastrunk]

Regarding yaml file:

Do we have one yaml file with all layers and levels at the end, or one yaml file per level and layer, such as SCS-compatible-IaaS.yaml for layer IaaS and level "SCS-compatible"

I prefer the second option, as one file may be grow over time and gets confusting. We may even think to have one file or each version, such as SCS-compatible-IaaS-v1.yaml for version 1 of layer "SCS-compatible" certificate for IaaS.

[mbuechse]

Regarding yaml file:

Do we have one yaml file with all layers and levels at the end, or one yaml file per level and layer, such as SCS-compatible-IaaS.yaml for layer IaaS and level "SCS-compatible"

Currently, it's one file per level, containing both layers. I would prefer one file per type of certificate, that is to say, one file per combination of level and layer. But this has been an open topic in the SIG for months now.

@anjastrunk see here: https://input.scs.community/2023-scs-sig-standardization#2023-06-29
I'm pretty sure that I had raised the matter even earlier, but it got postponed at least once, and even when it got discussed, it was postponed again.

[anjastrunk]

I like your improvements. It makes thing clearer.

One question, which came to may mind: Is there already a standard for receiving a certificate as CSP? I mean, how das a CSP apply for a certificate, how often will a re-certification take place and what are the consequences if certificate rules are violated?

[mbuechse]

One question, which came to may mind: Is there already a standard for receiving a certificate as CSP? I mean, how das a CSP apply for a certificate, how often will a re-certification take place and what are the consequences if certificate rules are violated?

@anjastrunk Something like that is being worked on in #337

[anjastrunk]

Regarding yaml file:
Do we have one yaml file with all layers and levels at the end, or one yaml file per level and layer, such as SCS-compatible-IaaS.yaml for layer IaaS and level "SCS-compatible"

Currently, it's one file per level, containing both layers. I would prefer one file per type of certificate, that is to say, one file per combination of level and layer. But this has been an open topic in the SIG for months now.

@anjastrunk see here: https://input.scs.community/2023-scs-sig-standardization#2023-06-29 I'm pretty sure that I had raised the matter even earlier, but it got postponed at least once, and even when it got discussed, it was postponed again.

We should but this on next SIG' agenda and make a decision!

[anjastrunk]

One question, which came to may mind: Is there already a standard for receiving a certificate as CSP? I mean, how das a CSP apply for a certificate, how often will a re-certification take place and what are the consequences if certificate rules are violated?

@anjastrunk Something like that is being worked on in #337

Yes. Thanks.

[mbuechse]

We should put this on next SIG' agenda and make a decision!

I prepared the agenda accordingly.

[alexander-diab]

I currently work on this. I have created a section on the docs page explaining the "certification" topic. There will be one section called "How to get certified". I will discuss this with Kurt tomorrow afternoon. And then write it up in this section. But it will be simply:
0. Download the compliance check tool and test your stack. Once you feel ready.

1. Write an email to the SCS team and ask for being certified.
2. You will be asked to give access to your stack for the SCS team to execute the compliance check tool (and this is to be automated).
3. You must agree to be listed on the docs page with the result of the compliance check tool published and updated each night.
4. You are certfied!