diff --git a/docs/book/src/developer/architecture/controllers/machine.md b/docs/book/src/developer/architecture/controllers/machine.md
index 758145a7d474..bf73eae6fcf4 100644
--- a/docs/book/src/developer/architecture/controllers/machine.md
+++ b/docs/book/src/developer/architecture/controllers/machine.md
@@ -81,6 +81,14 @@ The `spec` object **must** at least one field defined:
 
 * `providerID` - a cloud provider ID identifying the machine.
 
+#### Optional `spec` fields
+
+The `spec` object **may** define the following field:
+
+* `osType` - string value of either `Linux` or `Windows` which can be used by providers to provide OS specific behavior.  
+  If not included it is assumed the machine `OsType` is `Linux`. Refer to the specific provider documentation to 
+  for support and changes in behavior of the provider.
+
 #### Required `status` fields
 
 The `status` object **must** at least one field defined:
diff --git a/docs/book/src/developer/providers/machine-infrastructure.md b/docs/book/src/developer/providers/machine-infrastructure.md
index e3ada74947e5..f0c43c698b32 100644
--- a/docs/book/src/developer/providers/machine-infrastructure.md
+++ b/docs/book/src/developer/providers/machine-infrastructure.md
@@ -25,6 +25,9 @@ A machine infrastructure provider must define an API type for "infrastructure ma
            instead. If supporting conversions from previous types, the provider will need to support a conversion from
            the provider-specific field that was previously used to the `failureDomain` field to support the automated
            migration path.
+        1. `osType` - string value of either `Linux` or `Windows` which can be used by other providers to provide OS specific 
+           behavior.  If not included it is assumed the machine `OsType` is `Linux`. Refer to the specific provider 
+           documentation for support and any changes in behavior.
 6. Must have a `status` field with the following:
     1. Required fields:
         1. `ready` (boolean): indicates the provider-specific infrastructure has been provisioned and is ready
diff --git a/docs/book/src/tasks/kubeadm-bootstrap.md b/docs/book/src/tasks/kubeadm-bootstrap.md
index ac30948e7b8a..a04498b78eb2 100644
--- a/docs/book/src/tasks/kubeadm-bootstrap.md
+++ b/docs/book/src/tasks/kubeadm-bootstrap.md
@@ -259,8 +259,8 @@ The `KubeadmConfig` object supports customizing the content of the config-data.
     verbosity: 10
     ```
 
-- `KubeadmConfig.UseExperimentalRetryJoin` replaces a basic kubeadm command with a shell script with retries for joins. This will add about 40KB to userdata.
-
+- `KubeadmConfig.UseExperimentalRetryJoinUseExperimentalRetryJoin` replaces a basic kubeadm command with a shell script with retries for joins. This will add about 40KB to userdata.
+  
     ```yaml
     useExperimentalRetryJoin: true
     ```
diff --git a/docs/proposals/20200804-windows-support.md b/docs/proposals/20200804-windows-support.md
index 80047a0345fc..d9e396a8fb7b 100644
--- a/docs/proposals/20200804-windows-support.md
+++ b/docs/proposals/20200804-windows-support.md
@@ -143,25 +143,13 @@ currently uses a Linux shell script to create add the retry functionality and do
 solution is to add retries to CABPK core but requires kubeadm refactors to enable use as a library that are still in 
 progress (see the [tracking issue](https://github.com/kubernetes-sigs/cluster-api/issues/2769#issuecomment-603989176)).
 
-For the current `UseExperimentalRetryJoin` CABPK will need to be aware of the type of OS that is requesting the kubeadm join 
-script to accommodate Windows. The OS information should be added on the Infra Machine (AWSMachine, AzureMachine, 
+To add support for Windows, the current `UseExperimentalRetryJoin` in CABPK needs to be aware of the type of OS that is requesting the kubeadm join 
+to provide the correct script. The OS information should be added on the Infra Machine (AWSMachine, AzureMachine, 
 DockerMachine, etc) since it's tightly coupled to the infrastructure and OS image. The CAPI machine object should be agnostic 
-and look as much as possible as a Kubernetes node, rather than a VM. We will add this as an optional field on the Status Field 
-in the CAPI Machine type and CABPK (and other tooling) can use it. If the field is not provided then we will assume the current 
-version to maintain backwards compatibility. 
+and look as much as possible as a Kubernetes node [see discussion](https://github.com/kubernetes-sigs/cluster-api/pull/3616#discussion_r495132309), 
+rather than a VM. The field on the Infra Machine is optional and if not provided will be assumed the value is Linux.
 
-An example on the Infra Machine:
-
-```go
-type InfraMachineSpec struct {
-	...
-	VMSize string `json:"vmSize"`
-  OS OsType `json:"osType:"`
-  ...
-}
-```
-
-CAPI would need to know the OS type so we can provide it as a well known field:
+CAPI will need to know the OS type so we can provide it as a well known field:
 
 ```go
 type OsType string
@@ -172,7 +160,18 @@ const (
 )
 ```
 
-The Machine controller will search for this optional `osType` field and sync it to the status field. CABPK would then reference the Status field for the `osType` and alter the logic in [cloudinit](https://github.com/kubernetes-sigs/cluster-api/blob/2afc70d32567682f93468033433e72fd428fc8f9/bootstrap/kubeadm/internal/cloudinit/cloudinit.go) to output the correct field.
+An example of `OsType` the Infra Machine:
+
+```go
+type InfraMachineSpec struct {
+	VMSize string `json:"vmSize"`
+  OS OsType `json:"osType:"`
+  ...
+}
+```
+
+CABPK (or any provider that wishes to use this information) will search for this optional `OsType` field on the Infra Machine. If the field is not found it will be defaulted 
+to `Linux` to maintain backwards compatibility.  This additional field contract between a bootstrap provider and Infra Machine will be optional. 
 
 #### netbios names