[FAB-9836] Glossary

To avoid scope creep, 
please only comment on the
following entries in the
glossary:
- Added ACL
- Updated Policy, Anchor Peer
Leading Peer

Change-Id: I14cc55b180120522900914b4193095fbc6be8f50
Signed-off-by: pama-ibm <pama@ibm.com>

Author: pamandrejko

docs/source/glossary.rst

@@ -20,7 +20,24 @@ Each organization added to a channel should identify at least one of its
 peers as an anchor peer. The anchor peer address is stored in the
 configuration block of the channel. Each organization that has a peer
 should have at least one (there can be more than one) of its peers
-defined as an anchor peer.
+defined as an anchor peer. Thus, the anchor peer is used as the entry point
+from another organization's peer on the same channel to get the message
+delivered to each of the peers in the anchor peer's org.
+
+.. _glossary_ACL:
+
+ACL
+---
+
+Access Control List. Used to associate policies with specific resources.
+Access control lists are defined in the ``configtx.yaml`` file, used by
+configtxgen to build channel configurations. An ACL is formatted as a key-value
+pair consisting of a resource function name followed by the name of the group
+with access to the resource. A set of default ACLs are provided in the
+``configtx.yaml`` file and  can be overridden by editing the configtx.yaml
+for the orderer system channel (new channels copy the configuration of the
+orderer system channel by default) or the ``configtx.yaml`` for a specific
+channel.
 
 .. _Block:
 
@@ -227,11 +244,11 @@ invoke, and an array of arguments.
 Leading Peer
 ------------
 
-Each Member_ can own multiple peers on each channel that
-it subscribes to. One of these peers is serves as the leading peer for the channel,
+Each Organization_ can own multiple peers on each channel that
+it subscribes to. One of these peers serves as the leading peer for the channel,
 in order to communicate with the network ordering service on behalf of the
-member. The ordering service "delivers" blocks to the leading peer(s) on a
-channel, who then distribute them to other peers within the same member cluster.
+organization. The ordering service "delivers" blocks to the leading peer(s) on a
+channel, who then distribute them to other peers within the same org cluster.
 
 .. _Ledger:
 
@@ -327,8 +344,24 @@ read/write operations to the ledger.  Peers are owned and maintained by members.
 Policy
 ------
 
-There are policies for endorsement, validation, chaincode
-management and network/channel management.
+How members come to agreement on accepting or rejecting changes to the network
+or a channel. Policies include criteria for adding or removing members or peers
+from the network. They also include the requirements needed to update a channel
+or endorsements required to instantiate chaincode and have a transaction
+validated by a channel.
+
+Policies are fundamental to the way Fabric works because they allow the identity
+associated with a request to be checked against the policy associated with the
+resource (such as a chaincode API) needed to fulfill the request.  There are two
+types of policies -- ``Signature`` and ``ImplicitMeta``.  ``Signature`` policies
+define specific users who must sign in order for a policy to be satisfied such
+as ``Org1.Peer OR Org2.Peer``.  ``ImplicitMeta`` policies are only valid in the
+context of configuration and aggregate the result of policies deeper in the
+configuration hierarchy which are ultimately defined by Signature policies.
+They use a different syntax, for example  ``"MAJORITY Admins``.  Policies can be
+defined globally for the entire network in the ``configtx.yaml`` file under
+``Application: Policies``,  but channel specific policies may also be defined in
+the channel profile section as well.
 
 .. _Proposal: