[netmod] missing sections

[Phil Shafer <[e-mail]>]

There were two sections in the last arch draft that were missing.
See the attached delta for the new text.  Unfortunately I cannot
post a new draft.

Thanks, 
 Phil

------

 ** Modeler
 
-(No clue what needs said here; lots to say, but what's important?)
+The modeler's role constructing a model based on their in-depth
+knowledge of the problem domain being modeled.  This model should
+be as simple as possible, but should balance complexity with
+expressiveness.  The organization of the model should target not only
+the current model, but should allow for extensibility from other
+modules and for adaptability to future changes.
 
 Additional modeling issues are discussed in ^modeling^.
 
@@ -680,8 +684,50 @@
 
 ** Default Values
 
-(With all the discussion on this point, it needs to be mentioned here.)
+The concept of default values is simple, but their details,
+representation, and interaction with configuration data can be
+difficult issues.  NETCONF leaves default values as a data model
+issue, and YANG gives flexibility to the device implementation in
+terms of how default values are handled.  The requirement is that the
+device "MUST operationally behave as is if the leaf was present in the
+data tree with the default value as its value".  This gives the device
+implementation choices in how default values are handled.
 
+One choice is to view the configuration as a set of instructions for
+how the device should be configured.  If a data value is given as part
+of those instructions is the default value, then it should be retained
+as part of the configuration, but if it not explicitly given, then the
+value is not considered to be part of configuration.
+
+Another choice is to trim values that are identical to the default
+values, implicitly removing them from the configuration database.
+The act of setting a leaf to it's default value effectively deletes
+that leaf.
+
+The device could also choose to report all default values, regardless
+of whether they were explicitly set.  This choice eases the work of
+a client that needs default values, but may significantly increase the
+size of the configuration data.
+
+These choices reflect the default handling schemes of widely deployed
+networking devices and supporting them allows YANG to reduce
+implementation and deployment costs of YANG-based models.
+
+When the client retrieves data from the device, it must be prepared to
+handle the absence of leaf nodes with the default value, since the
+server is not required to send such leaf elements.  This permits the
+device to implement either of the first two default handling schemes
+given above.
+
+Regardless of the implementation choice, the device can support the
+"with-defaults" capability (^RFCWITHDEFAULTS^) and give the client the
+ability to select the desired handling of default values.
+
+When evaluating the XPath expressions for constraints like "must" and
+"when", the evaluation context for the expressions will include any
+appropriate default values, so the modeler can depend on consistent
+behavior from all devices.
+