update proposal header

Author: jvmncs

rfcs/20200427-tff-aggregators-placement.md

@@ -1,24 +1,21 @@
 # TF Federated Aggregators Placement
 
-| Status        | (Proposed / Accepted / Implemented / Obsolete)       |
+| Status        | Proposed       |
 :-------------- |:---------------------------------------------------- |
-| **RFC #**     | [TF Federated Aggregators Placement](https://github.com/tensorflow/community/pull/NNN) (TODO update when you have community PR #)|
+| **RFC #**     | https://github.com/tensorflow/community/pull/TODO    |
 | **Author(s)** | Jason Mancuso ([email protected])                |
 | **Sponsor**   | Michael Reneer ([email protected])            |
-| **Updated**   | 2020-05-04  (TODO)                                   |
+| **Updated**   | 2020-05-04                                           |
 
 ## Objective
 
 This document proposes adding an explicit `tff.AGGREGATORS` placement to the
-Federated Core (FC) in TensorFlow Federated (TFF). This would allow users to express
-custom aggregation protocols directly in TFF without adding unnecessary
-assumptions about where aggregation functions must be placed and computed.
+Federated Core (FC) in TensorFlow Federated (TFF). This would lift the requirement
+that all aggregations be computed on `tff.SERVER`, while still allowing users to
+express custom aggregation logic using FC & TF.
 
 ## Motivation
 
-*Why this is a valuable problem to solve? What background information is needed
-to show how this design addresses the problem?*
-
 When approaching federated learning with an eye for security or privacy, it is
 useful to divide federated computation into two categories: computations performing
 aggregations, and computations performing on-device computation.  Security and
@@ -65,12 +62,6 @@ by working directly with federated values placed on `tff.AGGREGATORS`.
 
 ## Design Proposal
 
-*This is the meat of the document, where you explain your proposal. If you have
-multiple alternatives, be sure to use sub-sections for better separation of the
-idea, and list pros/cons to each approach. If there are alternatives that you
-have eliminated, you should also list those here, and explain why you believe
-your chosen approach is superior.
-
 Adding the `tff.AGGREGATORS` placement for federated types involves adding a new `Placement` and `PlacementLiteral`, and then extending the compiler to recognize federated values with this placement when computing intrinsics. The compiler generally recognizes separate intrinsics by placement; e.g., `tff.federated_value(value, placement)` is actually interpreted by the compiler as `federated_value_at_clients(value)` or `federated_value_at_server(value)`, depending on the provided `placement`. This means we we will want to add new intrinsics that correspond to `tff.AGGREGATORS`, e.g. `federated_value_at_aggregators`.
 
 Existing federated computation that will need modification fall into the two categories below:
@@ -109,7 +100,7 @@ We also briefly considered the name `tff.AGGREGATOR` instead of `tff.AGGREGATORS
 This is an additive improvement to the FC, so there should be no performance implications for existing functionality. TFF is designed to support this kind of addition with minimal overhead. New functionality could be less performant relative to current practices, but only from overhead inherent to adding a new node to a distributed computation.
 
 ### Dependencies
-This change brings no new dependencies. Since this proposal adds a new federated type, any project that enforces limits based on the current federated types may have to be updated. We will work with the TFF team to identify any affected projects and limit any breaking changes.
+This change brings no new dependencies. Since this proposal adds a new federated type, any project that enforces limits based on the current federated types may need an update. We will work to identify any affected projects and limit breaking changes as much as possible.
 
 ### Engineering Impact
 This code will likely bring marginal increases to build and test time, but changes to binary size should be negligible. Executor factories including a stack for the `tff.AGGREGATORS` placement will experience a nontrivial increase in startup time, but not all executor factories will need to include a stack for this placement.