1 files changed, 127 insertions, 17 deletions

diff --git a/doc/book-enea-nfv-access-release-info/doc/main_changes.xml b/doc/book-enea-nfv-access-release-info/doc/main_changes.xml
index 6719a36..58435ff 100644
--- a/doc/book-enea-nfv-access-release-info/doc/main_changes.xml
+++ b/doc/book-enea-nfv-access-release-info/doc/main_changes.xml
@@ -14,28 +14,25 @@
 
     <itemizedlist>
       <listitem>
-        <para>uCPE Manager 1.0.1</para>
+        <para>Use of OpenJDK as the Java Engine in the uCPE Manager.</para>
       </listitem>
 
       <listitem>
-        <para>Support for standard (non-DPDK) interfaces on the virtualized
-        networking infrastructure.</para>
+        <para>USB Installer Web User Interface.</para>
       </listitem>
 
       <listitem>
-        <para>Support for OpenvSwitch using kernel datapath.</para>
+        <para>Support of ZTP extensions through custom scripting.</para>
       </listitem>
 
       <listitem>
-        <para>In-band management extension for VNFs' management plane.</para>
+        <para>Support for uCPE device software management from the Enea uCPE
+        Manager.</para>
       </listitem>
 
       <listitem>
-        <para>UEFI Secure Boot.</para>
-      </listitem>
-
-      <listitem>
-        <para>Bare Metal Provisioning.</para>
+        <para>Support for Layer 3 networking configuration from the Enea uCPE
+        Manager.</para>
       </listitem>
     </itemizedlist>
   </section>
@@ -48,13 +45,126 @@
     release.</para>
   </section>
 
-  <section condition="hidden" id="relinfo-backward-compat">
+  <section id="relinfo-backward-compat">
     <title>Compatibility</title>
 
-    <para>In the development of any complex software platform, there is a need
-    to strike a balance between backwards compatibility and new development.
-    In most cases, compatibility will be maintained as long as reasonably
-    possible. Necessary compatibility breaks will be done only as needed and
-    in major releases.</para>
+    <para condition="hidden">In the development of any complex software
+    platform, there is a need to strike a balance between backwards
+    compatibility and new development. In most cases, compatibility will be
+    maintained as long as reasonably possible. Necessary compatibility breaks
+    will be done only as needed and in major releases.</para>  
+
+    <para><remark>LXCR-9773</remark>Following REST API changes were added:</para>
+
+    <itemizedlist>
+      <listitem>
+        <para>The <literal>uploadCustomScript()</literal> method included in the 
+          <literal>CustomScripts</literal> module takes in an
+        additional argument (device module name).</para>
+      </listitem>
+
+      <listitem>
+        <para>A new <literal>-- upload() --</literal> method has been added to
+          the Device Upgrade module to allow for uploads of NFV Access software 
+          images to the uCPE Manager.</para>
+      </listitem>
+
+      <listitem>
+        <para>A new <literal>-- upload() --</literal> method has been added to
+          the <literal>VnfManager</literal> module to allow uploads of VNF 
+          images to the uCPE Manager as part of the onboarding process.</para>
+      </listitem>
+    </itemizedlist>
+
+    <para>The <literal>VcpeAgent</literal> (i.e. the NFV Access device module)
+    was redesigned:</para>
+
+    <itemizedlist>
+      <listitem>
+        <para> The <literal>system-attributes</literal> config table was split
+        into <literal>system-attributes-state</literal> (operational data) and
+        <literal>system-attributes</literal> (configuration data).</para>
+
+        <itemizedlist>
+          <listitem>
+            <para> The configuration data still contains the attributes:
+            <literal>device-name</literal>,
+            <literal>device-description</literal> and
+            <literal>initial-configuration-complete</literal>.</para>
+          </listitem>
+
+          <listitem>
+            <para>The fields <literal>device-type</literal>,
+            <literal>device-version</literal>, <literal>device-id</literal>,
+            <literal>device-latitude</literal>, and
+            <literal>device-longitude</literal> are now operational data.
+            <literal>device-ip-address</literal> has been added as oper
+            data.</para>
+          </listitem>
+
+          <listitem>
+            <para>The <literal>customer-tag</literal> in release version 2.2.1
+            was a config leaf-list, it is now a leaf called
+            <literal>device-customer-tags</literal> (comma-separated).</para>
+          </listitem>
+
+          <listitem>
+            <para>The <literal>mgmt-ip-address</literal> has been added as
+            oper data. This attribute was configured within an ovs-bridge of
+            type <literal>inband-mgmt</literal>.</para>
+          </listitem>
+        </itemizedlist>
+      </listitem>
+
+      <listitem>
+        <para>The <literal>external-interface-capabilities</literal>
+        operational table now has <literal>wan</literal> and
+        <literal>mgmt</literal> Booleans.</para>
+      </listitem>
+
+      <listitem>
+        <para>The <literal>external-interface</literal> configuration table
+        now has a choice of <literal>wan</literal>. </para>
+
+        <para>New fields for this type are <literal>mgmt-interface</literal>,
+        <literal>address-assignment</literal>, <literal>ip-address</literal>,
+        <literal>gateway</literal>, and <literal>netmask</literal> (only
+        considered if static).</para>
+      </listitem>
+
+      <listitem>
+        <para>In an <literal>ovs-bridge</literal>, for the choice of
+        <literal>inband-mgmt</literal>, the <literal>mgmt-address</literal>
+        and <literal>mgmt-port</literal> fields have been removed (there are
+        no fields left in this choice).</para>
+      </listitem>
+
+      <listitem>
+        <para>In the Host operational table, there are a couple of
+        changes:</para>
+
+        <itemizedlist>
+          <listitem>
+            <para>The <literal>name</literal> field has been removed, however,
+            there is still a <literal>host-name</literal> field.</para>
+          </listitem>
+
+          <listitem>
+            <para>A <literal>machine-type</literal> field has been
+            added.</para>
+          </listitem>
+        </itemizedlist>
+      </listitem>
+    </itemizedlist>
+    
+    <para>REST clients should see only some minor changes when upgrading from 
+      NFV Access 2.2.1 to NFV Access 2.2.2. Code that deals with the 
+      system-attributes table, in-band management OVS bridges, or the host 
+      operational data may need to be modified.</para>
+    
+    <para>The new WAN interface type needs a <literal>wan-mgmt</literal> 
+      interface configured to create the <literal>in-band mgmt</literal> bridge. 
+      This should typically happen automatically as part of initial installation
+      or upgrade and should not affect the REST clients.</para>
   </section>
-</chapter>
+</chapter>
\ No newline at end of file