diff --git a/images/layers1.png b/images/layers1.png
new file mode 100644
index 0000000..3179915
--- /dev/null
+++ b/images/layers1.png
Binary files differ
diff --git a/navigate.md b/navigate.md
index 56cb057..56dfed6 100644
--- a/navigate.md
+++ b/navigate.md
@@ -6,12 +6,12 @@
 components. This assembly is done according to the general pattern
 shown in the following diagram.
 
-![Layers](images/layers.png)
+![Layers](images/layers1.png)
 
 There are four major elements:
 
 * **Kubernetes:** All elements of the CORD control plane run in
-  Kubernetes containers. CORD assumes a Kubernetes foundation,
+  Kubernetes containers. CORD assumes a Kubernetes foundation (not shown above),
   but does not prescribe how Kubernetes or the underlying hardware
   are installed.
 
@@ -26,15 +26,15 @@
   on-boarded into XOS and SDN control apps running on ONOS.
   Examples of profiles are [SEBA](profiles/seba) and
   [M-CORD](profiles/mcord).
-  
-* **Workflow:** A Profile includes one or more workflows, each of
+
+* **Workflow:** A Profile typically includes a workflow,
   which defines the business logic and state machine for one of the
   access technologies contained in the Profile. A workflow customizes
-  a Profile for the target deployment environment; it is not a
+  a Profile for an operator's target deployment environment; it is not a
   software layer, per se.  SEBA's
   [AT&T Workflow](profiles/seba/workflows/att-install.md)
   is an example.
-  
+
 The diagram also shows a hardware bill-of-materials, which must be
 defined for a given POD.
 
@@ -103,7 +103,7 @@
   which is a pre-requisite for configuring and provisioning that new service.
 
 * Upgrading an existing service is similar to bringing up a new service,
-  where we depend on Kubernetes to incrermentally roll out the containers
+  where we depend on Kubernetes to incrementally roll out the containers
   that implement the service (and rollback if necessarily), and we depend
   on XOS to migrate from the old model to the new model (and support
   both old and new APIs during the transition period). Upgrading existing
diff --git a/profiles/seba/README.md b/profiles/seba/README.md
index 30220ff..b5ce6dc 100644
--- a/profiles/seba/README.md
+++ b/profiles/seba/README.md
@@ -1,7 +1,10 @@
 # SEBA Profile
 
-SEBA (SDN Enabled Broadband Access) is a profile meant for residential access networks
-[Click here for a high-level overview.](https://www.opennetworking.org/seba/).
+SEBA (SDN Enabled Broadband Access) is a profile meant for residential access networks.
+
+![SEBA-exemplar](./seba-ep.png "SEBA-exemplar")
 
 The following pages describe how to install SEBA with an operator defined workflow,
 and how to configure, operate and troubleshoot an installed SEBA POD.
+
+For more information on the SEBA community visit the [SEBA wiki page](https://wiki.opencord.org/display/CORD/SEBA)
diff --git a/profiles/seba/known-issues.md b/profiles/seba/known-issues.md
index a7e2d43..082ca8d 100644
--- a/profiles/seba/known-issues.md
+++ b/profiles/seba/known-issues.md
@@ -1,2 +1,33 @@
 # Known Issues
 
+## SEBA 1.0 Release
+
+The only known major issues have to do with reboot of physical hardware, both
+the OLT and the AGG switch. These issues are described in more detail in
+
+* [SEBA-388](https://jira.opencord.org/browse/SEBA-388)
+   With this issue, DHCP may not work after AGG switch reboot. A possible workaround is to use a different config for the DHCPl2Relay app that uses the OLT's uplink to reach the DHCP Server, instead of the Switch's uplink. More details are described [here](troubleshoot/no-dhcp.md)
+* [SEBA-385](https://jira.opencord.org/browse/SEBA-385)
+   With this issue, the OLT may not pass traffic anymore after reboot. Currently, the only workaround is to, enter the ONOS CLI and force a 'device-remove <&lt;device-id>' for the device from VOLTHA (in other words, force VOLTHA to reconnect to ONOS), and then perform the authentication/dhcp steps again for the subscribers
+
+Fixes to these issues will be addressed soon after the release.
+
+Another minor issue that does not affect functionality is related to the state of an ONU on the VOLTHA CLI, after disable/re-enable of the ONU.
+
+```shell
+(voltha) devices
+Devices:
++------------------+-------------------+------+------------------+------------------+-------------+-------------+----------------+----------------+------------------+------------------------+-------------------------+--------------------------+----------------------+------------------------------+
+|               id |              type | root |        parent_id |    serial_number | admin_state | oper_status | connect_status | parent_port_no |    host_and_port |                 reason | proxy_address.device_id | proxy_address.channel_id | proxy_address.onu_id | proxy_address.onu_session_id |
++------------------+-------------------+------+------------------+------------------+-------------+-------------+----------------+----------------+------------------+------------------------+-------------------------+--------------------------+----------------------+------------------------------+
+| 0001a82d21249c28 |           openolt | True | 000100000a5a007a | 10.90.0.122:9191 |     ENABLED |      ACTIVE |      REACHABLE |                | 10.90.0.122:9191 |                        |                         |                          |                      |                              |
+| 00014f81e9f21dbb | brcm_openomci_onu | True | 0001a82d21249c28 |     ALPHe3d1cf9d |     ENABLED |      ACTIVE |      REACHABLE |      536870912 |                  | initial-mib-downloaded |        0001a82d21249c28 |                          |                    1 |                            1 |
+| 0001666321e17127 | brcm_openomci_onu | True | 0001a82d21249c28 |     ALPHe3d1ced5 |     ENABLED |      ACTIVE |      REACHABLE |      536870912 |                  | initial-mib-downloaded |        0001a82d21249c28 |                          |                    2 |                            2 |
+| 000175a511654437 | brcm_openomci_onu | True | 0001a82d21249c28 |     ISKT71e80080 |     ENABLED |      ACTIVE |      REACHABLE |      536870927 |                  |      omci-flows-pushed |        0001a82d21249c28 |                       15 |                    1 |                            1 |
+| 0001cb66a703449d | brcm_openomci_onu | True | 0001a82d21249c28 |     ALPHe3d1cfe3 |     ENABLED |      ACTIVE |      REACHABLE |      536870912 |                  | initial-mib-downloaded |        0001a82d21249c28 |                          |                    3 |                            3 |
+| 0001246c72a99ddd | brcm_openomci_onu | True | 0001a82d21249c28 |     ALPHe3d1cf8e |     ENABLED |      ACTIVE |      REACHABLE |      536870912 |                  | initial-mib-downloaded |        0001a82d21249c28 |                          |                    4 |                            4 |
+| 000192f54601ecb4 | brcm_openomci_onu | True | 0001a82d21249c28 |     ALPHe3d1cf70 |     ENABLED |      ACTIVE |      REACHABLE |      536870912 |                  | initial-mib-downloaded |        0001a82d21249c28 |                          |                    5 |                            5 |
++------------------+-------------------+------+------------------+------------------+-------------+-------------+----------------+----------------+------------------+------------------------+-------------------------+--------------------------+----------------------+------------------------------+
+```
+
+In the `reason` column of the devices table, the state of the ONU devices are displayed. Normally after an ONU is disabled, and then re-enabled, it should display the `initial-mib-downloaded` state, indicating that the RG behind the ONU should be ready to re-authenticate (as per the AT&T workflow). However, in this release, the state is incorrectly displayed as `omci-flows-pushed`. This does not affect authentication, dhcp or the subscribers.
diff --git a/profiles/seba/seba-ep.png b/profiles/seba/seba-ep.png
new file mode 100644
index 0000000..607eea8
--- /dev/null
+++ b/profiles/seba/seba-ep.png
Binary files differ