Nits

Signed-off-by: Andrei Warkentin <andrei.warkentin@intel.com>

acpi-id.adoc

@@ -7,7 +7,7 @@ devices, that do not have a standard enumeration mechanism. The ACPI ID
 consists of two parts: a Vendor ID followed by a product identifier.
 
 Vendor IDs consist of 4 characters, each character being either an
-uppercase letter (A-Z) or a numeral (0-9). The Vendor ID should be
+uppercase letter (A-Z) or a numeral (0-9). The Vendor ID SHOULD be
 unique across the Industry and registered by the UEFI forum. For RVI
 standard devices, **"RSCV"** is the Vendor ID registered. Vendor-specific
 devices can use an appropriate Vendor ID registered for the manufacturer.

acpi.adoc

@@ -17,8 +17,8 @@ IMPORTANT: All content in this section is optional and recommended for BRS-B.
 | ID#     ^| Requirement
 | [[acpi-64bit-clean]]ACPI_010 a| Be 64-bits clean.
 
-  * RSDT must not be implemented, with RsdtAddress in RSDP set to 0.
-  * 32-bit address fields must be 0.
+  * RSDT MUST NOT be implemented, with RsdtAddress in RSDP set to 0.
+  * 32-bit address fields MUST be 0.
 2+| _<<acpi-guidance-64bit-clean, See additional guidance>>._
 | [[acpi-hw-reduced]]ACPI_020 a| Implement the HW-Reduced ACPI Mode (no FACS table).
 2+| _<<acpi-guidance-hw-reduced, See additional guidance>>._
@@ -33,7 +33,7 @@ available to an OS loader via the standard UEFI EFI_GRAPHICS_OUTPUT_PROTOCOL int
  * Revision 4 or later of SPCR.
  * For NS16550-compatible UARTs:
  ** Use Interface Type 0x12 (16550-compatible with parameters defined in Generic Address Structure).
- ** There must be a matching AML device object.
+ ** There MUST be a matching AML device object.
 2+| _<<acpi-guidance-spcr, See additional guidance>>_.
 | [[acpi-namespace-dev]]ACPI_080 | Depending on the interrupt controller
 implemented by the system, PLIC or APLIC namespace devices MUST be
@@ -65,12 +65,12 @@ objects.
 2+| _ACPI resource descriptors are typically used to describe devices with fixed CSR regions that do not change. Flexible resource assignment is not supported by most modern ACPI OSes._
 | AML_040 | Per-hart device objects MUST be defined under \_SB (System Bus) namespace and not in the deprecated \_PR (Processors) namespace.
 | AML_050 | Systems supporting OS-directed hart performance control and power management MUST expose these via Collaborative Processor Performance Control (CPPC, cite:[ACPI] Section 8.4.6).
-| AML_060 | Processor idle states must be described using Low Power Idle (LPI, cite:[ACPI] Section 8.4.3).
+| AML_060 | Processor idle states MUST be described using Low Power Idle (LPI, cite:[ACPI] Section 8.4.3).
 | [[acpi-tad]] AML_070 | Systems with a Real-Time Clock on an OS-managed bus (e.g. I2C, subject to arbitration issues due to access to the bus by the OS) MUST implement the Time and Alarm Device (TAD).
 2+| _Also see <<uefi-rtc, URT_020>>_.
-| AML_080 | Systems implementing a TAD must be functional without additional system-specific OS drivers.
+| AML_080 | Systems implementing a TAD MUST be functional without additional system-specific OS drivers.
 2+| _In situations where the Time and Alarm Device (TAD) depends on a
-vendor-specific OS driver for correct function (SPI, I2C, etc), the TAD must
+vendor-specific OS driver for correct function (SPI, I2C, etc), the TAD MUST
 be functional if the OS driver is not loaded. That is, when a dependent
 driver is loaded, an AML method switches further accesses to go
 through the driver-backed OperationRegion._

smbios.adoc

@@ -20,7 +20,7 @@ language (cite:[SMBIOS]).
 | SMBIOS_010 | A Baseboard/Module Information (Type 02) structure SHOULD be implemented.
 | SMBIOS_020 | A System Enclosure/Chassis (Type 03) structure SHOULD be implemented.
 2+|_This relaxes the SMBIOS specification requirement._
-| SMBIOS_030 | A Processor Information (Type 04) structure, meeting the additional <<smbios-type04>> clarifications, must be implemented.
+| SMBIOS_030 | A Processor Information (Type 04) structure, meeting the additional <<smbios-type04>> clarifications, MUST be implemented.
 2+|_This supersedes the RISC-V specific language in the SMBIOS specification (cite:[SMBIOS], Section 7.5.3.5)._
 | SMBIOS_040 | A Port Connector Information (Type 08) SHOULD be implemented.
 | SMBIOS_050 | A System Slots (Type 09) structure MUST be implemented, when expansion slots are present.

uefi.adoc

@@ -18,16 +18,16 @@ IMPORTANT: All content in this section is optional and recommended for BRS-B.
 | UEFI_020 | Meet the 3rd Party UEFI Certificate Authority (CA) requirements on UEFI memory mitigations cite:[MSUefiCaRequirements].
 | UEFI_030 a| Meet BRS-I specific memory map requirements:
 
-              * The default memory space attribute must be EFI_MEMORY_WB.
+              * The default memory space attribute MUST be EFI_MEMORY_WB.
               * Enable address translation.
               * Only use EfiRuntimeServicesData memory type for describing any SMBIOS data structures.
 | UEFI_040 | An implementation MAY comply with the UEFI Platform Initialization Specification cite:[UEFI-PI].
 | UEFI_050 | All hart manipulation internal to a firmware implementation SHOULD be done before completion of the EFI_EVENT_GROUP_READY_TO_BOOT event, with all secondary harts remaining offline from that point on.
 2+| _This ensures an OS loader is entered with an OS-compatible state for all harts._
 | UEFI_060 | Declare a EFI_CONFORMANCE_PROFILES_UEFI_SPEC_GUID conformance profile.
-2+| _The EFI_CONFORMANCE_PROFILES_UEFI_SPEC_GUID conformance profile must be declared, as the BRS requirements are a superset of UEFI cite:[UEFI] (Section 2.6)._
+2+| _The EFI_CONFORMANCE_PROFILES_UEFI_SPEC_GUID conformance profile MUST be declared, as the BRS requirements are a superset of UEFI cite:[UEFI] (Section 2.6)._
 | UEFI_070 | Declare EFI_CONFORMANCE_PROFILE_BRS_1_0_SPEC_GUID conformance profile ({ 0x05453310, 0x0545, 0x0545, { 0x05, 0x45, 0x33, 0x05, 0x45, 0x33, 0x05, 0x45 }}).
-2+| _Only a system fully compliant to the requirements in this section may declare the EFI_CONFORMANCE_PROFILE_BRS_1_0_SPEC_GUID conformance profile._
+2+| _Only a system fully compliant to the requirements in this section MAY declare the EFI_CONFORMANCE_PROFILE_BRS_1_0_SPEC_GUID conformance profile._
 |===
 
 === BRS-I Security Requirements
@@ -65,23 +65,23 @@ See additional <<uefi-rt, requirements under UEFI Runtime Services>>.
 | ID#     ^| Requirement
 | URT_010 a| Systems without a Real-Time Clock (RTC) MUST meet the following requirements:
 
-             * GetTime must be implemented (e.g. in terms of CPU cycle counter).
-             * SetTime must return EFI_UNSUPPORTED, and be appropriately described in EFI_RT_PROPERTIES_TABLE.
+             * GetTime MUST be implemented (e.g. in terms of CPU cycle counter).
+             * SetTime MUST return EFI_UNSUPPORTED, and be appropriately described in EFI_RT_PROPERTIES_TABLE.
 | [[uefi-rtc]] URT_020 a| Systems with a Real-Time Clock on an OS-managed bus (e.g. I2C, subject to arbitration issues due to access to the bus by the OS) MUST meet the following requirements:
 
-             * GetTime and SetTime must return EFI_UNSUPPORTED, when called after the UEFI boot services have been exited.
-             * GetTime and SetTime must be appropriately described in EFI_RT_PROPERTIES_TABLE.
+             * GetTime and SetTime MUST return EFI_UNSUPPORTED, when called after the UEFI boot services have been exited.
+             * GetTime and SetTime MUST be appropriately described in EFI_RT_PROPERTIES_TABLE.
 2+|_Also see <<acpi-tad, AML_070>>_.
 | URT_030 a| The UEFI ResetSystem() runtime service MUST be implemented.
 2+| _The OS MUST call the ResetSystem() runtime service call to reset or shutdown the system, preferring this to SBI, ACPI or other system-specific mechanisms. This allows for systems to perform any required system tasks on the way out (e.g. servicing UpdateCapsule() or persisting non-volatile variables in some systems)._
 | URT_040 | Non-volatile UEFI variables MUST persist across calls to the Reset System() runtime service call.
 | URT_050 | UEFI Runtime Services MUST be able to update the variables directly without the aid of an OS.
 | URT_060 a| The following requirements MUST be met for systems with UEFI Secure Boot:
 
-             * Must support a minimum of 128 KB of non-volatile storage for UEFI variables.
-             * The maximum supported variable size must be at least 64 KB.
-             * The 'db' signature database variable EFI_IMAGE_SECURITY_DATABASE must be created with EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS, to prevent rollback attacks.
-             * The 'dbx' signature database variable EFI_IMAGE_SECURITY_DATABASE1 must be created with EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS, to prevent rollback.
+             * MUST support a minimum of 128 KiB of non-volatile storage for UEFI variables.
+             * The maximum supported variable size MUST be at least 64 KiB.
+             * The 'db' signature database variable EFI_IMAGE_SECURITY_DATABASE MUST be created with EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS, to prevent rollback attacks.
+             * The 'dbx' signature database variable EFI_IMAGE_SECURITY_DATABASE1 MUST be created with EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS, to prevent rollback.
 |===
 
 === BRS-I Firmware Update