[ReadMe] Just one level/tier of compliance

[RobDolinMS]

Per discussions among the OCI TB Certification Program WG, including at June 2016 and August 2016 face-to-face meetings, updating the compliance language so there is only one level or tier of compliance.

Signed-off-by: Rob Dolin robdolin@microsoft.com

[wking]

Is there a reason to ignore the SHOULDs? Not that we have many of those at the moment.

[RobDolinMS]

@wking I did a quick count of each of the compliance terms (in both Runtime-spec and Image-spec) and there are relatively few instances of SHOULD. Once instances of SHOULD are replaced, the count will be near zero.

There was also discussion on this at the Certification Program WG (most recently at F2F on Mon, 8/22) and the desire is to minimize complexity.

[wking]

On Fri, Aug 26, 2016 at 01:23:15PM -0700, Rob Dolin (MSFT) wrote:

@wking I did a quick count of each of the compliance terms (in both
Runtime-spec and Image-spec) and there are relatively few instances
of SHOULD. Once instances of SHOULD are replaced, the count will be
near zero.

What are we replacing the SHOULDs with? For example 1:

Bundles SHOULD use, and runtimes SHOULD understand, os entries
listed in the Go Language document for $GOOS.

Is that going to change to MUST (so configurations using non-GOOS
values would be invalid)? Or is it going to change to an informative
(non-normative) line that has no teeth? Or are we going to drop the
line?

There was also discussion on this at the Certification Program WG
(most recently at F2F on Mon, 8/22) and the desire is to minimize
complexity.

I think there are places where we do want to recommend—but not
require—some behavior, and that's what the SHOULD level is for. I
think we do want to acknowledge a difference between MUST-level and
MUST+SHOULD-level compliance. The first rounds of validation tooling
should obviously focus on covering the MUST cases, but once we've
finished that up I see no reason to not also cover the SHOULD cases.

On the other hand, we'd certainly have a smaller spec if we stripped
it down to MUSTs. I'm ok with trying that and building it back out if
it turns out to be too sparse ;). But I think the change should be
“drop ‘unconditionally compliant’ and all the SHOULD and MAY
wording. Dropping “unconditionally complaint” while keeping the
SHOULD and MAY wording just makes it harder to talk about MUST+SHOULD
compliance.

[RobDolinMS]

@wking - This PR does not preclude spec authors from using SHOULD in cases where they want something stronger than MAY or OPTIONAL. However, this makes it clear which clauses are REQUIRED for certification and which are OPTIONAL.

[wking]

On Mon, Aug 29, 2016 at 01:50:39PM -0700, Rob Dolin (MSFT) wrote:

@wking - This PR does not preclude spec authors from using SHOULD in
cases where they want something stronger than MAY or OPTIONAL.

It just means that those SHOULD-level statements are meaningless from
a certification standpoint ;). I'd rather keep the certification
component.

However, this makes it clear which clauses are REQUIRED for
certification and which are OPTIONAL.

It was already mostly clear, and is more so now that #527 has landed
with 1 and the later two lines, which explicitly define “not
compliant”, “compliant”, and “unconditionally compliant”.

[polvi]

LGTM

[crosbymichael]

LGTM

[mrunalp]

Needs rebase

[RobDolinMS]

Thanks @mrunalp. I have rebased as #553