Add language for compliance requirements around platforms and architectures

Signed-off-by: Mrunal Patel <[email protected]>

Author: mrunalp

README.md

@@ -24,8 +24,13 @@ Table of Contents
 
 In the specifications in the above table of contents, the keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC 2119](http://tools.ietf.org/html/rfc2119) (Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997).
 
-An implementation is not compliant if it fails to satisfy one or more of the MUST or REQUIRED requirements for the protocols it implements.
-An implementation that satisfies all the MUST or REQUIRED and all the SHOULD requirements for its protocols is said to be "unconditionally compliant".
+An implementation is not compliant for a given CPU architecture if it fails to satisfy one or more of the MUST or REQUIRED requirements for the protocols it implements.
+An implementation is compliant for a given CPU architecture if it satisfies all the MUST and REQUIRED requirements for the protocols it implements.
+An implementation that satisfies all the MUST or REQUIRED and all the SHOULD requirements for its protocols on a given CPU architecture is said to be "unconditionally compliant" with those protocols and architectures.
+
+Protocols defined by this specification are:
+* Linux containers: [runtime.md](runtime.md), [config.md](config.md), [config-linux.md](config-linux.md), and [runtime-linux.md](runtime-linux.md).
+* Solaris containers: [runtime.md](runtime.md), [config.md](config.md), and [config-solaris.md](config-solaris.md).
 
 # Use Cases