diff options
Diffstat (limited to 'docs')
-rw-r--r-- | docs/sections/architecture/security.rst | 4 | ||||
-rw-r--r-- | docs/sections/installation/Bootstrapping-AAF-Components.rst | 2 | ||||
-rw-r--r-- | docs/sections/installation/client_vol.rst | 2 |
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 |