ontinue filling in the config doc.

_includes/doc-side-concepts-nav.html

@@ -5,6 +5,6 @@
 	<li class="doc-side-nav-list-item"><a href="{{ site.baseurl }}/docs/concepts/model.html" {% if current[3] == 'model.html' %}class='current'{% endif %}>Service Model</a></li>
 	<li class="doc-side-nav-list-item"><a href="{{ site.baseurl }}/docs/concepts/attributes.html" {% if current[3] == 'attributes.html' %}class='current'{% endif %}>Attributes</a></li>
 	<li class="doc-side-nav-list-item"><a href="{{ site.baseurl }}/docs/concepts/mixer.html" {% if current[3] == 'mixer.html' %}class='current'{% endif %}>Mixer</a></li>
-	<li class="doc-side-nav-list-item"><a href="{{ site.baseurl }}/docs/concepts/config.html" {% if current[3] == 'config.html' %}class='current'{% endif %}>Configuration</a></li>
+	<li class="doc-side-nav-list-item"><a href="{{ site.baseurl }}/docs/concepts/config.html" {% if current[3] == 'config.html' %}class='current'{% endif %}>Mixer Configuration Model</a></li>
   <li class="doc-side-nav-list-item"><a href="{{ site.baseurl }}/docs/concepts/writing-config.html" {% if current[3] == 'writing-config.html' %}class='current'{% endif %}>Writing Configuration</a></li>
  </ul>

docs/concepts/config.md

@@ -1,6 +1,6 @@
 ---
 title: Mixer Configuration
-headline: Configuring the mixer
+headline: Mixer Configuration Model
 sidenav: doc-side-concepts-nav.html
 bodyclass: docs
 layout: docs
@@ -319,7 +319,22 @@ Refer to *TBD* for the full attribute expression syntax.
 
 ### Scopes and Selectors
 
-*TBD*
+Configuration scopes make it possible to organize various blocks of configuration state in a
+hierarchy. Blocks of configuration can only reference other configuration artifacts
+within its own scope or within parent scopes, but not in sibling or descendant scopes. 
+
+Scoping is designed to enable sharing of a single Istio deployment within the context of a broad
+organization. Orthogonal teams within the organization can operate in different scopes, preventing
+one team's configuration from impacting another team's. Because artifacts declared higher-up in the
+hierarchy are available to descendants in the hierarchy, it also enables centralized configuration
+where it makes sense within the organization.
+
+The exact composition and depth of the hierarchy is entirely determined by the configuration state. Let's
+look at some examples:
+
+```yaml
+
+```
 
 ## Configuration API
 

docs/concepts/mixer.md

@@ -69,6 +69,7 @@ configured descriptors.
 
 An example can help clarify the concepts. Let's consider the `MetricDescriptor` type which is defined as follows:
 
+```proto
     message MetricDescriptor {
       string name = 1;
       string display_name = 2;
@@ -84,24 +85,27 @@ An example can help clarify the concepts. Let's consider the `MetricDescriptor`
       ValueType value = 5;
       repeated LabelDescriptor labels = 6;
     }
+```
 
 Within a deployment configuration, you can declare a metric descriptor using a snippet of YAML:
 
-    name: request_count
-    kind: COUNTER
-    value: INT64
-    description: request count by source, target, service, and code
-    labels:
-    - name: source
-      valueType: STRING
-    - name: target
-      valueType: STRING
-    - name: service
-      valueType: STRING
-    - name: method
-      valueType: STRING
-    - name: response_code
-      valueType: INT64
+```yaml
+name: request_count
+kind: COUNTER
+value: INT64
+description: request count by source, target, service, and code
+labels:
+- name: source
+  valueType: STRING
+- name: target
+  valueType: STRING
+- name: service
+  valueType: STRING
+- name: method
+  valueType: STRING
+- name: response_code
+  valueType: INT64
+```
 
 This is declaring a descriptor called `request_count`. Because of the kind and value fields, policy objects associated with this
 descriptor represent 64-bit integer counters. Additionally, each associated policy object will be uniquely identified via the 5
@@ -116,14 +120,16 @@ listed labels. Producing a policy object for such a descriptor requires 6 pieces
 
 Here is an example snippet of Istio configuration which produces a policy object for the above descriptor:
 
-    descriptor_name: request_count
-    value: "1"
-    labels:
-      source: source.name | "unknown"
-      target: target.name | "unknown"
-      service: api.name | "unknown"
-      method: api.method | "unknown"
-      response_code: response.code | 200
+```yaml
+descriptor_name: request_count
+value: "1"
+labels:
+  source: source.name | "unknown"
+  target: target.name | "unknown"
+  service: api.name | "unknown"
+  method: api.method | "unknown"
+  response_code: response.code | 200
+```
 
 Many such policy objects are created as part of attribute processing and they ultimately serve as input to
 adapters.