3 files changed, 153 insertions, 19 deletions
diff --git a/docs/AAI REST API Documentation/AAIRESTAPI_CASABLANCA.rst b/docs/AAI REST API Documentation/AAIRESTAPI_CASABLANCA.rst
index 49dc1077..cb23ae50 100644
--- a/docs/AAI REST API Documentation/AAIRESTAPI_CASABLANCA.rst
+++ b/docs/AAI REST API Documentation/AAIRESTAPI_CASABLANCA.rst
@@ -1715,3 +1715,13 @@ List of Queries and Payloads
 For a full list of available custom queries, please refer to our
 `Custom Queries <customQueries.html>`_ document
 
+Nodes Query
+-----------
+
+In working with AAI's standard REST API, you may have noticed that
+certain API paths have a hierarchy to them and require a client to
+know multiple object keys to preform GETs. The nodes API allows for
+more freedom in querying AAI, allowing clients to circumvent the need
+to know every key in the hierarchy.
+
+See `Nodes Query <nodesQuery.html>`_ for more information.
diff --git a/docs/AAI REST API Documentation/nodesQuery.rst b/docs/AAI REST API Documentation/nodesQuery.rst
new file mode 100644
index 00000000..6064020b
--- /dev/null
+++ b/docs/AAI REST API Documentation/nodesQuery.rst
@@ -0,0 +1,94 @@
+.. contents::
+   :depth: 3
+..
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+
+Nodes Query
+===========
+
+In working with AAI's standard REST API, you may have noticed that
+certain API paths have a hierarchy to them and require a client to
+know multiple object keys to preform GETs. For example: the vserver
+object is under tenant, which is itself under cloud-region. If you
+wanted to look up a vserver by name, you would still need to know the
+tenant-id and cloud-region-id (and cloud-owner) in order to
+successfully perform that GET. The nodes API allows for more freedom
+in querying AAI, allowing clients to circumvent the need to know
+every key in the hierarchy. Using the previous example, the below is
+how the API called would change for looking up a vserver by name:
+
+.. code::
+
+  GET /aai/v$/cloud-infrastructure/cloud-regions/cloud-region/{cloud-owner}/{cloud-region-id}/tenants/tenant/{tenant-id}/vservers?vserver-name={vserver-name}
+  becomes
+  GET /aai/v$/nodes/vservers?vserver-name={vserver-name}
+
+A side effect of this is that if the same vserver name was reused between
+multiple cloud-regions or tenants the client will receive multiple
+vservers in the response. Vserver ID and vserver name are
+intentionally non-unique outside of their cloud-region/tenant
+hierarchy, as are many other keys for nested objects.
+
+API URI
+~~~~~~~
+
+.. code::
+
+   GET /aai/v$/nodes/{plural}?{property}={value}
+   OR
+   GET /aai/v$/nodes/{plural}/{singular}/{key}
+
+Optional Query Parameters
+~~~~~~~~~~~~~~~~~~~~~~~~~
+The Nodes API can make use of all the optional query
+parameters available on the standard REST API.
+
+Depth
+~~~~~
+
+You can pass a depth query parameter to indicate what level of child objects you want
+returned. By default the output will be depth = 0 (no "children", only
+"cousin" relationships). When using depth in conjunction with the
+format query parameter, it will only apply to the on the resource or
+resource_and_url formats.
+
+.. code::
+
+   GET /aai/v$/nodes/{plural}/{singular}/{key}?depth={integer}
+
+Nodes Only
+~~~~~~~~~~
+
+You can pass a nodes only query parameter to have the output only contain
+the object properties with no relationships.
+
+.. code::
+
+   GET /aai/v$/nodes/{plural}/{singular}/{key}?nodes-only
+   OR
+   GET /aai/v$/nodes/{plural}/{singular}/{key}?format={format}&nodesOnly=true
+
+Format
+~~~~~~
+
+You can optionally request an output format different from the default
+REST API output. You can reference the list of formats on the `Custom
+Query <customQueries.html>`_ wiki page for the full list of available
+formats and examples.
+
+.. code::
+
+   GET /aai/v$/nodes/{plural}/{singular}/{key}?format={format}
+
+Usage with Custom Query
+~~~~~~~~~~~~~~~~~~~~~~~
+
+The Nodes API can be called directly or as the start node for Custom
+Queries. Please reference the Custom Queries wiki page for full
+documentation on how to use that interface.
+
+.. code::
+
+   PUT /aai/v$/query?format={format} with payload like..
+   { "start": ["nodes/{plural}/{singular}/{key}"], "query": "query/{query-name}" }
diff --git a/docs/release-notes.rst b/docs/release-notes.rst
index dcea52d9..03e085b0 100644
--- a/docs/release-notes.rst
+++ b/docs/release-notes.rst
@@ -9,7 +9,7 @@ AAI Release Notes
 Version: 1.3.0
 --------------
 
-:Release Date: TBD
+:Release Date: 2018-11-30
 
 **New Features**
 
@@ -17,27 +17,57 @@ The R3 Casablanca release of ONAP again focuses on platform maturity
 and deployablity. AAI continued to leverage oom and kubernetes, and
 added new data types in support of multiple R3 use cases.  AAI added a
 new schema ingest library which moves AAI closer to being more
-model-driven.
+model-driven and a new microservice called "graphadmin" which provides
+graph maintenance and configuration facilities.
 
-Authentication and Authorization is performed using AAF with the CADI
-framework. We use basic authentication with RBAC (Role Based Access
-Control) to secure the AAI REST APIs.
+AAI is more model driven in Casablanca, which means it dynamically
+operationalize new and updated models at run-time, with minimal
+downtime and coding, so that the latest service and resource models
+can be delivered quickly. To do this, AAI must update its internal
+model, external API and behavior to respond to change to service and
+resource models, including schema changes. There are changes required
+to align on implementation across different ONAP components to provide
+a more strategic model-driven A&AI implementation. For this release
+decomposing AAI model/schema artifacts (OXM/XSD) into a more granular
+approach better enables extensibility and support logical
+subdivision of models.
 
-**Epic**
+AAI added support fo the Cross Domain and Carrier Layer VPN use case
+by adding new object types, models, and edge rules.
+
+AAI delivered 50%+ test coverage on all Java-based repos.
+
+Added support Support for SR-IOV.
+
+Authentication and Authorization is performed using AAF with the
+CADI framework. We use basic authentication with RBAC (Role Based
+Access Control) to secure the AAI REST APIs.
+
+AAI added automation support for orchestrating SR-IOV Provider
+Networks that are compatible with the Network Cloud 1.0
+infrastructure solution based on standard SR-IOV. Allow for standard
+SR-IOV Provider Networks to be defined with a set of one or more
+VLAN associations.
+
+AAI added suport to allow clients to specify the format on GET
+operations in the resources micoservices to output like the custom
+query API does.
+
+Added support for VLAN tagging.
+
+**Known Issues**
 
-- `AAI-32 <https://jira.onap.org/browse/AAI-32>`_ Integrate with AAF
-- `AAI-766 <https://jira.onap.org/browse/AAI-766>`_ Microservice for administering the AAI graph db
-- `AAI-767 <https://jira.onap.org/browse/AAI-767>`_ Make AAI More Model Driven
-- `AAI-981 <https://jira.onap.org/browse/AAI-981>`_ Schema updates required for the R3 Casablanca use cases
-- `AAI-1340 <https://jira.onap.org/browse/AAI-1340>`_ Support CCVPN use case in AAI
-- `AAI-1409 <https://jira.onap.org/browse/AAI-1409>`_ SONAR Coverage
-- `AAI-1410 <https://jira.onap.org/browse/AAI-1410>`_ Logging Enhancements
-- `AAI-1411 <https://jira.onap.org/browse/AAI-1411>`_ SRIOV Automation
-- `AAI-1413 <https://jira.onap.org/browse/AAI-1413>`_ 5G Core Scale over Network Cloud
-- `AAI-1415 <https://jira.onap.org/browse/AAI-1415>`_ SVLAN and CVLAN rewrite
-- `AAI-1416 <https://jira.onap.org/browse/AAI-1416>`_ Enhance CRUD APIs to take Optional "format"
-- `AAI-1418 <https://jira.onap.org/browse/AAI-1418>`_ VLAN Tagging
-- `AAI-1419 <https://jira.onap.org/browse/AAI-1419>`_ Schema Ingest Library
+Please find at this link the list of issues that will be fixed in the `Casablanca Maintenance Release <https://jira.onap.org/issues/?jql=fixVersion%20%3D%20%22Casablanca%20Maintenance%20Release%22%20and%20type%20%3D%20Bug%20and%20project%20%3D%20%22Active%20and%20Available%20Inventory%22>`_
+
+**Security Notes**
+
+AAI code has been formally scanned during build time using NexusIQ and all Critical vulnerabilities have been addressed, items that remain open have been assessed for risk and determined to be false positive. The AAI open Critical security vulnerabilities and their risk assessment have been documented as part of the `project <https://wiki.onap.org/pages/viewpage.action?pageId=45307817>`_.
+
+Quick Links:
+
+- `AAI project page <https://wiki.onap.org/display/DW/Active+and+Available+Inventory+Project>`_
+- `Passing Badge information for AAI <https://bestpractices.coreinfrastructure.org/en/projects/1591>`_
+- `Project Vulnerability Review Table for AAI <https://wiki.onap.org/pages/viewpage.action?pageId=45307817>`_
 
 
 Version: 1.2.0