summaryrefslogtreecommitdiffstats
path: root/docs
diff options
context:
space:
mode:
Diffstat (limited to 'docs')
-rw-r--r--docs/sections/architecture/security.rst4
-rw-r--r--docs/sections/installation/Bootstrapping-AAF-Components.rst2
-rw-r--r--docs/sections/installation/client_vol.rst2
3 files changed, 4 insertions, 4 deletions
diff --git a/docs/sections/architecture/security.rst b/docs/sections/architecture/security.rst
index 93247899..d1809935 100644
--- a/docs/sections/architecture/security.rst
+++ b/docs/sections/architecture/security.rst
@@ -12,7 +12,7 @@ The service side is always compute process, but the client can be of two types:
* People (via browser, or perhaps command line tool)
* Compute process talking to another computer process.
-In larger systems, it is atypical to have just one connection, but will the call initiated by the initial actor will cause additional calls after it. Thus, we demonstrate both a client call, and a subsequent call in the following:
+In larger systems, it is a typical to have just one connection, but will the call initiated by the initial actor will cause additional calls after it. Thus, we demonstrate both a client call, and a subsequent call in the following:
Thus, the essential building blocks of any networked system is made up of a caller and any subsquent calls.
@@ -126,7 +126,7 @@ The AAF Suite provides the following elements:
The Organization
----------------
-AAF is only a tool to reflect the Organization it is setup for. AAF does not, for instance, know what IDs are acceptable to a particular company. Every Organization (or Company) will also likely have its own Certificate Authority and DNS. Most importantly, each Organzation will have a hierarchy of who is responsible for any give person or application.
+AAF is only a tool to reflect the Organization it is setup for. AAF does not, for instance, know what IDs are acceptable to a particular company. Every Organization (or Company) will also likely have its own Certificate Authority and DNS. Most importantly, each Organization will have a hierarchy of who is responsible for any give person or application.
* AAF's Certman connects to the Organization's CA via SCEP protocol (Others can be created as well)
* AAF ties into the Organizational hierarchy. Currently, this is through a feed of IDs and relationships.
diff --git a/docs/sections/installation/Bootstrapping-AAF-Components.rst b/docs/sections/installation/Bootstrapping-AAF-Components.rst
index 2bb329d6..79b2fffc 100644
--- a/docs/sections/installation/Bootstrapping-AAF-Components.rst
+++ b/docs/sections/installation/Bootstrapping-AAF-Components.rst
@@ -145,7 +145,7 @@ $ cd /opt/app/osaaf/CA
view README.txt for last minute info
-view an/or change "subject.aaf" for your needs. This format will be used on all generated certs from the CA.
+view and/or change "subject.aaf" for your needs. This format will be used on all generated certs from the CA.
$ cat subject.aaf
diff --git a/docs/sections/installation/client_vol.rst b/docs/sections/installation/client_vol.rst
index fc33e1bb..059c1d23 100644
--- a/docs/sections/installation/client_vol.rst
+++ b/docs/sections/installation/client_vol.rst
@@ -62,7 +62,7 @@ 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 deployer@people.osaaf.org. In a REAL system, this would be a person or process
+Deployer's FQI DEPLOY_FQI In a REAL system, this would be a person or process. For ONAP Testing, the id is deploy@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