Update formatting and wording

A21-Service-Config-Error-Handling.md

@@ -28,38 +28,42 @@ certain parts.
 
 ## Proposal
 
-If a resolved service config is badly formatted or contains invalid values for
-known fields, the client should ignore that service config in its entirety.
-Unknown fields in the service config should be ignored. If there was a service
-config that the client was previously using, it should continue using those
-parameters when communicating with the service. If there was no service config
-being used, then the client should continue behaving as if it never received a
-service config update from the resolver. On the other hand, if it is a new
-client, then the client should fail to start, i.e., not act on the resolution
-result till a valid service config is received.
-
-If a default service config is provided (as a channel argument), and the
-received service config is invalid, the client should fall back on the default
-service config if there was no previously accepted service config. It should as
-before, fail to start if the default service config has not been set.
-
-Based on this proposal, if new load balancing policies are to be introduced and
-the rollout is not controlled, then older clients will start discarding entire
-service configs due to the load balancing policy being unknown. To make this
-rollout process easier, load balancing policy could be changed into a list of
-policies. The clients would iterate through the list and use the first policy
-that it knows. If none of the policies are known, the client would treat the
-service config as invalid.
-
-For example,
-
-“loadBalancingPolicy” : [
-    “NewUnknownPolicy”,
-    “RoundRobin”
-  ]
-
-In this case, since the client does not understand the first policy, it would
-use RoundRobin.
+In brief, if a service config (JSON formatted) received is badly formatted or
+contains invalid values for known fields, the client should ignore that service
+config in its entirety. This section enumerates the exact steps that clients
+need to take on receiving a new config.
+
+### Behavior on receiving a new gRPC Config
+
+1. A gRPC config can have multiple service configs. When multiple service configs
+are available, clients choose the service config to use based on the proposal
+[here](A2-service-configs-in-dns.md#canarying-changes).
+2. On choosing a service config, the client validates the service config based on
+the criteria outlined in the section below.
+3. If the service config is valid, the client uses the configuration provided.
+4. If the service config is invalid, the clients should reject the received
+config in its entirety and do different things depending on its state and
+configuration.
+	1. If it previously received an update with a valid service config, it should
+	continue using the configuration from that config.
+	2. If this is a new client or a client which has not yet received a valid
+	service config -
+		1. It uses the default service config, if configured. Note that, an empty 
+		default service config is a valid service config.
+		2. If it does not have a default service config, it should treat the 
+		resolution attempt as having failed (e.g., for a polling-based resolver, 
+		it should retry the query after appropriate backoff). In other words, 
+		the channel will remain in state TRANSIENT_FAILURE until a valid service 
+		config is received.
+
+### Criteria to determine the validity of a service config
+
+A valid service config needs to be well formatted, i.e., the JSON representation
+of the service config needs to be in a valid JSON format. If the service config
+is well formatted, the client validates each field that it recognizes while
+ignoring the unknown fields, i.e., unknown fields do not affect validation. For
+known fields, valid values are defined by the field itself. If any of the known
+fields fails in validation, the entire service config is deemed invalid.
 
 ## Rationale
 
@@ -82,9 +86,22 @@ Examples of invalid service configs :
 
 * Fields with invalid values are not allowed
 “serviceConfig” : {
-      “loadBalancingPolicy” : “UnknownPolicy”
+  “loadBalancingPolicy” : “UnknownPolicy”
+}
+
+Note that loadBalancingPolicy is deprecated in favor of loadBalancingConfig,
+which provides a list of LB policies with the client selecting the first policy
+it supports. If it doesn’t understand any of the policies, it is treated as
+invalid, and the entire service config is rejected.
+
+“serviceConfig” : {
+  “loadBalancingConfig” : [
+    “UnknownPolicy1” : {},
+    “UnknownPolicy2” : {}
+  ]
 }
 
+
 ## Implementation
 
 C -