Subject: [netmod] review of draft-ietf-netmod-yang-05

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 14 May 2009 10:31:14 +0200

Hi,

here is my review of the YANG draft. Apart from the comments in the mail
body below, I am also attaching a patch file with corrections of typos
and my suggestions for minor formulation changes.

Lada

------------------------------------------------------------------------
- The name of the game: "YANG" is used for both the C-like syntax and
  semantics but "YIN" only for syntax. Perhaps it would be more
  appropriate to drop "YIN" and use e.g., "standard syntax" and "XML
  syntax" where necessary. Cf. Sec. 5.6.5: 'Note that the format is
  "YANG", even if the YIN syntax is used.'

- Section 3 defines terms "data node" and "schema node" but quite
  often the text uses just "node" and it is not immediately clear
  which one of the two it is.

- The word "definition" is used in two meanings: (i) definition of
  data nodes and (ii) definitions of groupings, typedefs and
  features. For example, Sec. 7.1.5 says: 'The "import" statement
  makes definitions from one module available inside another module or
  submodule.' and it means (ii). Suggestion: use "data node
  definition" for (i).

- Sec. 3.1: Fourth item is missing for "anyxml" node.

- Sec. 5.1.1: The spec doesn't ensure that both parties in a NETCONF
  session always use the same module revisions or that any mismatch
  is immediately detected, if the revision is not specified. What is
  the meaning of "current revision" and "available at the time"? An
  agent may be limited to locally stored modules, so its notion of
  "current" may be different. Resulting problems are hard to detect
  unless the exact revision dates are always used in both capability
  advertisements and imports.

- Sec. 5.1.2: <config> is not the only NETCONF element carrying data
  model XML data. Others are <data> or <rpc-reply>.

- Sec. 5.2: What are "YANG compilers"? Suggestion: "YANG software"

- Sec 5.3: XML namespace URIs are globally unique, so the probability
  of collisions must be zero. Last sentence should be: "Namespace URI
  MUST be chosen so that it cannot collide with standard ...".

- Sec. 5.6.1: Instead of suggesting religious attitudes of
  implementors, this section should state what basic behavior means:
  all features that do not depend on a feature must be implemented.

- Sec. 5.6.4:
  * The ABNF is too lax (this has already been discussed in the ML).
  * The module names and their namespaces are somewhat redundant. I'd
    suggest to resolve YANG modules using only namespace URI -
    collisions in module names then wouldn't be a problem and "module"
    parameter of capability strings can be removed. 
  * How can the capability string for module A declare a feature which
    module A imports from module B (another namespace)?

- Sec. 5.6.4.3: Is it necessary to advertise the module with
  deviations (my-devs) twice?

- Sec. 6.1.3, para 5: "... two strings are concatenated into one
   quoted string, ...". Does "quoted" mean single- or double-quoted?
   Example: "Here's " + 'the problem.\n'. Suggestion: State that all
   escaped characters are substituted before concatenation and then
   the strings are joined into one (value-space) string.

- Sec. 6.4 (sorry, I can't help myself:-): "... the namespace of the
  current module defined as the null namespace." is wrong. In fact,
  XPath 1.0 spec never uses the term "null namespace", but only "null
  namespace URI", for example "The namespace URI is either null or a
  string." It is beyond any doubt that "null" means "non-existent".

- Sec. 7.1.3: The namespace is used not only for XML elements but also
  for extensions and features.

- Sec. 7.1.5: It is not specified which revision is used if the
  "revision-date" substatement is missing (related to Sec. 5.1.1).

- Sec. 7.1.6, para 1: This should be added: "Submodules are only
  allowed to import other submodules if both importing and imported
  submodules belong to the same module."

- Sec. 7.5.3:
  * In the description of the evaluation context, the second item is:
    "The accessible tree is made up of all nodes in the data tree, and
    ..." However, subsequent items say that the tree actually depends
    on the content type (config data, RPC, notification).
  * "... any XPath comparisons are done on the canonical value." Does
    it mean that 'foo < 5' is always false is foo is decimal64? If so,
    I strongly disagree, because this is not how it works in XPath.

- Sec 7.19.5: Same problem as in 7.5.3 (specification of the
  accessible tree).

- Sec.7.5.7, para 3: NP-container must be sent if it is at the top of
  a case in a choice, because it may be the selector for the
  case. (This has already been discussed in the ML.)

- Sec. 7.6.5, para 2: Again, a leaf at the top level of a case in a
  choice must be sent even if it's value is the default.

- Sec. 7.9.3:
  * Suggestion: use 'default-case' keyword here, because both syntax
    and semantics differs from the 'default' specifying leaf default
    value.
  * para 3: Could this clarify how the default case is used? 
    OLD
    The default values for nodes under the default case are used if
    none of the nodes under any of the cases are present.
    NEW
    If (and only if) none of the nodes under any of the cases are
    present in the data tree, the contents of the default case
    effectively replace the entire choice.

- Sec. 7.11, last para:
  * "References from inside the grouping are relative to the scope in
    which the grouping is defined, not where it is used." I believe
    this should be "Identifiers appearing inside the grouping are
    resolved relative to the scope in which ...". References such as
    'leafref' or XPath expressions in 'must' are relative to the scope
    of 'uses'.
  * In don't understand the last sentence "For extensions, ...".

- Sec. 7.13.2, para 2: This is not true if the mandatory leaf is
  inside a P-container.

- Sec. 7.13.3, para 2: Same as in 7.13.2

- Sec. 7.14, para 3: Same as in 7.13.2

- Sec. 7.14, para 4: s/NETCONF server/NETCONF client/ (?)

- Sec. 7.15: The shorthand notation for a case cannot be used when
  augmenting a choice?

- Sec 9., para 4: The lexicographic representation is also used for
  specifying ranges of numeric types.

- Sec. 9.2.1: Are octal and hexadecimal values allowed in 'range'
  restrictions?

- Sec. 9.4.1: Encodings that every implementation must support should
  be specified here, for example UTF-8 or UTF-16. But in an argument of
  'default', a string must be always in UTF-8.

- Sec. 9.4.2, para 2: The text should mention that multiple
  adjacent predicates are allowed, as in "foo[key1=3][key2=100]". An
  example would also be helpful.
  OLD
  Each predicate consists of exactly one equality test per key.
  NEW
  Each predicate consists of exactly one equality test per key but
  multiple adjacent predicates may be present, for example if a list
  has multiple keys.

- Sec. 9.9.2: What is the context for XPath evaluation in this case?

- Sec. 9.9.3: The case "require-instance false;" should also be
  specified: 'If "require-instance" is "false", the value of the leaf
  with "leafref" type must be equal to the referred leaf only if the
  latter exists.'

- Sec. 9.10: I don't understand the semantics of 'identityref'
  type. How is it different from an enumeration?

- Sec. 9.10.5:
  * Since module "des" is not imported, how can an
    implementation know that such a module exists and defines the
    "des3" identity?
  * Is "crypto:crypto-alg" also a valid value of the "crypto" leaf? 

- Sec. 9.13.2, para 1: "All node names in an instance-identifier value
  MUST be qualified with explicit namespace prefixes and these
  prefixes MUST be declared ..."

Editorial comments:
-------------------

- Possessive forms with 's are overused and sometimes it is really ugly:
  "The must's Substatements", "bits's".

- In HTML rendering, Sec. 5.6.4 in ToC does not have the hyperlink.

- Also in HTML: xml2rfc tries to be too clever and makes phrases like
  "section 3.1" automatically into a local hyperlink, even if they
  refer to a section of another document. This happens in
  Sec. 6.4. Similarly, upper limits of ranges are interpreted as page
  references (in 9.2.5, 9.4.5) and regular expressions into
  bibliography refs (9.4.7).

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C
diff --git a/draft-ietf-netmod-yang-05.txt b/draft-ietf-netmod-yang-05.txt
index 48e4c31..3240e9f 100644
--- a/draft-ietf-netmod-yang-05.txt
+++ b/draft-ietf-netmod-yang-05.txt
@@ -397,7 +397,7 @@ Internet-Draft                    YANG                        April 2009
 
    Today, the NETCONF protocol [RFC4741] lacks a standardized way to
    create data models.  Instead, vendors are forced to use proprietary
-   solutions.  In order for NETCONF to be a interoperable protocol,
+   solutions.  In order for NETCONF to be an interoperable protocol,
    models must be defined in a vendor-neutral way.  YANG provides the
    language and rules for defining such models for use with NETCONF.
 
@@ -638,7 +638,7 @@ Internet-Draft                    YANG                        April 2009
 
    A mandatory node is one of:
 
-   o  A leaf or choice node with a "mandatory" statement with the value
+   o  A leaf, anyxml or choice node with a "mandatory" statement with the value
       "true".
 
    o  A list or leaf-list node with a "min-elements" statement with a
@@ -690,7 +690,7 @@ Internet-Draft                    YANG                        April 2009
 
    YANG structures data models into modules and submodules.  A module
    can import data from other external modules, and include data from
-   submodules.  The hierarchy can be extended, allowing one module to
+   submodules.  The hierarchy can be augmented, allowing one module to
    add data nodes to the hierarchy defined in another module.  This
    augmentation can be conditional, with new nodes appearing only if
    certain conditions are met.
@@ -767,7 +767,7 @@ Internet-Draft                    YANG                        April 2009
    This section introduces some important constructs used in YANG that
    will aid in the understanding of the language specifics in later
    sections.  This progressive approach handles the inter-related nature
-   of YANG concepts and statements.  Specifics about YANG statements and
+   of YANG concepts and statements.  A detailed description of YANG statements and
    syntax begins in Section 7.
 
 4.2.1.  Modules and Submodules
@@ -1350,7 +1350,7 @@ Internet-Draft                    YANG                        April 2009
      <rpc message-id="101"
           xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
        <activate-software-image xmlns="http://acme.example.com/system">
-         <name>acmefw-2.3</name>
+         <image-name>acmefw-2.3</image-name>
       </activate-software-image>
      </rpc>
 
@@ -1465,7 +1465,7 @@ Internet-Draft                    YANG                        April 2009
    a single data model.  A module can define a complete, cohesive model,
    or augment an existing data model with additional nodes.
 
-   Submodule are partial modules that contribute definitions to a
+   Submodules are partial modules that contribute definitions to a
    module.  A module may include any number of submodules, but each
    submodule may belong to only one module.
 
@@ -1523,8 +1523,8 @@ Internet-Draft                    YANG                        April 2009
    is unaffected and its contents are unchanged.  When the author of the
    module is prepared to move to the most recently published revision of
    an imported module, the module is republished with an updated import
-   statement.  By republishing with the new revision, the author is
-   explicitly indicating their acceptance of any changes in the imported
+   statement.  By republishing with the new revision, the authors
+   explicitly indicate their acceptance of any changes in the imported
    module.
 
    For submodules, the issue is related but simpler.  A module or
@@ -1571,9 +1571,10 @@ Internet-Draft                    YANG                        April 2009
 
    level nodes are sometimes convenient, and are supported by YANG.
 
-   NETCONF is capable of carrying any XML content as the payload in the
-   <config> element.  The top-level nodes of YANG modules are encoded as
-   child elements within the <config> element.
+   The NETCONF protocol [RFC4741] defines the encapsulating elements
+   such as <config> or <data> that contain the top-level nodes of YANG
+   modules as their child elements. This encapsulation guarantees that
+   the corresponding NETCONF PDUs are always well-formed XML documents.
 
    For example:
 
@@ -1709,7 +1710,7 @@ Internet-Draft                    YANG                        April 2009
    model.  Generally speaking, devices are responsible for implementing
    the model faithfully, allowing applications to treat devices which
    implement the model identically.  Deviations from the model can
-   reduce the utility of the model and increase fragility into
+   reduce the utility of the model and increase fragility of
    applications that use it.
 
    YANG modelers have three mechanisms for conformance:
@@ -1725,7 +1726,7 @@ Internet-Draft                    YANG                        April 2009
 5.6.1.  Basic Behavior
 
    The model defines a contract between the NETCONF client and server,
-   which allows both parties to have faith the other knows the syntax
+   which allows both parties to have faith that the other party knows the syntax
    and semantics behind the modeled data.  The strength of YANG lies in
    the strength of this contract and the mindless devotion with which
    implementers follow it.
@@ -1760,7 +1761,7 @@ Internet-Draft                    YANG                        April 2009
 
    A module may declare any number of features, identified by simple
    strings, and may make portions of the module optional based on those
-   feature.  If the device supports a feature, then the corresponding
+   features.  If the device supports a feature, then the corresponding
    portions of the module are valid for that device.  If the device
    doesn't support the feature, those parts of the module are not valid,
    and applications should behave accordingly.
@@ -1776,7 +1777,7 @@ Internet-Draft                    YANG                        April 2009
    In an ideal world, all devices would be required to implement the
    model exactly as defined, and deviations from the model would not be
    allowed.  But in the real world, devices are often not able or
-   willing to implement the model as written.  For YANG-based automation
+   their developers willing to implement the model as written.  For YANG-based automation
    to deal with these device deviations, a mechanism must exist for
    devices to inform applications of the specifics of such deviations.
 
@@ -2004,7 +2005,8 @@ Internet-Draft                    YANG                        April 2009
    If the double quoted string contains a line break followed by
    whitespace which is used to indent the text according to the layout
    in the YANG file, this leading whitespace is stripped from the
-   string, up to at most the same column of the double quote character.
+   string, up to at most the column of the opening double quote character
+   in a preceding line.
 
    If the double quoted string contains whitespace before a line break,
    this trailing whitespace is stripped from the string.
@@ -2075,7 +2077,7 @@ Internet-Draft                    YANG                        April 2009
 
 6.2.  Identifiers
 
-   Identifiers are used to identify different kinds of YANG items by
+   Identifiers are used to identify different kinds of YANG objects by
    name.  Each identifier starts with an upper-case or lower-case ASCII
    letter or an underscore character, followed by zero or more ASCII
    letters, digits, underscore characters, hyphens, and dots.
@@ -2387,7 +2389,7 @@ Internet-Draft                    YANG                        April 2009
 
    The "yang-version" statement specifies which version of the YANG
    language was used in developing the module.  The statement's argument
-   contains value "1", which is the current yang version and the default
+   MUST contain value "1", which is the current yang version and the default
    value.
 
 7.1.3.  The namespace Statement
@@ -2413,7 +2415,7 @@ Internet-Draft                    YANG                        April 2009
 
    The "prefix" statement is used to define the prefix associated with
    the module and its namespace.  The "prefix" statement's argument is
-   the prefix string which is used as a prefix to access a module.  The
+   the prefix string which is used as a prefix to access the names defined in a foreign module.  The
    prefix string MAY be used to refer to definitions contained in the
    module, e.g. "if:ifName".  A prefix follows the same rules as an
    identifier (see Section 6.2).
@@ -2483,7 +2485,7 @@ Internet-Draft                    YANG                        April 2009
 7.1.6.  The include Statement
 
    The "include" statement is used to make content from a submodule
-   available to the module.  The argument is an identifier which is the
+   available to the module or another submodule.  The argument is an identifier which is the
    name of the submodule to include.  Modules are only allowed to
    include submodules that belong to that module, as defined by the
    "belongs-to" statement (see Section 7.2.2).
@@ -2614,7 +2616,7 @@ Internet-Draft                    YANG                        April 2009
 7.2.  The submodule Statement
 
    While the primary unit in YANG is a module, a YANG module can itself
-   be constructed out of several submodules.  Submodules allows a module
+   be constructed out of several submodules.  Submodules allow a module
    designer to split a complex model into several pieces where all the
    submodules contribute to a single namespace, which is defined by the
    module that includes the submodules.
@@ -2874,8 +2876,8 @@ Internet-Draft                    YANG                        April 2009
    used to put further restrictions on the type.
 
    The restrictions that can be applied depend on the type being
-   restricted.  The restriction statements are described in subsections
-   for each built-in type in Section 9.
+   restricted.  The restriction statements for all built-in types are
+   described in the subsections of Section 9.
 
 7.4.1.  The type's Substatements
 
@@ -3029,7 +3031,7 @@ Internet-Draft                    YANG                        April 2009
       statements' prefix and namespace pairs, and the "prefix"
       statement's prefix for the "namespace" statement's URI.
 
-   o  Elements without a namespace refer to nodes in the current module.
+   o  Elements without a namespace prefix refer to nodes in the current module.
 
    o  The function library is the core function library defined in
       [XPATH], and a function "current()" which returns a node set with
@@ -3552,7 +3554,7 @@ Internet-Draft                    YANG                        April 2009
 
    The "min-elements" statement, which is optional, takes as an argument
    a non-negative integer which puts a constraint on valid list entries.
-   A valid leaf-list or list MUST have least min-elements entries.
+   A valid leaf-list or list MUST have at least min-elements entries.
 
    If no "min-elements" statement is present, it defaults to zero.
 
@@ -4568,7 +4570,7 @@ Internet-Draft                    YANG                        April 2009
    An anyxml node is treated as an opaque chunk of data.  This data can
    be modified in its entirety only.
 
-   Any "operation" attributes within the XML value of an anyxml node are
+   Any "operation" attributes present on subelements of an anyxml node are
    ignored by the NETCONF server.
 
    When a NETCONF server processes an <edit-config> request, the
@@ -4695,7 +4697,7 @@ Internet-Draft                    YANG                        April 2009
 
    The effect of a "uses" reference to a grouping is that the nodes
    defined by the grouping are copied into the current schema tree, and
-   then updated according to the refinement statements.  Thus, the
+   then updated according to the refinement or augment statements.  Thus, the
    identifiers defined in the grouping are copied into the current

@@ -4892,7 +4894,7 @@ Internet-Draft                    YANG                        April 2009
 
    The "input" statement, which is optional, is used to define input
    parameters to the RPC method.  It does not take an argument.  The
-   substatements to "input" defines nodes under the RPC's input node.
+   substatements to "input" define nodes under the RPC's input node.
 
    If a leaf in the input tree has a "mandatory" statement with the
    value "true", the leaf MUST be present in a NETCONF RPC invocation.
@@ -5124,7 +5126,7 @@ Internet-Draft                    YANG                        April 2009
    [RFC5277].  The element's name is the notification's identifier, and
    its XML namespace is the module's XML namespace.
 
-   The notifications's child nodes are encoded as subelements to the
+   The notification's child nodes are encoded as subelements to the
    notification node's XML element, in the same order as they are
    defined within the notification statement.
 
@@ -6179,7 +6181,7 @@ Internet-Draft                    YANG                        April 2009
       leaf, including those defined in the type's range, length, and
       pattern properties, the server MUST reply with an "invalid-value"
       error-tag in the rpc-error, and with the error-app-tag and error-
-      message assoicated with the constraint, if any exist.
+      message associated with the constraint, if any exist.
 
    o  If all keys of a list entry are not present, the server MUST reply
       with a "missing-element" error-tag in the rpc-error.
@@ -6202,7 +6204,7 @@ Internet-Draft                    YANG                        April 2009
 
    o  If the attributes "before" and "after" appears in any element that
       is not a list whose "ordered-by" property is "user", the server
-      MUST reply with an "unkown-attribute" error-tag in the rpc-error.
+      MUST reply with an "unknown-attribute" error-tag in the rpc-error.
 
 8.3.2.  NETCONF <edit-config> Processing
 
@@ -6311,13 +6313,13 @@ Internet-Draft                    YANG                        April 2009
    uint16, uint32, and uint64.  They represent signed and unsigned
    integers of different sizes:
 
-   int8  represents integer values between -128 and 127, inclusively.
+   int8  represents integer values between -128 and 127 inclusive.
 
-   int16  represents integer values between -32768 and 32767,
-      inclusively.
+   int16  represents integer values between -32768 and 32767
+      inclusive.
 
-   int32  represents integer values between -2147483648 and 2147483647,
-      inclusively.
+   int32  represents integer values between -2147483648 and 2147483647
+      inclusive.

@@ -6330,17 +6332,17 @@ Internet-Draft                    YANG                        April 2009

    int64  represents integer values between -9223372036854775808 and
-      9223372036854775807, inclusively.
+      9223372036854775807 inclusive.
 
-   uint8  represents integer values between 0 and 255, inclusively.
+   uint8  represents integer values between 0 and 255 inclusive.
 
-   uint16  represents integer values between 0 and 65535, inclusively.
+   uint16  represents integer values between 0 and 65535 inclusive.
 
-   uint32  represents integer values between 0 and 4294967295,
-      inclusively.
+   uint32  represents integer values between 0 and 4294967295
+      inclusive.
 
-   uint64  represents integer values between 0 and 18446744073709551615,
-      inclusively.
+   uint64  represents integer values between 0 and 18446744073709551615
+      inclusive.
 
 9.2.1.  Lexicographic Representation
 
@@ -6409,7 +6411,7 @@ Internet-Draft                    YANG                        April 2009
    or ranges are given they all MUST be disjoint and MUST be in
    ascending order.  If a range restriction is applied to an already
    range restricted type, the new restriction MUST be equal or more
-   limiting, that is raising the lower bounds, reducing the upper
+   limiting, that is increasing the lower bounds, decreasing the upper
    bounds, removing explicit values or ranges, or splitting ranges into
    multiple ranges with intermediate gaps.  Each explicit value and
    range boundary value given in the range expression MUST match the
@@ -6472,7 +6474,7 @@ Internet-Draft                    YANG                        April 2009
 
    A decimal64 value is lexicographically represented as an optional
    sign ("+" or "-"), followed by a sequence of decimal digits,
-   optionally followed by a period ('.') as a decmial indicator and a
+   optionally followed by a period ('.') as a decimal indicator and a
    sequence of decimal digits.  If no sign is specified, "+" is assumed.
 
 9.3.2.  Canonical Form
@@ -6485,7 +6487,7 @@ Internet-Draft                    YANG                        April 2009
 
 9.3.3.  Restrictions
 
-   A decmial64 type can be restricted with the "range" statement
+   A decimal64 type can be restricted with the "range" statement
    (Section 9.2.4).

@@ -6515,7 +6517,7 @@ Internet-Draft                    YANG                        April 2009
 
 9.4.  The string Built-in Type
 
-   The string built-in type represents human readable strings in YANG.
+   The string built-in type represents finite-length character strings in YANG.
    Legal characters are tab, carriage return, line feed, and the legal
    characters of Unicode and ISO/IEC 10646 [ISO.10646]:
 
@@ -6564,8 +6566,8 @@ Internet-Draft                    YANG                        April 2009
    be negative.  If multiple values or ranges are given, they all MUST
    be disjoint and MUST be in ascending order.  If a length restriction
    is applied to an already length restricted type, the new restriction
-   MUST be equal or more limiting, that is, raising the lower bounds,
-   reducing the upper bounds, removing explicit length values or ranges,
+   MUST be equal or more limiting, that is, increasing the lower bounds,
+   decreasing the upper bounds, removing explicit length values or ranges,
    or splitting ranges into multiple ranges with intermediate gaps.  A
    length value is a non-negative integer, or one of the special values
    "min" or "max". "min" and "max" means the minimum and maximum length
@@ -6636,7 +6638,7 @@ Internet-Draft                    YANG                        April 2009
    matches the pattern.
 
    If the type has multiple "pattern" statements, the expressions are
-   AND:ed together, i.e. all such expressions have to match.
+   ANDed together, i.e. all such expressions have to match.
 
    If a pattern restriction is applied to an already pattern restricted
    type, values must match all patterns in the base type, in addition to
@@ -7358,7 +7360,7 @@ Internet-Draft                    YANG                        April 2009
    An instance-identifier value is lexicographically represented as a
    string in the XML encoding.  The namespace prefixes used in the
    encoding MUST be declared in the XML namespace scope in the instance-
-   idenfitier's XML element.
+   identifier's XML element.
 
    Any prefixes used in the encoding are local to each instance
    encoding.  This means that the same instance-identifier may be
@@ -7459,7 +7461,7 @@ Internet-Draft                    YANG                        April 2009
 
    For any published change, a new "revision" statement (Section 7.1.9)
    SHOULD be included in front of the existing revision statements.
-   Furthermore, any necessary changes MUST be applied to any meta
+   Furthermore, any necessary changes MUST be applied to any metadata
    statements, including the "organization" and "contact" statements
    (Section 7.1.7, Section 7.1.8).
 
@@ -7477,7 +7479,7 @@ Internet-Draft                    YANG                        April 2009
    o  An "enumeration" type may have new enums added, provided the old
       enums's values do not change.
 
-   o  A "bits" type may have new bits added, provided the old bits's
+   o  A "bits" type may have new bits added, provided the old bit
       positions do not change.
 
    o  A "range", "length", or "pattern" statement may expand the allowed
@@ -7546,7 +7548,7 @@ Internet-Draft                    YANG                        April 2009
       be removed, provided the definitions in the module do not change
       in any other way than allowed here.
 
-   o  The "prefix" statment may be changed, provided all local uses of
+   o  The "prefix" statement may be changed, provided all local uses of
       the prefix also are changed.
 
    Otherwise, if the semantics of any previous definition are changed
@@ -7632,7 +7634,7 @@ Internet-Draft                    YANG                        April 2009
    provides a more concise and readable format.
 
    The mapping between YANG and YIN does not modify the information
-   content of the model.  Comments and whitespaces are not preserved.
+   content of the model.  Comments and whitespace are not preserved.
 
 11.1.  Formal YIN Definition
 
@@ -9302,7 +9304,7 @@ Internet-Draft                    YANG                        April 2009
    The editor wishes to thank the following individuals, who all
    provided helpful comments on various versions of this document:
    Mehmet Ersue, Washam Fan, Joel Halpern, Leif Johansson, Ladislav
-   Lhotka, Gerhard Muenz, Tom Petch, Randy Preshun, David Reid, and Bert
+   Lhotka, Gerhard Muenz, Tom Petch, Randy Presuhn, David Reid, and Bert
    Wijnen.

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 20 May 2009 22:41:46 +0200 (CEST)

Hi,

> and my suggestions for minor formulation changes.

Thanks, I applied most of them.

>   "YANG", even if the YIN syntax is used.'

I think the names are pretty well-known by now and already used by
others, so I'd be hesitant to change this now.

>   which one of the two it is.

I will have a look at this.

>   submodule.' and it means (ii). Suggestion: use "data node

Actually, it refers to both meanings.  E.g. you need to import a module
in order to augment it.

> - Sec. 3.1: Fourth item is missing for "anyxml" node.

Fixed.

>   session always use the same module revisions

This is by design.  We cannot assume that all clients always have the
latest version of a particular module.

>  or that any mismatch

The full sentence is:

  When a module is written, it uses the current revisions of
  other modules, based on what is available at the time.

This is design time, not run-time.  The text argues for why import by
revision is needed.

>   model XML data. Others are <data> or <rpc-reply>.

I added <data> as well.  Nothing in 4741 encodes data model XML
directly under rpc-reply.

> - Sec. 5.2: What are "YANG compilers"? Suggestion: "YANG software"

I changed this to "YANG tools".

>   MUST be chosen so that it cannot collide with standard ...".

Fixed.

>   all features that do not depend on a feature must be implemented.

I suggest we remove the last part of the last sentence, to get:

   The strength of YANG lies in the strength of this contract.

>   * The ABNF is too lax (this has already been discussed in the ML).

Fixed (as discussed in the other thread).

>     parameter of capability strings can be removed. 

If it is not there, we would have to use the URI for the deviation
parameter.   The module name is easier to work with.

>     module A imports from module B (another namespace)?

It cannot.  The device must advertise module B and its features.

>   deviations (my-devs) twice?

It is advertised once.  The first <capability> is for a module called
'syslog'.

>    the strings are joined into one (value-space) string.

Would this work:

  If a quoted string is followed by a plus character ("+"), followed by
  another quoted string, the two strings are concatenated into one
  string, allowing multiple concatenations to build one string.
  Whitespace trimming and substition of backslash-escaped characters in
  double quoted strings is done before concatenation.

(this paragraph would be moved after the backslash-special character
text).

>   for extensions and features.

Extensions and features never show up in the XML.  The namespace does
not affect them.

>   "revision-date" substatement is missing (related to Sec. 5.1.1).

I will get back on this.  If anyone has a suggestion for text, please
let me know.

>   submodules belong to the same module."

Yes, but s/import/include.  I added:

  Submodules are only allowed to include other submodules belonging to
  the same module.

>     on the content type (config data, RPC, notification).

The idea is that the first sentence says that all nodes including
default values are there, and the next list specifies which nodes are
there, depending on context.  If this is unclear, could you suggest a
change?

>     it mean that 'foo < 5' is always false is foo is decimal64?

No, XPath comparison is NOT modified (of course).  It just specifies
what the value passed to the XPath expression will be.

>     resolved relative to the scope in which ...".

Fixed.

>   * In don't understand the last sentence "For extensions, ...".

It means that if you have an extention in a grouping, it applies to
the grouping itself, the extension statement is not expanded to the
uses.   I have fixed the typo "use node" --> "uses node".

> - Sec. 7.14, para 4: s/NETCONF server/NETCONF client/ (?)

Fixed.

> - Sec. 7.15: The shorthand notation for a case cannot be used when

Yes, it should be allowed.

OLD:

If the target node is a choice node, the "case" statement can be used
within the "augment" statement.

NEW:

If the target node is a choice node, the "case" statement, or a case
shorthand statement (see ^case^) can be used within the "augment"
statement.

>   specifying ranges of numeric types.

Fixed.

> - Sec. 9.2.1: Are octal and hexadecimal values allowed in 'range'

No.  Just for defaults.

>   'default', a string must be always in UTF-8.

YANG modules are written in UTF-8, isn't that enough?  If not, could
you propose some text?

>   multiple adjacent predicates may be present, for example if a list

I added:

   Each
   predicate consists of exactly one equality test per key, and
   multiple adjacent predicates MAY be present if a list has multiple
   keys.

> - Sec. 9.9.2: What is the context for XPath evaluation in this case?

Hmm.. do you think we need a list such as the ones in 7.5.3 and
7.19.5?

>   specified:

Ok.

> 'If "require-instance" is "false", the value of the leaf

I don't think this propsed text makes much sense - if they are equal
it means that the referred leaf exist!  I suggest:

NEW:

If "require-instance" is "false", it means that the instance being
referred MAY exist in valid data.

>   type. How is it different from an enumeration?

It is extensible.  The module designer should carefully think about
each enumeration in a module - should it be a type enumeration or type
identityref?  (This discussion should go into the yang guidelines).

>     implementation know that such a module exists and defines the

des:des3 will only be valid on the device if the device implements
(and adertises) the des module.

>   * Is "crypto:crypto-alg" also a valid value of the "crypto" leaf? 

No, the text says:

  Valid values for an identityref are any identities derived from the
  identityref's base identity.

>   prefixes MUST be declared ..."

Fixed.

> Editorial comments:

Not changed.

> - In HTML rendering, Sec. 5.6.4 in ToC does not have the hyperlink.

I never posted the HTML, it was automatically generated from the text
by the IETF tools.

(Phil's tool does generate HTML from the source, available at:
http://www.yang-central.org/twiki/pub/Main/YangDocuments/draft-ietf-netmod-yang-05.html)

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 21 May 2009 10:23:39 +0200

Hi,

I think it is more effective to discuss the issues in separate threads,
so I will divide my responses into multiple messages.

> Actually, it refers to both meanings.  E.g. you need to import a

A data node definition such as "container" changes the schema but it is
not the case with "import". This is also different behaviour when
compared to other common languages like Python or RELAX NG, so it
probably needs a more detailed explanation. I remember it was quite
confusing for me, too.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 21 May 2009 10:33:16 +0200

> latest version of a particular module.

It is a strange contract where each party may work with a different
text. I didn't get this was a feature, so I disagree now.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 21 May 2009 10:38:52 +0200

> directly under rpc-reply.

Sec. 7.13.4:
If output parameters are returned, they are encoded as
child elements to the <rpc-reply> element defined in [RFC4741], in
the same order as they are defined within the output statement.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 21 May 2009 11:20:10 +0200

> parameter.   The module name is easier to work with.

URIs are required to be globally unique and also there are established
procedures for resolving them. Neither is true for module names.
It is machine-to-machine communication, so ease of use shouldn't be a
top priority.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 21 May 2009 11:21:06 +0200

> (this paragraph would be moved after the backslash-special character

Looks good. Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 21 May 2009 11:24:57 +0200

> Extensions and features never show up in the XML.  The namespace does

The 'namespace' statements defines the namespace and prefix for objects
within the YANG module, too.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 21 May 2009 11:33:32 +0200

> there, depending on context.  If this is unclear, could you suggest a

o Default values are substituted for all missing leafs in the
  accessible data tree for which the default value is defined.

Perhaps the specification of the accessible data tree could be moved
before this list.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 21 May 2009 11:48:28 +0200

> YANG modules are written in UTF-8, isn't that enough?  If not, could

Encoding of PDUs follows XML rules, so I suggest to have the same
requirements as the XML spec:

"All implementations MUST accept the UTF-8 and UTF-16 encodings of
ISO/IEC 10646 specified according to [XML], section 4.3.3."

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 21 May 2009 11:56:04 +0200

> Hmm.. do you think we need a list such as the ones in 7.5.3 and

Yes, something similar. The accessible data tree is apparently different
from the one used for "must" and "when".

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 21 May 2009 13:00:11 +0200

> referred MAY exist in valid data.

... and if it exists, its value MUST be equal to the value of the
referring leaf.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 21 May 2009 09:34:52 -0700

Hi -

> From: "Ladislav Lhotka" <[email-masked]>
> To: "Martin Bjorklund" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Thursday, May 21, 2009 2:48 AM
> Subject: [netmod] character encoding [Was: review ofdraft-ietf-netmod-yang-05]
>
...

There is little or no value to having two mandatory encodings.

Having two options increases the chances of error, and the code points
requiring multiple words to encode in UTF-16 are sufficiently uncommon
that it's likely that those code paths will not be properly tested.

UTF-8 is the clear winner in the encoding wars.  That should be the sole
mandatory encoding, IMO.

RAndy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 21 May 2009 21:37:17 +0200 (CEST)

> probably needs a more detailed explanation. I remember it was quite

The text says:

  The "import" statement makes definitions from one module available
  inside another module or submodule. 

Could you propose text to make it more clear?

BTW, RNG doesn't have 'import' does it?

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 21 May 2009 21:38:10 +0200 (CEST)

> text. I didn't get this was a feature, so I disagree now.

Are you suggesting that if a server advertises module A, revision X,
and the client does not understand A rev X, then the client MUST close
the session?

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 21 May 2009 21:43:43 +0200 (CEST)

> the same order as they are defined within the output statement.

Right.  The text in 5.1.2 now reads:

   NETCONF is capable of carrying any XML content as the payload in the
   <config> and <data> elements.  The top-level nodes of YANG modules
   are encoded as child elements within these elements. 

The top-level nodes of YANG modules will not be sent directly as
children to <rpc-reply>.

(The text does not say "NETCONF is capable of carrying any XML content
*only* as the payload...")

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 21 May 2009 21:45:34 +0200 (CEST)

> within the YANG module, too.

I'm sorry, I don't understand your point.  Could you suggest some text
that would go into 7.1.3?

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 21 May 2009 21:49:13 +0200 (CEST)

> Perhaps the specification of the accessible data tree could be moved

Or maybe we can remove the bullet "The accessible tree is made up
of...", and add your new bullet as the last bullet in the second list
"The accessible data tree depends on the context node:".

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 21 May 2009 22:01:41 +0200 (CEST)

> ... and if it exists, its value MUST be equal to the value of the

This does not make much sense.  How can it exist *without* its value
being equal to the value of the referring leaf?  Consider the example
in 9.9.6.

     <interface>
       <name>eth0</name>
     </interface>
     <interface>
       <name>lo</name>
     </interface>

The following leafef is valid:

     <mgmt-interface>eth0</mgmt-interface>

because the interface 'eth0' exists.  The following is invalid:

     <mgmt-interface>eth1</mgmt-interface>

because the interface 'eth1' does not exist.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 21 May 2009 13:19:30 -0700

> and the client does not understand A rev X, then the client MUST close

don't do that!

what if get-schema() is supported?
what if the manager auto-magically uses get-schema()
to fill in the missing modules?

This is the best part of the ietf-netconf-state module,
so let's use it!  It is up to the application/operator to
decide how to handle this problem.

> /martin

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 21 May 2009 22:20:24 +0200 (CEST)

> UTF-8 is the clear winner in the encoding wars.  That should be the sole

+1

But I don't think this should be specified in the YANG draft.  YANG
will work with any encodings of the XML in the NETCONF protocol.  So
if we want to talk about these encodings, it should be in 4741bis.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 21 May 2009 22:28:17 +0200 (CEST)

> > and the client does not understand A rev X, then the client MUST close

I definitely agree; I'm just trying to understand what Lada is saying.
IMO, requiring that both sides have the same revisions would simply
not work in real life.  We can not require that all clients are
updated in sych with the servers.  The module updating rules are
written specifically to support revision mismatch - the first rule is:

  - Protect old clients
    We want a client that uses version x of a module to be able to
    function when talking to a server implementing version x+1.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 22 May 2009 08:13:22 +0200

> There is little or no value to having two mandatory encodings.

Maybe, but then the XML in NETCONF PDUs would be more restricted than
general XML. From the XML 1.0 spec:

"All XML processors must accept the UTF-8 and UTF-16 encodings of
10646; ..."

>From http://en.wikipedia.org/wiki/UTF-16:

"UTF-16 is the native internal representation of text in the Microsoft
Windows 2000/XP/2003/Vista/CE; Qualcomm BREW operating systems; the Java
and .NET bytecode environments; Mac OS X's Cocoa and Core Foundation
frameworks; and the Qt cross-platform graphical widget toolkit."

Lada

> 
> RAndy
> 
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 22 May 2009 08:28:05 +0200

> Could you propose text to make it more clear?

The "import" statement makes identifiers from the namespace of the
imported module available in the importing module. In particular, the
importing module may

o use groupings and typedefs defined at the top level of the imported 
  module;

o refer to features defined in the imported module;

o use any data node of the imported module as the target node for the 
  "augment" statement.

Unlike "include", the "import" statement doesn't contribute the data
tree from the imported to the importing module.

> BTW, RNG doesn't have 'import' does it?

It's called "include".

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 22 May 2009 08:42:56 +0200

> that would go into 7.1.3?

The "namespace" statement defines the XML namespace to which all
identifiers defined by the module belong, with the exception of data
node identifiers defined inside a grouping (see Section 7.12 for
details).

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 22 May 2009 08:56:08 +0200

Martin Bjorklund píše v Čt 21. 05. 2009 v 22:01 +0200:
> being equal to the value of the referring leaf?

leafref needn't refer to a list key:

leaf foo {
    type string;
}
leaf fooref {
    type leafref {
        path "../foo";
    }
}

Then the following is made illegal by the requirement:

<foo>foo</foo>
<fooref>bar</fooref>

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 22 May 2009 09:18:43 +0200

> if we want to talk about these encodings, it should be in 4741bis.

True, but sec. 9.4.1 says

"A string value is lexicographically represented as character data in
   the XML encoding."

There is no unique "XML encoding".

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 22 May 2009 09:36:14 +0200 (CEST)

> There is no unique "XML encoding".

We talk about XML encoding in many places.  This means how data is
encoded into XML; it does not refer to which character encoding scheme
the NETCONF PDUs use.

/martin

---

From: "tom.petch" <[email-masked]>
Date: Fri, 22 May 2009 10:06:14 +0200

----- Original Message -----
From: "Martin Bjorklund" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, May 21, 2009 10:20 PM

> if we want to talk about these encodings, it should be in 4741bis.

Um.  Does

6.  YANG syntax

still say

"   YANG modules are written in the UTF-8 [RFC3629] character set."
?

I have problems with this because UTF-8 is not a character set but a
transformation format or character (en)coding syntax or ... (depending on your
SDO:-(

And do we really mean that YANG modules can be written in a mixture of Han and
Katakana and ... because that is what it seems to tell me?

Tom Petch

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 22 May 2009 11:21:50 +0200 (CEST)

> transformation format or character (en)coding syntax or ... (depending on your

What should we write instead?

> Katakana and ... because that is what it seems to tell me?

Would this be a problem?

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 22 May 2009 11:28:59 +0200

> encoded into XML; it does not refer to which character encoding scheme

The word "encoding" denotes (in the XML spec at least) the process of
mapping characters to byte sequences.

I propose to add the following term to Sec. 3:

o character: atomic unit of text as specified by [ISO/IEC10646].

And then use just "character".

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 22 May 2009 11:35:53 +0200

> transformation format or character (en)coding syntax or ... (depending

It specifies the encoding of YANG modules in text files.

> Katakana and ... because that is what it seems to tell me?

IMO, yes.

Lada (Láďa, actually :-)

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 22 May 2009 13:01:47 +0200

> I definitely agree; I'm just trying to understand what Lada is saying.

Examples for two revisions of the same module, X0 is used by the server
and X1 by the client, where X0 < X1:

* Revision X1 adds a new enum value and the client tries to set the 
  leaf to this value. For the server the value is invalid, so it
  returns an error message.

* Even worse: Leaf "mtu" has no default value defined in X0 (but is not 
  mandatory either), so the server uses a specific operational value, 
  say 296, perhaps hardwired. Revision X1 adds a default value of 1500 
  for "mtu". When "mtu" is not in the configuration obtained from the 
  server, the client concludes MTU is set to 1500, which is not the 
  case.

Are these not interoperability problems?

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 22 May 2009 13:29:15 +0200 (CEST)

> mapping characters to byte sequences.

I will change the words "XML encoding" to something else.  

"NETCONF XML Encoding:"

will be:

"NETCONF XML Example:"

"A corresponding XML encoding:"

will be

"A corresponding XML instance example:"

and so on.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 22 May 2009 15:00:13 +0200 (CEST)

> leafref needn't refer to a list key:

Duh!  Of course.  It is a *leaf* ref now.  Not just keyref.

I have added your suggested clarfication.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 22 May 2009 15:12:51 +0200 (CEST)

> node identifiers defined inside a grouping (see Section 7.12 for

Thanks, I have replaces the current text with this one.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 22 May 2009 15:15:26 +0200 (CEST)

> tree from the imported to the importing module.

I'm not sure this text is better than the current text.  Does anyone
else have an opinion?

> > BTW, RNG doesn't have 'import' does it?

Exactly.  YANG's include is more like RNG's include.  So I don't see
why RNG users would be confused when YANG's import does not behave
like RNG's include.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 22 May 2009 15:18:54 +0200 (CEST)

> Are these not interoperability problems?

I think these situations should be up to the client to handle
properly.  I don't think the solution is to say that such a client
MUST close the session.  Suppose the client simply does a
<get-config/> for archival reasons - should it not be allowed to do
this?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 22 May 2009 06:39:35 -0700

> <get-config/> for archival reasons - should it not be allowed to do

Agreed.
It should be common in manager code to treat
an unexpected node as 'anyxml', not to blow up
and stop working.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 22 May 2009 16:06:06 +0200

> <get-config/> for archival reasons - should it not be allowed to do

In the first case, the edit-config operation fails, and the second is an
undetected mismatch in the client and server data. Both situations are
abnormal.

Rather than closing the session, the client could learn about the
revision advertised by the server and switch to server's revision, and
abort the session only if it is not possible. This would induce a
modification in NETCONF hello negotiation, though.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 22 May 2009 16:09:53 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> abort the session only if it is not possible.

This is certainly possible today, and entirely up to the client to do
it it wants to.

/martin

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 22 May 2009 11:14:48 -0700

Hi -

> To: <[email-masked]>
> Sent: Thursday, May 21, 2009 11:13 PM
> Subject: Re: [netmod] character encoding [Was:review ofdraft-ietf-netmod-yang-05]
...
> frameworks; and the Qt cross-platform graphical widget toolkit."

Our job in the IETF is to worry about what goes on the wire.
When you advocate UTF-16, do you mean UTF-16BE or UTF-16LE?
Both is it?

Have you verified that surrogate pairs are actually handled
correctly?  What other IETF protocol actually USES some form
of UTF-16 encoding?

> And then use just "character".

I'm afraid that definition would be misleading.  Depending on the
canonicalization rules in place, you might reduce, but can not
eliminate, the possibility of combining marks and directionality
marks, which, while atomic from the code point perspective,
are not from a user perspective.  Then, too, there are wondrous things
like "COMBINING DOUBLE TILDE RIGHT HALF" and the ideographic variation
selectors.

The Unicode definition(s) of character won't help much either:

| Character. (1) The smallest component of written language that has
| semantic value; refers to the abstract meaning and/or shape, rather
| than a specific shape (see also glyph), though in code tables some
| form of visual representation is essential for the reader’s
| understanding. (2) Synonym for abstract character. (3) The basic
| unit of encoding for the Unicode character encoding. (4) The English
| name for the ideographic written elements of Chinese origin. [See  ideograph (2).]

I *think* you intend definition #3.  You could address the concern
by referring to the specific definition, but I'm afraid it doesn't
really help with the underlying problem.

If you intend to be consistent with the IS 10646 and Unicode, then
the solution is to use the term "code point," rather than "character".

Randy

---

From: "tom.petch" <[email-masked]>
Date: Fri, 22 May 2009 17:11:43 +0200

----- Original Message -----
From: "Ladislav Lhotka" <[email-masked]>
To: <[email-masked]>
Sent: Friday, May 22, 2009 8:13 AM
> Windows 2000/XP/2003/Vista/CE;

Don't I know it.  Microsoft produced a version of Word which doubled the size of
documents.  They then produced another version which printed those documents one
character (yes, character) to a line, consuming forests by the bucketload.

Then I learnt about UTF-16 and put two and two together.

So, Never! to UTF-16.

Tom Petch

>                          Qualcomm BREW operating systems; the Java

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 22 May 2009 22:26:14 +0200

Hi Randy,

> When you advocate UTF-16, do you mean UTF-16BE or UTF-16LE?

Oh, I don't advocate UTF-16, being a Linux user I would be quite happy
with UTF-8 only. I just don't believe UTF-8 is that universal as you
suggested. I happen to speak and write a language where these encodings
are a real issue and every once in a while I get a text where the
accented letters are broken.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E 8C0C

---

From: Andy Bierman <[email-masked]>
Date: Fri, 22 May 2009 13:44:34 -0700

> Then I learnt about UTF-16 and put two and two together.

+1 x 10^^42

UTF-8 is enough

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 22 May 2009 16:35:17 -0700

> modification in NETCONF hello negotiation, though.

The client already knows about the server's revision,
because it is advertised in the <hello>.
There is no modification needed, beyond the refinement already
specified in the YANG draft.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Sun, 24 May 2009 11:24:36 +0200

> specified in the YANG draft.

Oh yes, sorry, I assumed the supported modules are advertised by both
the client and server, but after checking the draft I realized that the
client doesn't send them in <hello>. So it should be OK provided that
the server always sends the revision as a part of the capability string.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: "tom.petch" <[email-masked]>
Date: Tue, 26 May 2009 10:23:21 +0200

---- Original Message -----
From: "Ladislav Lhotka" <[email-masked]>
To: <[email-masked]>
Sent: Friday, May 22, 2009 11:35 AM
Subject: Re: [netmod] character encoding

> > Katakana and ... because that is what it seems to tell me?

Touché.

But UTF-8 is still an encoding and not a character set so I think that that
needs changing or, as Martin suggested, removing to 4741bis.

Tom Petch