[FAB-17411] Update Fabric versions where necessary

Change-Id: Iad3d1c409fb864c211a34388711234cddac187b2
Signed-off-by: joe-alewine <Joe.Alewine@ibm.com>

docs/source/access_control.md

@@ -281,21 +281,5 @@ whatever you want them to be. As a result, it's important to keep track of these
 policies to ensure that the ACLs for peer proposals are not impossible to satisfy
 (unless that is the intention).
 
-#### Migration considerations for customers using the experimental ACL feature
-
-Previously, the management of access control lists was done in an `isolated_data`
-section of the channel creation transaction and updated via `PEER_RESOURCE_UPDATE`
-transactions. Originally, it was thought that the `resources` tree would handle the
-update of several functions that, ultimately, were handled in other ways, so
-maintaining a separate parallel peer configuration tree was judged to be unnecessary.
-
-Migration for customers using the experimental resources tree in v1.1 is possible.
-Because the official v1.2 release does not support the old ACL methods, the network
-operators should shut down all their peers.  Then, they should upgrade them to v1.2,
-submit a channel reconfiguration transaction which enables the v1.2 capability and
-sets the desired ACLs, and then finally restart the upgraded peers.  The restarted
-peers will immediately consume the new channel configuration and enforce the ACLs as
-desired.
-
 <!--- Licensed under Creative Commons Attribution 4.0 International License
 https://creativecommons.org/licenses/by/4.0/ -->

docs/source/capability_requirements.rst

@@ -24,35 +24,13 @@ Capabilities are set as part of the channel configuration (either as part of the
 initial configuration -- which we'll talk about in a moment -- or as part of a
 reconfiguration).
 
-.. note:: For a tutorial that shows how to update a channel configuration, check
-          out :doc:`channel_update_tutorial`. For an overview of the different
-          kinds of channel updates that are possible, check out :doc:`config_update`.
+.. note:: For more information about how to update a channel configuration, check
+          out :doc:`config_update`.
 
 Because new channels copy the configuration of the ordering system channel by
 default, new channels will automatically be configured to work with the orderer
 and channel capabilities of the ordering system channel and the application
-capabilities specified by the channel creation transaction. Channels that already
-exist, however, must be reconfigured.
-
-The schema for the Capabilities value is defined in the protobuf as:
-
-.. code:: bash
-
-  message Capabilities {
-        map<string, Capability> capabilities = 1;
-  }
-
-  message Capability { }
-
-As an example, rendered in JSON:
-
-.. code:: bash
-
-  {
-      "capabilities": {
-          "V1_1": {}
-      }
-  }
+capabilities specified by the channel creation transaction.
 
 Capabilities in an Initial Configuration
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -61,50 +39,11 @@ In the ``configtx.yaml`` file distributed in the ``config`` directory of the rel
 artifacts, there is a ``Capabilities`` section which enumerates the possible capabilities
 for each capability type (Channel, Orderer, and Application).
 
-The simplest way to enable capabilities is to pick a v1.1 sample profile and customize
-it for your network. For example:
-
-.. code:: bash
-
-    SampleSingleMSPRaftV1_1:
-        Capabilities:
-            <<: *GlobalCapabilities
-        Orderer:
-            <<: *OrdererDefaults
-            Organizations:
-                - *SampleOrg
-            Capabilities:
-                <<: *OrdererCapabilities
-        Consortiums:
-            SampleConsortium:
-                Organizations:
-                    - *SampleOrg
-
 Note that there is a ``Capabilities`` section defined at the root level (for the channel
-capabilities), and at the Orderer level (for orderer capabilities). The sample above uses
-a YAML reference to include the capabilities as defined at the bottom of the YAML.
+capabilities), and at the Orderer level (for orderer capabilities).
 
 When defining the orderer system channel there is no Application section, as those
-capabilities are defined during the creation of an application channel. To define a new
-channel's application capabilities at channel creation time, the application admins should
-model their channel creation transaction after the ``SampleSingleMSPChannelV1_1`` profile.
-
-.. code:: bash
-
-   SampleSingleMSPChannelV1_1:
-        Consortium: SampleConsortium
-        Application:
-            Organizations:
-                - *SampleOrg
-            Capabilities:
-                <<: *ApplicationCapabilities
-
-Here, the Application section has a new element ``Capabilities`` which references the
-``ApplicationCapabilities`` section defined at the end of the YAML.
-
-.. note:: The capabilities for the Channel and Orderer sections are inherited from
-          the definition in the ordering system channel and are automatically included
-          by the orderer during the process of channel creation.
+capabilities are defined during the creation of an application channel.
 
 .. Licensed under Creative Commons Attribution 4.0 International License
    https://creativecommons.org/licenses/by/4.0/

docs/source/couchdb_as_state_database.rst

@@ -253,7 +253,7 @@ the following steps to avoid long queries:
 
 - For range queries, composite key queries, and JSON queries:
 
-    * Utilize paging support (as of v1.3) instead of one large result set.
+    * Utilize paging support instead of one large result set.
 
 - If you want to build a dashboard or collect aggregate data as part of your
   application, you can query an off-chain database that replicates the data

docs/source/kafka_raft_migration.md

@@ -9,7 +9,7 @@ describes the channel update process in detail.**
 
 For users who want to transition channels from using Kafka-based ordering
 services to [Raft-based](./orderer/ordering_service.html#Raft) ordering services,
-v1.4.2 allows this to be accomplished through a series of configuration update
+nodes at v1.4.2 or higher allow this to be accomplished through a series of configuration update
 transactions on each channel in the network.
 
 This tutorial will describe this process at a high level, calling out specific
@@ -245,4 +245,4 @@ There are a few states which might indicate migration has failed:
 3. The attempt to flip to `STATE_NORMAL` mode on the system channel fails.
 
 <!--- Licensed under Creative Commons Attribution 4.0 International License
-https://creativecommons.org/licenses/by/4.0/) -->
+https://creativecommons.org/licenses/by/4.0/) -->

docs/source/orderer/ordering_service.md

@@ -213,7 +213,6 @@ implementation the node will be used in), check out [our documentation on standi
   up and manage than Kafka-based ordering services, and their design allows
   different organizations to contribute nodes to a distributed ordering service.
 
-
 * **Kafka** (deprecated in v2.0)
 
   Similar to Raft-based ordering, Apache Kafka is a CFT implementation that uses

docs/source/private-data/private-data.md

@@ -10,7 +10,7 @@ separate channels in each of these cases creates additional administrative overh
 cases in which you want all channel participants to see a transaction while keeping
 a portion of the data private.
 
-That's why, starting in v1.2, Fabric offers the ability to create
+That's why Fabric offers the ability to create
 **private data collections**, which allow a defined subset of organizations on a
 channel the ability to endorse, commit, or query private data without having to
 create a separate channel.

docs/source/whatis.md

@@ -12,7 +12,7 @@ have followed in its footsteps. Ethereum, an alternative cryptocurrency, took a
 different approach, integrating many of the same characteristics as Bitcoin but
 adding _smart contracts_ to create a platform for distributed applications.
 Bitcoin and Ethereum fall into a class of blockchain that we would classify as
-_public permissionless_ blockchain technology.  Basically, these are public
+_public permissionless_ blockchain technology. Basically, these are public
 networks, open to anyone, where participants interact anonymously.
 
 As the popularity of Bitcoin, Ethereum and a few other derivative technologies
@@ -97,7 +97,7 @@ deployed with roughly the same operational cost as any other distributed system.
 The combination of these differentiating design features makes Fabric one of
 the **better performing platforms** available today both in terms of transaction
 processing and transaction confirmation latency, and it enables **privacy and confidentiality** of transactions and the smart contracts (what Fabric calls
-  "chaincode") that implement them.
+"chaincode") that implement them.
 
 Let's explore these differentiating features in more detail.
 
@@ -223,9 +223,7 @@ scale of the system. This first phase also **eliminates any non-determinism**,
 as inconsistent results can be filtered out before ordering.
 
 Because we have eliminated non-determinism, Fabric is the first blockchain
-technology that **enables use of standard programming languages**. In the 1.1.0
-release, smart contracts can be written in either Go or Node.js, while there are
-plans to support other popular languages including Java in subsequent releases.
+technology that **enables use of standard programming languages**.
 
 ## Privacy and Confidentiality
 
@@ -242,7 +240,7 @@ cases. For example, in a network of supply-chain partners, some consumers might
 be given preferred rates as a means of either solidifying a relationship, or
 promoting additional sales. If every participant can see every contract and
 transaction, it becomes impossible to maintain such business relationships in a
-completely transparent network -- everyone will want the preferred rates!
+completely transparent network --- everyone will want the preferred rates!
 
 As a second example, consider the securities industry, where a trader building
 a position (or disposing of one) would not want her competitors to know of this,
@@ -268,17 +266,14 @@ might explore approaches that restrict the distribution of confidential
 information exclusively to authorized nodes.
 
 Hyperledger Fabric, being a permissioned platform, enables confidentiality
-through its channel architecture. Basically, participants on a Fabric network
-can establish a "channel" between the subset of participants that should be
-granted visibility to a particular set of transactions. Think of this as a
-network overlay. Thus, only those nodes that participate in a channel have
-access to the smart contract (chaincode) and data transacted, preserving the
-privacy and confidentiality of both.
-
-To improve upon its privacy and confidentiality capabilities, Fabric has
-added support for [private data](./private-data/private-data.html) and is working
-on zero knowledge proofs (ZKP) available in the future. More on this as it
-becomes available.
+through its channel architecture and [private data](./private-data/private-data.html)
+feature. In channels, participants on a Fabric network establish a sub-network
+where every member has visibility to a particular set of transactions. Thus, only
+those nodes that participate in a channel have access to the smart contract
+(chaincode) and data transacted, preserving the privacy and confidentiality of
+both. Private data allows collections between members on a channel, allowing
+much of the same protection as channels without the maintenance overhead of
+creating and maintaining a separate channel.
 
 ## Pluggable Consensus
 
@@ -290,10 +285,9 @@ particular deployment or solution. This modular architecture allows the platform
 to rely on well-established toolkits for CFT (crash fault-tolerant) or BFT
 (byzantine fault-tolerant) ordering.
 
-Fabric currently offers two CFT ordering service implementations. The first is
+Fabric currently offers a CFT ordering service implementation
 based on the [`etcd` library](https://coreos.com/etcd/) of the [Raft protocol](https://raft.github.io/raft.pdf).
-The other is [Kafka](https://kafka.apache.org/) (which uses [Zookeeper](https://zookeeper.apache.org/)
-internally). For information about currently available ordering services, check
+For information about currently available ordering services, check
 out our [conceptual documentation about ordering](./orderer/ordering_service.html).
 
 Note also that these are not mutually exclusive. A Fabric network can have
@@ -304,22 +298,11 @@ requirements.
 
 Performance of a blockchain platform can be affected by many variables such as
 transaction size, block size, network size, as well as limits of the hardware,
-etc. The Hyperledger community is currently developing [a draft set of measures](https://docs.google.com/document/d/1DQ6PqoeIH0pCNJSEYiw7JVbExDvWh_ZRVhWkuioG4k0/edit#heading=h.t3gztry2ja8i) within the Performance and Scale working group, along
-with a corresponding implementation of a benchmarking framework called
-[Hyperledger Caliper](https://wiki.hyperledger.org/projects/caliper).
-
-While that work continues to be developed and should be seen as a definitive
-measure of blockchain platform performance and scale characteristics, a team
-from IBM Research has published a
-[peer reviewed paper](https://arxiv.org/abs/1801.10228v1) that evaluated the
-architecture and performance of Hyperledger Fabric. The paper offers an in-depth
-discussion of the architecture of Fabric and then reports on the team's
-performance evaluation of the platform using a preliminary release of
-Hyperledger Fabric v1.1.
-
-The benchmarking efforts that the research team did yielded a significant
-number of performance improvements for the Fabric v1.1.0 release that more than
-doubled the overall performance of the platform from the v1.0.0 release levels.
+etc. The Hyperledger Fabric [Performance and Scale working group](https://wiki.hyperledger.org/display/PSWG/Performance+and+Scale+Working+Group)
+currently works on a benchmarking framework called [Hyperledger Caliper](https://wiki.hyperledger.org/projects/caliper).
+
+Several research papers have been published studying and testing the performance
+capabilities of Hyperledger Fabric. The latest [scaled Fabric to 20,000 transactions per second](https://arxiv.org/abs/1901.00910).
 
 ## Conclusion
 
@@ -332,10 +315,10 @@ enable the platform to support a wide range of industry use cases ranging from
 government, to finance, to supply-chain logistics, to healthcare and so much
 more.
 
-Hyperledger Fabric is the most active of the
-Hyperledger projects. The community building around the platform is growing
-steadily, and the innovation delivered with each successive release far
-out-paces any of the other enterprise blockchain platforms.
+Hyperledger Fabric is the most active of the Hyperledger projects. The community
+building around the platform is growing steadily, and the innovation delivered
+with each successive release far out-paces any of the other enterprise blockchain
+platforms.
 
 ## Acknowledgement