diff --git a/SUMMARY.md b/SUMMARY.md
index 5796405..ee029d8 100644
--- a/SUMMARY.md
+++ b/SUMMARY.md
@@ -47,6 +47,8 @@
             * [XOS Configuration](xos/modules/xosconfig.md)
     * [Configuring Profiles](operating_cord/profiles.md)
         * [R-CORD](profiles/rcord/configuration.md)
+            * Workflows
+                * [AT&T](profiles/rcord/workflows/att.md)
         * [M-CORD](profiles/mcord/configuration.md)
     * [Configuring Services](operating_cord/services.md)
         * [Fabric](fabric/README.md)
@@ -67,6 +69,7 @@
         * [Core Models](xos/core_models.md)
         * [Security Policies](xos/security_policies.md)
         * [Tutorial](xos/tutorials/basic_synchronizer.md)
+        * [Build proto files from xProto](xos/dev/xproto_to_protobuf.md)
     * [Developer Workflows](developer/workflows.md)
         * [Working on R-CORD Without an OLT/ONU](developer/configuration_rcord.md)
     * [Building Docker Images](developer/imagebuilder.md)
diff --git a/book.json b/book.json
index 1317bf7..0bf2058 100644
--- a/book.json
+++ b/book.json
@@ -4,6 +4,9 @@
   "structure": {
     "summary": "SUMMARY.md"
   },
+  "styles": {
+    "website": "styles/website.css"
+  },
   "variables": {
     "branch": "master"
   },
diff --git a/images/att_workflow.png b/images/att_workflow.png
new file mode 100644
index 0000000..66c89ec
--- /dev/null
+++ b/images/att_workflow.png
Binary files differ
diff --git a/profiles/rcord/configuration.md b/profiles/rcord/configuration.md
index d2cff9a..4e81cb0 100644
--- a/profiles/rcord/configuration.md
+++ b/profiles/rcord/configuration.md
@@ -305,6 +305,74 @@
 For instructions on how to push TOSCA into a CORD POD, please
 refer to this [guide](../../xos-tosca/README.md).
 
+### Complete the Subscriber config
+
+As a result of the OLT/ONU activation you'll find out that XOS has generated
+an `RCORDSubscriber` for you.
+That model has the `status` field set to `awaiting-auth`, that means that
+you can ping the gateway but not the internet.
+
+The authentication mechanism is not yet ready in CORD 6.0,
+so you need to configure few attributes manully,
+such as:
+
+- `ip_addres`
+- `mac_address`
+- set `status` to `enabled`
+
+You can do that via the GUI or you can use a TOSCA like the following:
+```yaml
+tosca_definitions_version: tosca_simple_yaml_1_0
+imports:
+  - custom_types/rcordsubscriber.yaml
+description: Create a test subscriber
+topology_template:
+  node_templates:
+    # A subscriber
+    my_house:
+      type: tosca.nodes.RCORDSubscriber
+      properties:
+        name: My House
+        must-exist: true
+        status: enabled
+        mac_address: 00:AA:00:00:00:01 # subscriber mac address
+        ip_address: 10.8.2.1 # subscriber IP
+```
+
+For instructions on how to push TOSCA into a CORD POD, please
+refer to this [guide](../../xos-tosca/README.md).
+
+#### Pre-provision subscribers
+
+Another viable approach is to `pre-provision` subscribers,
+you can do that using this TOSCA:
+
+```yaml
+tosca_definitions_version: tosca_simple_yaml_1_0
+imports:
+  - custom_types/rcordsubscriber.yaml
+
+description: Pre-provsion a subscriber
+
+topology_template:
+  node_templates:
+
+    # Pre-provision the subscriber the subscriber
+    my_house:
+      type: tosca.nodes.RCORDSubscriber
+      properties:
+        name: My House
+        status: pre-provisioned
+        c_tag: 111
+        onu_device: BRCM22222222
+        mac_address: 90:E2:BA:82:FA:81
+        ip_address: 192.168.0.1
+```
+>NOTE: if you do this you still need to set `status=enabled` after the ONU comes up
+
+For instructions on how to push TOSCA into a CORD POD, please
+refer to this [guide](../../xos-tosca/README.md).
+
 ### Know issues
 
 There is a set of issue that we have seen from time to time.
diff --git a/profiles/rcord/workflows/att.md b/profiles/rcord/workflows/att.md
new file mode 100644
index 0000000..79545ea
--- /dev/null
+++ b/profiles/rcord/workflows/att.md
@@ -0,0 +1,30 @@
+# AT&T Workflow
+
+You can find a complete description of the SEBA workflow for At&t in [this document](https://docs.google.com/document/d/1nou2c8AsRzhaDJmA_eYvFgd0Y33KiCsioveU77AOVCI/edit#heading=h.x73smxj2xaib). This pages focus exclusively on the internals details of the workflow such as actions triggered by the environment and decisions taken by NEM.
+
+## Workflow description
+
+1. ONT discovered bottom-up
+2. If ONT serial number is not allowed or unknown (i.e it has NOT been provisioned by OSS), disable the ONT; generate an event to external OSS that an ONU has been discovered but not yet provisioned.
+3. When OSS provisions the ONT, re-enable it & program 802.1x flow - UNI port(s) will be UP
+4. Ensure that DHCP fails here (because subscriber/service-binding has not been provisioned by OSS yet)
+5. 802.1x EAPOL message happens from RG, and ONOS AAA app adds options and sends to radius server. Options are pulled from Sadis/NEM  - no subscriber information is required here
+6. If RG authentication fails, allow it to keep trying (in the future consider redirection to captive / self-help portal). DHCP should not succeed since RG authentication has failed
+7. If RG authentication succeeds, ONOS AAA app notifies via an event on the kafka bus that authentication has succeeded
+8. NEM can listen for the event, and then check to see if subscriber/service-binding has happened on that port from OSS - if not, then nothing to be done
+9. Must ensure that DHCP fails here even though RG has been authenticated (because subscriber/service-binding has not been provisioned by OSS yet)
+10. When OSS provisions the subscriber/service-binding on the UNI port and gives the C and S vlan info, then DHCP trap will be programmed on the port, and DHCP process can start
+11. If RG is disconnected from UNI port, force authentication again (even if subscriber/service-binding has been provisioned by OSS). Upon reconnection  to UNI port, RG must re-authenticate before DHCP/other-traffic can flow on the provisioned VLANs.
+12. DHCP L2 relay -> add option 82, learn public IP address, forward via dataplane to external DHCP server
+
+
+This schema summarizes the workflow, please note:
+
+- in `light blue` are environment events (wether they are triggered from hardware or from an operator)
+- in `yellow` are NEM configuration calls to ONOS or VOLTHA
+- in `green` are decisions
+- in `orange` event published on the kafka bus
+
+![att-workflow](../../../images/att_workflow.png)
+
+> NOTE: when we refer to `service chain` we are talking about the set of subscriber specific service instances that will trigger the `add_subscriber` call in ONOS-VOLTHA and provision the crossconnect in ONOS-FABRIC
\ No newline at end of file
diff --git a/styles/website.css b/styles/website.css
new file mode 100644
index 0000000..62fe48f
--- /dev/null
+++ b/styles/website.css
@@ -0,0 +1,14 @@
+.page-inner {
+    max-width: 95% !important;
+}
+
+.page-toc {
+    max-width: 400px;
+    margin-left: 10px;
+}
+
+.page-toc li {
+    list-style: disc;
+    text-indent: -1.5em;
+    padding-left: 1.5em;
+}
\ No newline at end of file
diff --git a/versioning.md b/versioning.md
index dd1a00c..1c821b2 100644
--- a/versioning.md
+++ b/versioning.md
@@ -12,8 +12,9 @@
 [PEP440](https://www.python.org/dev/peps/pep-0440/) syntax (`.dev#` instead of
 `-dev#`) if using Python code are the recommended formats.
 
-To avoid confusion, all components that existed prior to 6.0 started their
-independent versioning at version `6.0.0`.
+As this is the first time that many of these components received a version
+number, most of them started with version `1.0.0`, except for the `xos` core,
+which starts at `2.0.0`.
 
 ## CORD Releases
 
@@ -48,6 +49,58 @@
    version string, and Docker images with the tag will be built and sent to
    Docker Hub.
 
+## How to create a new CORD release
+
+For 6.0 and later releases, please follow these steps to create a new release.
+
+### Pre-release steps
+
+Per the instructions above, create versioned releases of all the individual
+components, primarily the docker images.
+
+In the `helm-charts` repo, check that all charts use only released versions of
+container images (no `master` or `candidate` tags), and that the `Chart.yaml`
+has the correct *new* `version` field set for the release.
+
+Test the release with this version of the charts, making sure to not override
+the image versions.
+
+### Release steps
+
+Update the `VERSION` file on both the `automation-tools` and `helm-charts`
+repos then commit and merge the patch. Jenkins will then create git tags from
+the contents of the `VERSION` file.
+
+Create a branch in Gerrit using the form `cord-#.#` on those repos starting
+with the new tagged commit.
+
+In the `docs` project, on the `master` branch add an entry to the `book.json`
+to add the new branch, and create a directory on the `guide.opencord.org` site
+for the branch docs.  Create a `cord-#.#` branch on the `docs` repo in Gerrit,
+then update the `git_refs` file within that repo with the commits that have
+the most pertinent documentation.  The `make freeze` command can help generate
+the contents of the `git_refs` file by listing the current git `HEAD` of each
+repo.
+
+Create a `cord-#.#` branch on the `manifest` repo, setting the `revision`
+attribute to `cord-#.#` on the `automation-tools`, `docs`, and `helm-charts`
+projects (and any other projects that have that patch branch).
+
+### Updates to a released branch
+
+Patches to individual components are generally done on the `master` branch of
+their respective projects and given component versions.
+
+Once released, these component versions are integrated into charts, the
+`version` field of the `Chart.yaml` for the chart is updated, and a new point
+release of the `helm-charts` repo is created on the `cord-#.#` branch.
+
+All patches on a released branch of the `helm-charts` and `automation-tools`
+repos should be SemVer release versions, not development versions.
+
+Documentation updates are less strict, with changes within the repo or to
+`git_refs` happening on the patch branch as needed.
+
 ## Details of the release process
 
 To create a new version, the version string is updated in the language or
@@ -64,10 +117,10 @@
 version string in the `VERSION` file, Jenkins jobs have been put in place to
 prevent this from happening. The implementation is as follows:
 
-- When a patchset is submitted to Gerrit, the `tag-collision-reject` Jenkins
-  job runs. This checks that the version string in `VERSION` is does not
-  already exist as a git tag, and rejects any patchsets that have duplicate
-  released versions. It ignores development and non-SemVer version strings.
+- When a patchset is submitted to Gerrit, the `tag-collision` Jenkins job runs.
+  This checks that the version string in `VERSION` is does not already exist as
+  a git tag, and rejects any patchsets that have duplicate released versions.
+  It ignores development and non-SemVer version strings.
 
   This job also checks that if a released version number is used, any
   Dockerfile parent images are also using a fixed parent version, to better