diff --git a/docs/sections/configuration/AAF_4.0_config.rst b/docs/sections/configuration/AAF_4.0_config.rst
new file mode 100644
index 0000000..75ba388
--- /dev/null
+++ b/docs/sections/configuration/AAF_4.0_config.rst
@@ -0,0 +1,152 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+.. Copyright © 2017 AT&T Intellectual Property. All rights reserved.
+
+============================
+Configuring
+============================
+*Note: this document assumes UNIX Bash Shell.  Being Java, AAF works in Windows, but you will have to create your own script/instruction conversions.*
+
+--------------------
+Configure AAF Volume
+--------------------
+
+AAF uses a Persistent Volume to store data longer term, such as CADI configs, Organization info, etc, so that data is not lost when changing out a container.
+
+This volume is created automatically, as necessary, and linked into the container when starting. ::
+
+  ## Be sure to have your 'd.props' file filled out before running.
+  $ bash aaf.sh
+
+----------------------------
+Bootstrapping with Keystores
+----------------------------
+
+Start the container in bash mode, so it stays up. ::
+
+  $ bash aaf.sh bash
+  id@77777: 
+
+In another shell, find out your Container name. ::
+  
+  $ docker container ls | grep aaf_config
+
+CD to directory with CA p12 files 
+  
+  * org.osaaf.aaf.p12
+  * org.osaaf.aaf.signer.p12    (if using Certman to sign certificates)
+
+Copy keystores for this AAF Env ::
+
+  $ docker container cp -L org.osaaf.aaf.p12 aaf_agent_<Your ID>:/opt/app/osaaf/local
+  ### IF using local CA Signer 
+  $ docker container cp -L org.osaaf.aaf.signer.p12 aaf_agent_<Your ID>:/opt/app/osaaf/local
+
+In Agent Window ::
+
+  id@77777: agent encrypt cadi_keystore_password
+  ### IF using local CA Signer 
+  id@77777: agent encrypt cm_ca.local 
+
+Check to make sure all passwords are set ::
+
+  id@77777: grep "enc:" *.props
+
+When good, exit from Container Shell and run AAF ::
+
+  id@77777: exit
+  $ bash drun.sh
+
+Check the Container logs for correct Keystore passwords, other issues ::
+
+  $ docker container logs aaf_<service>
+
+Watch logs ::
+
+  $ bash aaf.sh taillog
+
+Notes:
+
+You can find an ONAP Root certificate, and pre-built trustores  for ONAP Test systems at:
+  | authz/auth/sample/public/AAF_RootCA.cert
+  | authz/auth/sample/public/truststoreONAPall.jks
+
+Good Tests to run ::
+
+  ## From "docker" dir
+  ##
+  ## assumes you have DNS or /etc/hosts entry for aaf-onap-test.osaaf.org
+  ##
+  $ curl --cacert ../sample/public/AAF_RootCA.cer -u demo@people.osaaf.org:demo123456! https://aaf-onap-test.osaaf.org:8100/authz/perms/user/demo@people.osaaf.org
+  $ openssl s_client -connect aaf-onap-test.osaaf.org:8100
+
+-------------------------------
+Working with CADI Properties
+-------------------------------
+
+.. code:: bash
+
+   cadi.properties Template
+  # This is a normal Java Properties File
+  # Comments are with Pound Signs at beginning of lines,
+  # and multi-line expression of properties can be obtained by backslash at end of line
+  #hostname=
+
+  cadi_loglevel=WARN
+  cadi_keyfile=conf/keyfile
+
+
+  # Configure AAF
+  aaf_url=http://172.18.0.2:8101
+  #if you are running aaf service from a docker image you have to use aaf service IP and port number
+  aaf_id=<yourAPPID>@onap.org
+  aaf_password=enc:<encrypt>
+
+  aaf_dme_timeout=5000
+  # Note, User Expires for not Unit Test should be something like 900000 (15 mins) default is 10 mins
+  # 15 seconds is so that Unit Tests don't delay compiles, etc
+  aaf_user_expires=15000
+  # High count... Rough top number of objects held in Cache per cycle.  If high is reached, more are
+  # recycled next time.  Depending on Memory usage, 2000 is probably decent.  1000 is default
+  aaf_high_count=100
+
+
+How to create CADI Keyfile & Encrypt Password
+---------------------------------------------
+
+Password Encryption
+-------------------
+CADI provides a method to encrypt data so that Passwords and other sensitive data can be stored safely.
+
+Keygen (Generate local Symmetrical Key)
+A Keyfile is created by Cadi Utility.
+
+.. code:: bash
+
+  java -jar cadi-core-<version>.jar keygen <keyfile>
+  Given this key file unlocks any passwords created, it should be stored in your configuration directory and protected with appropriate access permissions. For instance, if your container is Tomcat, and runs with a "tomcat" id, then you should:
+
+.. code:: bash
+
+  java -jar cadi-core-<version>.jar keygen keyfile
+  chmod 400 keyfile
+  chown tomcat:tomcat keyfile
+  
+Digest - Encrypt a Password
+---------------------------
+The password is obtained by using the Cadi digest Utility (contained in the cadi-core-<version>.jar).
+
+.. code:: bash
+
+  java -jar cadi-core-<version>.jar digest <your_password> <keyfile>
+   •	"<keyfile>" is created by Cadi Utility, #keygen
+   •	Understand that if you change the keyfile, then you need to rerun "digest" on passwords used in the users/groups definitions.
+   •	Note: You cannot mix versions of cadi; the version used to digest your password must be the same version used at runtime.
+   
+CADI PROPERTIES
+   CADI properties, typically named "cadi.properties", must have passwords encrypted.
+      1.	Take the results of the "Digest" command and prepend "enc:"
+      2.	Use this as the value of your property
+	  
+Example:   aaf_password=enc:fMKMBfKHlRWL68cxD5XSIWNKRNYi5dih2LEHRFMIsut
+
diff --git a/docs/sections/configuration/AAF_4.1_config.rst b/docs/sections/configuration/AAF_4.1_config.rst
new file mode 100644
index 0000000..7197662
--- /dev/null
+++ b/docs/sections/configuration/AAF_4.1_config.rst
@@ -0,0 +1,161 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+.. Copyright © 2017 AT&T Intellectual Property. All rights reserved.
+
+========================================
+Automated Configuration and Certificates
+========================================
+
+*Note: this document assumes UNIX Bash Shell.  Being Java, AAF works in Windows, but you will have to create your own script/instruction conversions.*
+
+--------
+Strategy
+--------
+
+ONAP is deployed in Docker Containers or Kubernetes managed Docker Containers.  Therefore, this instruction utilizes a Docker Container as a standalone Utility... (This means that this container will stop as soon as it is done with its work... it is not a long running daemon)
+
+Given that all ONAP entities are also in Docker Containers, they all can access Persistent Volumes.
+
+This tool creates all the Configurations, including Certificates, onto a declared Volume on the directories starting with "/opt/app/osaaf"
+
+------------------
+Prerequisites
+------------------
+  * Docker
+    * Note: it does NOT have to be the SAME Docker that AAF is deployed on...
+    | but it DOES have be accessible to the AAF Instance.  
+  * For ONAP, this means
+    
+    * Windriver VPN
+    * include "10.12.6.214 aaf-onap-test.osaaf.org" in your /etc/hosts or DNS
+
+-----------------------
+Obtain the Agent Script
+-----------------------
+Choose the directory you wish to start in... 
+
+If you don't want to clone all of AAF, just get the "agent.sh" from a Browser:
+
+  https://gerrit.onap.org/r/gitweb?p=aaf/authz.git;a=blob_plain;f=auth/docker/agent.sh;hb=HEAD
+  
+  rename file "auth-docker-agent.sh" to "agent.sh" (named because of subdirectory in which it is found) 
+
+Note: curl/wget returns an  html, instead of text.  This cannot be used!
+  | You have to mv, and rename it to "agent.sh", but avoids full clone...
+
+-------------------------
+Run Script
+-------------------------
+
+In your chosen directory ::
+ 
+  $ bash agent.sh
+
+The Agent will look for "aaf.props", and if it doesn't exist, or is missing information, it will ask for it.
+
+This file is available to reuse for multiple calls. More importantly, you should use it as a template for auto-configuration.  (In ONAP, these are HEAT templates and OOM Helm Charts)
+
+---------------------
+'aaf.prop' Properties
+---------------------
+
+=================== =============== ============
+Query               Tag             Description
+=================== =============== ============
+CADI Version        VERSION         Defaults to CADI version of this
+AAF's FQDN          AAF_FQDN        PUBLIC Name for AAF. For ONAP Test, it is 'aaf-onap-test.osaaf.org'
+Deployer's FQI      DEPLOY_FQI      In a REAL system, this would be a person or process. For ONAP Testing, the id is deployer@people.osaaf.org, password (see Dynamic Properties) is 'demo123456!'
+App's Root FQDN     APP_FQDN        This will show up in the Cert Subject, and should be the name given by Docker. i.e. clamp.onap
+App's FQI           APP_FQI         Fully Qualified ID given by Organization and with AAF NS/domain.  ex: clamp@clamp.onap.org 
+App's Volume        VOLUME          Volume to put the data, see above. ex: clamp_aaf
+DRIVER              DRIVER          Docker Volume type... See Docker Volume documentation
+LATITUDE of Node    LATITUDE        Global latitude coordinate of Node (best guess in Kubernetes)
+LONGITUDE of Node   LONGITUDE       Global longitude coordinate of Node (best guess in Kubernetes)
+=================== =============== ============
+
+---------------------
+Dynamic Properties
+---------------------
+
+These Properties do not automatically save in 'aaf.props', because...
+
+  | Passwords should not be stored clear text, with the possible exception of constant Environment Recreation, where it is impractical.
+  | The IP of the AAF's FQDN is looked up, if possible.  It can be set, however, when lookup isn't available.
+
+=================== =============== ============
+Query               Tag             Description
+=================== =============== ============
+Deployer's Password DEPLOY_PASSWORD Password for the Deployer. Avoids storing, except where impossible otherwise. 
+IP of <AAF_FQDN>    AAF_FQDN_IP     IP for Name of AAF FQDN, if not available by normal lookup means
+=================== =============== ============
+
+-------------------------------
+Typical ONAP Entity Info in AAF
+-------------------------------
+*This is not intended to be a comprehensive list, but a short list of main entities*
+
+============================= ===========================  ======================= ==============================================
+ONAP Namespaces               APP FQI                      APP FQDN OOM            APP FQDN HEAT
+============================= ===========================  ======================= ==============================================
+org.osaaf.aaf                 aaf@aaf.osaaf.org            aaf.onap                aaf.api.simpledemo.onap.org
+org.onap.aaf-sms              aaf-sms@aaf-sms.onap.org     aaf-sms.onap            aaf-sms.api.simpledemo.onap.org
+org.onap.aai                  aai@aai.onap.org             aai.onap                aai.api.simpledemo.onap.org
+org.onap.appc                 appc@appc.onap.org           appc.onap               appc.api.simpledemo.onap.org
+org.onap.clamp                clamp@clamp.onap.org         clamp.onap              clamp.api.simpledemo.onap.org
+org.onap.dcae                 dcae@dcae.onap.org           dcae.onap               dcae.api.simpledemo.onap.org
+org.onap.dmaap                dmaap@dmaap.onap.org         dmaap.onap              dmaap.api.simpledemo.onap.org                                         
+org.onap.dmaap-bc             dmaap-bc@dmaap-bc.onap.org   dmaap-bc.onap           dmaap-bc.api.simpledemo.onap.org
+org.onap.dmaap-dr             dmaap-bc@dmaap-dr.onap.org   dmaap-dr.onap           dmaap-dr.api.simpledemo.onap.org                                           
+org.onap.dmaap-mr             dmaap-mr@dmaap-mr.onap.org   dmaap-mr.onap           dmaap-mr.api.simpledemo.onap.org
+org.onap.oof                  oof@oof.onap.org             oof.onap                oof.api.simpledemo.onap.org
+org.onap.policy               policy@policy.onap.org       policy.onap             policy.api.simpledemo.onap.org
+org.onap.pomba                pomba@pomba.onap.org         pomba.onap              pomba.api.simpledemo.onap.org
+org.onap.portal               portal@portal.onap.org       portal.onap             portal.api.simpledemo.onap.org
+org.onap.sdc                  sdc@sdc.onap.org             sdc.onap                sdc.api.simpledemo.onap.org
+org.onap.sdnc                 sdnc@sdnc.onap.org           sdnc.onap               sdnc.api.simpledemo.onap.org
+org.onap.so                   so@so.onap.org               so.onap                 so.api.simpledemo.onap.org
+org.onap.vfc                  vfc@vfc.onap.org             vfc.onap                vfc.api.simpledemo.onap.org
+org.onap.vid                  vid@vid.onap.org             vid.onap                vid.api.simpledemo.onap.org
+============================= ===========================  ======================= ==============================================
+
+*Note 1: FQDNs are set in AAF's Credential Artifact data, accessible in "Cred Details" from Namespace Page*
+
+*Note 2: Also, AAF itself is different, as it is not an ONAP only component... It is also expected to be used outside of ONAP.*
+
+If something goes wrong, and Certificate is not created, you can adjust the data, remove the data from the Container's /opt/app/osaaf/local dir, and it will generate again. ::
+
+  root@77777:/opt/app/osaaf/local# rm *
+  root@77777:/opt/app/osaaf/local# exit
+  $ bash agent.sh bash
+
+-------------
+Informational
+-------------
+
+There are two sets of Credentials at play here.  The ability to create the Certificate belongs to one of
+  
+  * The person responsible for the ID in the Organization 
+  * A delegated deployer
+
+It is expected in large organizations that Individual Employees are given the responsibility of an ID for an APP they are responsible for.
+
+  In ONAP test, to simplify create/tear-down environment... 
+     | The **Owner** is always "mmanager@people.osaaf.org". 
+     | The **Sponsor** is always "aaf_admin@people.osaaf.org".
+
+In a large org, there are probably many Operations teams to support many different apps.
+
+  In ONAP test, 
+     The **Deployer** is always set to "deployer@people.osaaf.org" for all Apps.
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/sections/installation/AAF_1_Prerequisites.rst b/docs/sections/installation/AAF_1_Prerequisites.rst
new file mode 100644
index 0000000..b91d912
--- /dev/null
+++ b/docs/sections/installation/AAF_1_Prerequisites.rst
@@ -0,0 +1,39 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+.. Copyright © 2017 AT&T Intellectual Property. All rights reserved.
+
+=====================
+Prerequisites for AAF
+=====================
+
+To *run* AAF, you need the following:
+  * Java 8+, openjdk is fine (see Version below)
+  * Cassandra
+     * a separate installation is fine
+     * Docker based AAF Envs offer a single instance Cassandra for convenience.  Single Instance Cassandra is **NOT** recommended for real AAF systems.
+  * Machine - one of the following
+     * Standalone Java Processes - Bare Metal or VMs.  No additional running environments necessary
+     * docker - typically available via packages for O/S
+     * kubernetes - various installs available
+
+To *build* AAF, you additionally need:
+  * Java 8+, openjdk is fine (see Version below)
+  * git
+  * maven
+  * for Container Based, you'll need Docker to build as well
+     * Note: 'minikube' works well to provide both Docker and Kubernetes Single Instance installations. 
+     
+
+---------------------------
+Current Technology Versions
+---------------------------
+
+ - Java(tm).  Version 8.121+
+   - Oracle Java previous to Oracle Java SE 8 to version 8 Update 121 is vulnerable to "SWEET32" attack.
+
+     1369383 - CVE-2016-2183 SSL/TLS: Birthday attack against 64-bit block ciphers (SWEET32)
+
+ - Cassandra, Version 3.11+
+
+ - X509 Certificates (at minimum to support HTTP/S TLS transactions (TLS1.1 and TLS1.2 are default, but can be configured).
+
diff --git a/docs/sections/installation/AAF_2_Env.rst b/docs/sections/installation/AAF_2_Env.rst
new file mode 100644
index 0000000..14c4a34
--- /dev/null
+++ b/docs/sections/installation/AAF_2_Env.rst
@@ -0,0 +1,35 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+.. Copyright © 2017 AT&T Intellectual Property. All rights reserved.
+
+AAF Environments
+=========================
+
+AAF can run globally, with high resilience in several different *kinds* of environments.  AAF runs globally, because, thanks to the Locator Component, you can place any network accessible element anywhere in the world, and find the best component entry FQDN and Port based on global Position (Latitude/Longitude).
+
+Env Types
+---------
+  1. Standalone O/S - AAF runs as Standalone Java Processes on bare metal or VMs.
+  2. Docker containers - AAF runs in containers, controlled by standard Docker Commands.
+  3. ONAP CSIT (CSIT env is an isolated Testing Environment, run within Jenkins for validation)
+  4. ONAP HEAT (Deprecated after Beijing)
+  5. Helm (Kubernetes) - this is a Standalone Helm method, suitable for external use of AAF as a Kubernetes Installation
+  6. ONAP OOM - AAF deployed as ONAP OOM component.  In this mode, AAF starts first, then provides configurations, certificates, etc to ONAP Components.
+
+Cassandra
+---------
+
+A key element of AAF's Global reach and resilience, is that it uses the Cassandra DB.  This automatically updates its data on a global scale, which allows AAF to have consistent data across geography.  
+
+AAF works best if you create a Network Topology based on "Datacenters" which you place in key geographies for your Entity.  You should organize your Cassanda Instances to be colocated with one or more AAF Service/Locator/Oauth instances for optimal performance. Futher, there should always be 3 or more Cassandra instances in each DataCenter (don't forget your "Seed Node" setup, see Cassandra Documentation).
+
+These kinds of setups are achievable fairly easily when using the Standalone O/S model, as it give you maximum control over what is deployed where.
+
+Container based Cassandras, and especially Kubernetes are more of a challenge as to work well, you need to dictate Seed Nodes, etc, but Kubernetes controls which machines any given Cassandra instance resides.
+
+These issues must be solved for best AAF results within your own installations.  For that reason, AAF can be configured to simply "point to" any Cassandra Instance scheme you setup.
+
+However, for testing purposes, requiring a Cassandra Setup beforehand is daunting and problematic, especially for automated testing scenarios, which are used extensively within the ONAP Community.
+
+For this reason, all of the Docker based Installations (#2-#6) come with a preconfigured with a single instance Cassandra, ready to run with ONAP data as soon as started.
+
diff --git a/docs/sections/installation/AAF_3.1_build.rst b/docs/sections/installation/AAF_3.1_build.rst
new file mode 100644
index 0000000..ec49c72
--- /dev/null
+++ b/docs/sections/installation/AAF_3.1_build.rst
@@ -0,0 +1,102 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+.. Copyright © 2017 AT&T Intellectual Property. All rights reserved.
+
+============================
+Building 
+============================
+*Note: this document assumes UNIX Bash Shell.  Being Java, AAF works in Windows, but you will have to create your own script/instruction conversions.*
+
+---------------------
+Building from Source 
+---------------------
+Choose the directory you wish to start in... This process will create an "authz" subdirectory::
+
+  $ mkdir -p ~/src
+  $ cd ~/src
+
+Use 'git' to 'clone' the master code::
+ 
+  $ git clone https://gerrit.onap.org/r/aaf/authz
+
+Change to that directory::
+
+  $ cd authz
+
+Use Maven to build::
+
+  << TODO, get ONAP Settings.xml>>
+  $ mvn install
+
+.. -----------------
+.. Standalone
+.. -----------------
+
+-----------------
+Docker Mode
+-----------------
+
+After you have successfully run maven, you will need a Cassandra.  If you don't have one, here are instructions for a Docker Standalone Cassandra.  For a *serious* endeavor, you need a multi-node Cassandra.
+
+From "authz"::
+
+  $ cd auth/auth-cass/src/main/cql
+  $ vi config.dat
+
+------------------
+Existing Cassandra
+------------------
+
+AAF Casablanca has added a table.  If you have an existing AAF Cassandra, do the following *ONCE* :
+
+### If Container Cassandra, add these steps, otherwise, skip
+$ docker container cp init2_1.cql aaf_cass:/tmp
+$ docker exec -it aaf_cass bash
+(docker) $ cd /tmp
+###
+$ cqlsh -f 'init2_1.cql'
+
+--------------------
+New Docker Cassandra
+--------------------
+
+Assuming you are in your src/authz directory::
+$ cd auth/auth-cass/docker
+$ bash dinstall.sh
+
+---------------------
+AAF Itself
+---------------------
+
+Assuming you are in your src/authz directory::
+
+| $ cd auth/docker
+| ### If you have not done so before (don't overwrite your work!)
+| $ cp d.props.init d.props
+
+You will need to edit and fill out the information in your d.props file.  Here is info to help
+
+**Local Env info** - These are used to load the /etc/hosts file in the Containers, so AAF is available internally and externally
+
+  =============== =============
+  Variable        Explanation
+  =============== =============
+  HOSTNAME        This must be the EXTERNAL FQDN of your host.  Must be in DNS or /etc/hosts
+  HOST_IP         This must be the EXTERNAL IP of your host. Must be accessible from "anywhere"
+  CASS_HOST       If Docker Cass, this is the INTERNAL FQDN/IP.  If external Cass, then DNS|/etc/hosts entry
+  aaf_env         This shows up in GUI and certs, to differentiate environments
+  aaf_register_as As pre-set, it is the same external hostname.
+  cadi_latitude   Use "https://bing.com/maps", if needed, to locate your current Global Coords
+  cadi_longitude  ditto
+  =============== =============
+
+------------------------------
+"Bleeding Edge" Source install
+------------------------------
+
+AAF can be built, and local Docker Images built with the following::
+
+  $ bash dbuild.sh
+
+Otherwise, just let it pull from Nexus
+
diff --git a/docs/sections/installation/AAF_7_Optional.rst b/docs/sections/installation/AAF_7_Optional.rst
new file mode 100644
index 0000000..60519dc
--- /dev/null
+++ b/docs/sections/installation/AAF_7_Optional.rst
@@ -0,0 +1,218 @@
+.. contents::
+   :depth: 3
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+.. Copyright © 2017 AT&T Intellectual Property. All rights reserved.
+
+=======================================
+Optional Technologies for special cases
+=======================================
+
+ - Build your own Certificate Authority for Bootstrapping and/or Certificate Manager component.
+   - openssl
+   - bash
+   
+Data Definitions
+----------------
+
+AAF Data Definitions
+
+ - AAF is Data Driven, and therefore, needs to have some structure around the Initial Data so that it can function.  You will need to define:
+
+Your Organization:
+ - Example:  Are you a company?  Do you already have a well known internet URL?
+ - If so, you should set up AAF Namespaces with this in mind.  Example:
+
+ - for "Kumquat Industries, LTD", with internet presence "kumquats4you.com" (currently, a fictitious name), you would want all your AAF Namespaces to start with:
+
+"com.kumquats4you" 
+The examples all use 
+
+"org.osaaf"
+
+However it is recommended that you change this once you figure out your organizations' structure.
+Your AAF Root Namespace
+This can be within your company namespace, i.e. 
+
+"com.kumquats4you.aaf"
+
+but you might consider putting it under different root structure.
+Again, the bootstrapping examples use:
+
+"org.osaaf.aaf" 
+ 
+While creating these, recognize that 
+2nd position of the Namespace indicates company/organization
+3rd+ position are applications within that company/organization
+
+"com.kumquats4you.dmaap"
+
+Following this "positional" structure is required for expected Authorization behavior.
+
+
+ILM (Identity Lifecycle Management)
+Neither Authentication nor Authorization make any sense outside the context of Identity within your Organization.
+
+Some organizations or companies will have their own ILM managers.
+
+If so you may write your own implementation of "Organization"
+Ensure the ILM of choice can be access real-time, or consider exporting the data into File Based mechanism (see entry)
+AAF comes with a "DefaultOrganization", which implements a file based localization of ILM in a simple text file
+
+Each line represents an identity in the organization, including essential contact information, and reporting structure 
+This file can be updated by bringing in the entire file via ftp or other file transfer protocol, HOWEVER
+Provide a process that
+Validates no corruption has occurred
+Pulls the ENTIRE file down before moving into the place where AAF Components will see it.
+Take advantage of UNIX File System behaviors, by MOVING the file into place (mv), rather than copying while AAF is Active
+Note: This file-based methodology has been shown to be extremely effective for a 1 million+ Identity organization
+TBA-how to add an entry
+
+TBA-what does "sponsorship mean"
+
+Initializing Default Implementation
+This is recommended for learning/testing AAF.  You can modify and save off this information for your Organizational use at your discretion.
+
+Extract Sample Configuration
+On your Linux box (creating/setting permissions as required)
+
+mkdir -p /opt/app/osaaf
+
+cd /opt/app/osaaf
+
+# Download AAF_sample_config_v1.zip (TBA)
+
+jar -xvf AAF_sample_config_v1.zip
+
+Certificate Authority
+You need to identify a SAFE AND SECURE machine when working with your own Certificate Authority.  Realize that if a hacker gets the private keys of your CA or Intermediate CAs, you will be TOTALLY Compromised.
+
+For that reason, many large companies will isolate any machines dealing with Certificates, and that is the recommendation here as well... However, this page cannot explain what works best for you.  JSCEP is an option if you have this setup already.
+
+If you choose to make your own CA, at the very least, once you create your private key for your Root Cert, and your Intermediate Certs, you might consider saving your Private Keys off line and removing from the exposed box.  Again, this is YOUR responsibility, and must follow your policy.
+
+
+
+IMPORTANT!  As you create Certificates for Identities, the Identities you use MUST be identities in your ILM.  See /opt/app/aaf/osaaf/data/identities.dat
+
+Creating your own Certificate Authority (if desired)
+1) Obtain all the Shell Scripts from the "conf/CA" directory which you can get the from the git repo.
+
+For this example, we'll put everything in /opt/app/osaaf
+
+mkdir /opt/app/osaaf/CA, if required
+
+$ cd /opt/app/osaaf/CA
+
+view README.txt for last minute info
+
+view and/or change "subject.aaf" for your needs. This format will be used on all generated certs from the CA.
+
+$ cat subject.aaf
+
+If you will be using PKCS11 option, review the "cfg.pkcs11" file as well
+
+$ cat cfg.pkcs11
+
+$ bash newca.sh
+
+Obviously, save off your passphrase in an encrypted place... how you do this is your procedure
+
+At this point, your Root CA information has been created.  If you want to start over, you may use "bash clean.sh"
+
+Create your Intermediate CAs
+2) You do NOT sign regular Cert requests with your Root.  You only sign with Intermediate CA.  The "intermediate.sh" will create a NEW Intermediate CA Directory and copy appropriate Shell scripts over.  Do this for as many Intermediate CAs as you need.
+
+$ bash newIntermediate.sh
+
+creates directories in order, intermediate_1, intermediate_2, etc.
+
+Use the Intermediate CA for creating Service/Identity Certs (can be utilized by Certman with LocalCA)
+3) When creating a Manual Certificate, DO THIS from the Intermediate CA needed
+
+$ cd intermediate_1
+
+4) Create initial Certificate for AAF
+
+IMPORTANT!  As you create Certificates for Identities, the Identities you use MUST be identities in your ILM.  See /opt/app/aaf/osaaf/data/identities.dat
+
+To create LOCALLY, meaning create the CSR, and submit immediately, do the following
+
+$ bash manual.sh <machine-name> -local
+
+FQI (Fully Qualified Identity):
+
+<identity from identities.dat>@<domain, ex: aaf.osaaf.org>
+
+To create Information suitable for Emailing, and signing the returned CSR
+
+$ bash manual.sh <machine-name>
+
+FQI (Fully Qualified Identity):
+
+<identity from identities.dat>@<domain, ex: aaf.osaaf.org>
+
+5) Create p12 file for AAF
+
+REMAIN in the intermediate directory...
+
+$ bash p12.sh <machine-name>
+
+Copy initializations to Host Machine
+AAF is setup so it can run 
+
+On the O/S, using Java
+On Docker
+On K8s
+In each case, even for Docker/K8s, we utilize the File O/S for host specific information.   This is because
+
+Many things are Host Specific
+The Hostname required for TLS interactions
+Cassandra specific information (when external/clustered)
+Logging (if logging is done in container, it will be lost if container goes down)
+To make things simpler, we are assuming that the file structure will be "/opt/app/osaaf".  The code supports changing this, but documentation will wait until use cases arises for ONAP.
+
+Steps:
+
+1) Copy "osaaf.zip" to your Host Machine, where osaaf.zip is provided by AAF SME. // TODO POST SAMPLE HERE
+
+2) Copy your "p12" file generated by your CA (see above), and place in your "certs" directory
+
+3) SSH (or otherwise login) to your Docker/K8s Host Machine
+
+4) setup your directories (you might need to be root, then adjust what you need for O/S File Permissions
+
+$ mkdir /opt/app/osaaf
+
+$ cd /opt/app/osaaf
+
+$ mkdir cred logs
+
+$ unzip ~/osaaf.zip
+
+$ mv ~/<p12 file from CA above> cred
+
+$ 
+
+Unzip the "osaaf.zip" so it goes into the /opt/app/osaaf directory (should have "etc", "data", "public" and "certs" directories)
+
+4) Modify "org.osaaf.props" to have 
+
+
+
+Load Data and/or Meta-Data into Cassandra
+Setting this initial Data can be done directly onto Cassadra using "cqlsh" using the following "cql" files:
+
+init<version>.cql (whatever is latest in the "zip" file)
+osaaf.cql
+| This file contains initial Authorization Structures, see AAF Data Structures. 
+| This is where you would modify your own initial Structures.
+
+Build Source
+(if not done already)
+
+Run Java
+Note: If you have a Kubernets requirement (support), it is STILL RECOMMENDED you run AAF as stand-alone Java Components on your system, and work out any modifications required BEFORE trying to run in Kubernetes.
+
+TBA <java -Dcadi_prop_files=/opt/app/osaaf/etc/org.osaaf.locator.props -cp <path> File>
+