Re: [netmod] tree diagrams - flags

[Dale R. Worley]

Martin Bjorklund  writes:
> Aha, ok.  This description is not a correct description of the YANG
> data tree (in which XPath expressions etc are evaluated).  There is
> not a single "list node" called "interfaces".  Look at an example of
  ^ I'm pretty sure you mean "interface" here.
> an XML instance document:
>
>   
> 
>   eth0
>   ...
> 
> 
>   eth1
>   ...
> 
>   
>
> This also reflects the data tree.

OK, yes, I'm recalling that now.  I run into mental interference because
there are at least three ways of looking at it:

- The Yang statement is named "list" -- a singular noun -- and not
something like "repeated" or "repeated container".  And compared to
ordinary programming languages, the semantics is "array-of-structures".
(The fact that Yang doesn't orthogonalize the array and the structure is
why Yang must also have a leaf-list statement.)  So the "obvious"
semantics of the name is that it's "the name" of "the list".

- The XML version doesn't have an overt representation of the array, but
does have an overt representation of each structure and uses the list
name as the label of each structure.  The XPath expressions are
evaluated within this version, so the absence of an explicit array node
is important.

- The JSON representation overtly represents both the array ([...]) and
the structures ({...}), and applies the name to the array, not the
structures.  (Which means that you can't evaluate XPath expressions
directly against the JSON representation.)

Thus you get the contrasting representations:

   list bar {
 key foo;
 leaf foo {
   type uint8;
 }
 leaf baz {
   type string;
 }
   }

   
 123
 zig
   
   
 zag
 o
   

   "bar": [
 {
   "foo": 123,
   "baz": "zig"
 },
 {
   "baz": "zag",
   "foo": 0
 }
   ]

each of which invites one to speak of the schema in somewhat different
ways.

The way you'd describe a tree diagram differs depending on which way
you're looking at the schema.

Dale

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] uses and augment

[Dale R. Worley]

Martin Bjorklund  writes:
>> I notice that "augment" is not allowed to target a "grouping", despite
>> that naively seems to be an operation that a module designer might like
>> to do.  I expect that there is a reason why this is not allowed.
>
> There were lots of debate over this one when we first designed YANG.
> The main reason for not allowing this is that it can easily have
> unintended consequences.  Module A uses a grouping G b/c it fits the
> purpose.  Later someone augments G with some nodes; at this point it
> is not at all clear that the additional nodes are suitable for module
> A.

True...  But assuming that the grouping G has clean semantics, it
corresponds to some facility in the device, which in some way or another
appears in multiple places in the device's data model.  And a module
that augments G adds semantics about that facility, and would only be
implemented by a device for which the facility uniformly has that
additional semantics.  So it would be suitable for every place where the
grouping is used.

It seems like this consideration applies to the "Yang mount" facility
also -- if a module A augments another module B, and module B is mounted
in several places in the full data model, then all the instances of
module B will be augmented.

> Ok.  Well, if you want to add a sibling node to the nodes in the
> grouping it is trivial:
>
>   grouping foo {
> leaf a { ... }
>   }
>
>   uses foo;
>   leaf b { ... }
>
> gives you:
>
>leaf a { ... }
>leaf b { ... }

Of course, that works.  But what I'm considering is a modification of
the grouping which implicitly applies to all "uses" of that grouping --
because you don't want to have duplicate declarations of the added nodes
in every place the grouping is used.

> Well, the syntax of descendant-schema-nodeid looks like an XPath path
> expression in abbreviated form, but it is not defined in terms of
> XPath, hence there is no text about any XPath context.  See also
> section 6.5

OK, "context node" isn't the right term, but the idea still applies --
if the schema node identifier is descendant, the starting point for
reckoning the descending path has to be specified.

Juergen Schoenwaelder  writes:
> On Wed, Mar 22, 2017 at 02:26:53PM -0400, Dale R. Worley wrote:
> This is not at all clear. You only import 'foo' - so why would the
> augment of /foo:target (which is not exactly defined either) done in
> 'bar' apply to uses foo:target in baz?

I'd say because that's what one would expect "augmenting" of a grouping
to mean.  Again, it looks like there will be similar behavior in "Yang
mount".

> Augments are restricted to things that have a well defined name in the
> data tree because this makes it clear what is being augmented. One
> would have to create additional language constructs to make
> augmentations of groupings work.

It's clear that *groupings* have well-defined names, because "uses"
statements can refer to them.  RFC 7950 section 7.13 isn't particularly
clear about how the argument string of the statement is to be
interpreted, but going back over 7950, I'm getting the idea that the
names of groupings are not descendant-schema-nodeid's, that is, named
based on where the grouping statement sits in the syntactic hierarchy,
but are in a separate namespace which is flat regarding equality and
inequality comparisons, but has elaborate scoping rules regarding which
groupings are visible in which locations.

OK, that clarifies why you can't apply "augment" to a grouping --
groupings (and thus the things defined within them) don't have names
that can be expressed by descendant-schema-nodeid's.

Dale

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Interaction of 'when' and 'default' statements

[Dale R. Worley]

Martin Bjorklund  writes:
> William Ivory  wrote:
>> Thanks.  Can you point me at the part of RFC 6020 that explicitly
>> states that 'when' wins over 'default'?
>
> Section 7.6.1 of RFC 7950 says:
>
>Note that if the leaf or any of its ancestors has a "when" condition
>or "if-feature" expression that evaluates to "false", then the
>default value is not in use.

Or perhaps more to the point, beware that RFC 6020 does *not* have that
paragraph.

Dale

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] uses and augment

[Dale R. Worley]

I've got a couple of questions about the interaction of "uses" and
"augment".  I hope that these have straightforward answers that the old
hands can tell me easily enough.

1. Augmenting a grouping

I notice that "augment" is not allowed to target a "grouping", despite
that naively seems to be an operation that a module designer might like
to do.  I expect that there is a reason why this is not allowed.

For example:

 module foo {
   ...
   grouping target {
 leaf address {
   type inet:ip-address;
   description "Target IP address.";
 }
 leaf port {
   type inet:port-number;
description "Target port number.";
 }
   }
 }

 module bar {
   ...
   import foo {
 ...
   }
   augment "/foo:target" {
 leaf new-leaf {
   type string;
 }
   }
}

 module baz {
   ...
   import foo {
 ...
   }
   container main {
 uses foo:target;
   }
}

giving an effective schema:

   container main {
 leaf address {
   type inet:ip-address;
   description "Target IP address.";
 }
 leaf port {
   type inet:port-number;
description "Target port number.";
 }
 leaf new-leaf {
   type string;
 }
   }

This construct seems to be well-defined to me, other than that it's not
immediately clear what namespace baz:main/new-leaf is in.  (For some
reason, I reflexively think that it's in bar's namespace, not baz's, but
I can't state any reasoning for that.)

2.  "augment" as a substatement of "uses"

In section 7.17:

   The "augment" statement allows a module or submodule ...  to add to
   the nodes from a grouping in a "uses" statement.

When I first read this, I took it to mean that an "augment" substatement
adds a peer node to the set of nodes 'from a grouping in a "uses"
statement'.  But I suspect that it is intended to mean that an "augment"
only adds nodes *under* one of the nodes from the grouping.  There's an
ambiguity that could be fixed by better wording.

7.17 also says:

   If the "augment" statement is a substatement to the
   "uses" statement, the descendant form (defined by the rule
   "descendant-schema-nodeid" in Section 14) MUST be used.

My understanding is that "descendant-schema-nodeid" is an XPath
expression, and that the "context node" for its evaluation is the node
to which the "uses" statement adds nodes -- but that doesn't seem to be
stated anywhere.

(Those last two I should have caught in my Gen-ART review!)

Thanks for any information,

Dale

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] tree diagrams - flags

[Dale R. Worley]

Martin Bjorklund  writes:
> Hmm, "*" was choosen b/c people are used to read it as
> "zero or more".  So for example:
>
>  +---c server* [name]
>  +--c name  string
>  ...
>
> means zero or more "server" elements.  Each indexed by "name".

>From RFC 7223:

   module ietf-interfaces {
 ...
 container interfaces {
   ...
   list interface {
 key "name";

 leaf name {
   type string;
 }

 leaf description {
   type string;
 }
   ...

There is a top-level container node "interfaces", which contains a list
node "interface", which contains a sequence of list elements which
consist of groups of (a leaf "name", a leaf "description", etc.), which
elements are indexed by the value of the "name" leaf.

Dale

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] tree diagrams - flags

[Dale R. Worley]

Ladislav Lhotka  writes:
> I think the "x" and "n" is only needed next to the name of 
> rpc/action/notification. So my version would be:
>
>  is one of:
>   c  for configuration data
>   x  for rpcs and actions
>   n  for notifications
>
> module: tree-sample
>   +--c config-true-container
>   |  +--c param?   string
>   +--- config-false-container
>   |  +--- value?   string
>   +--c inline-action
>   |  +--x action
>   | +--- input
>   | |  +--- in?   string
>   | +--- output
>   |+--- out?   string
>   +--c inline-notification
>  +--n notification
> +--- duration?   string

Naively, it seems to me that "c" for configuration and "s" for state
makes a great deal of sense.  ("cf" for state ("config=false") is
hazardous as "cf" is a natural contraction of "configuration".)
config/state is a somewhat messy distinction as the transition between
them can happen anywhere in the tree.

For RPCs, actions, and notifications, using a flag only for their top
nodes makes sense, because that makes it easy to find their top nodes,
and any node under them can only be assessed based on where it is
relative to the top node.

One thing that threw me the first time I saw it is marking lists with
"*".  That doesn't match the generic use of "*", which is to mark the
thing that is repeated.  (Compare using "?" to mark an optional thing,
which does match the generic usage.)  But in the context of Yang, you
don't want to flag the items in the list with "*", that would make the
tree harder to read.

I support having a rigid and consistent standard for indentation and
where the descending lines are placed under the parent nodes --
consistency in formatting allows one to train one's eye to parse the
diagram reflexively rather than having to pause and mentally group the
items into a structure.

Dale

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] augment and if-feature

[Dale R. Worley]

Robert Wilton  writes:
> To quote Joey's example,  I think that both of the following modules are 
> valid (presuming that they are both implemented by a device) regardless 
> of which features are enabled.  Do you agree?
>
> module base-module {
>prefix bmod;
>
>feature things;
>feature widgets;
>
>container things {
>  if-feature things;
>  ...
>  container widgets {
>if-feature widgets;
>...
>  }
>}
> }
>
> module augment-module {
>prefix amod;
>
>augment "/bmod:things" {
>  container other-things {
>  }
>}
>
>augment "/bmod:things/bmod:widgets" {
>  container other-widgets {
>  }
>}
> }

Does it remain valid if base-module is changed to:

module base-module {
   prefix bmod;

   feature things;
   feature widgets;

   container things {
 if-feature things;
 ...
 }
   }
}

As I analyze it, the augment statement is unconditional, but the
presence of its target node can be (1) unconditional, (2) conditional,
or (3) *never* present.

My preferred approach is that an augment is only valid if it is
"present" only if the target node is present (a condition I think can be
verified statically).  But if we allow the augment to silently have no
effect if the target node is not present in the current implementation,
do we still require that there is some possible implementation in which
the target node exists?

Dale

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] augment and if-feature

[Dale R. Worley]

Robert Wilton  writes:
> It isn't just any if-feature on the container that is being augmented 
> that needs to be considered.  You would have to consider all if-feature 
> statements by walking up the augmented node's ancestors to the top of 
> the tree and combine them, or have multiple if-feature statements.

Yes, I would expect that.

> Further, the 7950 YANG update rules allow for the augmented module to be 
> revised and some of those if-feature statements to be subsequently 
> removed.  If the augmenting module had restated the if-feature 
> conditions then this would probably leave the augmenting module 
> unintentionally out of sync with the module that it is augmenting.

It's an interesting sort of out-of-sync, though, as nothing would be
*incorrect*.  With some combinations of features, the augmented node
would have the agumentation and with some, it would not.  But it seems
to me that is quite OK, since whatever depends on the presence of the
augmentation (e.g., client logic or XPath expressions in the
augmentation) only expects the augmentation to be there if the
additional feature is present.

Dale

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] augment and if-feature

[Dale R. Worley]

JOEY BOYD  writes:
> module base-module {
>   prefix bmod;
>
>   feature do-things;
>
>   container things {
> if-feature do-things;
> ...
>   }
> }
>
> module augment-module {
>   prefix amod;
>
>   augment "/bmod:do-things" {
> container other-things {
> }
>   }
> }

First question:  I'm not expert in Yang, but as far as I can figure out,
the augment statement is augmenting "container things", right?  So the
augment statement should be 'augment "/bmod:things"' not 'augment
"/bmod:do-things"'.

But on the important question, I don't see it as at all unreasonable
that the augment needs to be qualified by the same if-feature.  The
reason is that if you're reading the text of module augment-module, it's
helpful to have documented, right there, that the augmentation depends
on the presence of a particular feature in the augmented module.  And
it's helpful to know that the designer did, at least for one moment,
think about the fact that the augmentation is conditional.

Dale

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11

[Dale R. Worley]

"Clyde Wildes (cwildes)"  writes:
> Thanks for the simplification. I have incorporated this in the next
> draft-ietf-netmod-syslog-model revision.

Ah, thanks!

Looking at -13, I see this:

   A syslog message is processed if:

   There is an element of facility-list (F, S) where
   the message facility matches F (if it is present)
  and the message severity matches S (if it is present)
   or the message text matches the regex pattern (if it is present)

I think you want to move the line "and the message severity ..." to the
left by two spaces so that the lines are aligned by how they are grouped
by the logical operators.  That would give:

   There is an element of facility-list (F, S) where
   the message facility matches F (if it is present)
   and the message severity matches S (if it is present)
   or the message text matches the regex pattern (if it is present)

Dale

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11

[Dale R. Worley]

(We seem to be well beyond the original LC date, but this is only an
editorial comment...)

The algorithm in section 3 isn't clear to me (possibly because I'm not
very familiar with syslog in practice):

   Selector processing (input is syslog message):

   1. Loop through facility-list
  a. Facility match processing - continue to the next entry in
 the list if no match
  b. Severity compare processing - continue to the next list
 entry if no match
  c. Match - proceed with the action and exit further processing
   2. Process pattern match if specified and if a match proceed with
  the action

If I understand correctly, a message is processed if it matches any one
element of facility-list OR the regexp.  In that case, I think you could
it clearer by writing the pseudocode in a style that is more functional
than imperative:

   A syslog message is processed if
   there is an element of facility-list (F, S) where
   the message facility matches F (if it is present)
   and the message severity matches S (if it is present)
   or the message text matches the pattern (if it is present)

Dale

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] How to constrain a leaf to a read-only list of supported values?

[Dale R. Worley]

Andy Bierman  writes:
> Back before there was YANG 1.0 I proposed the concept of constants in YANG
> but this was seen as too complicated.  This is the exact use-case I had in
> mind.
> The YANG module would #define the constants (maybe with a default or no
> value)
> and they could be used in statements. The vendors would set the constants at
> build or maybe the operators can set them at module load-time.

The difficulty in the scenario we are discussing (I think) is that the
list of valid values can be updated by the device, though presumably
infrequently (e.g., when the software is updated).  So the valid values
aren't determined by the module itself.

>   #define SUPPORTED_COMPRESSION_METHODS
>
>   must "compression-method ... SUPPORTED_COMPRESSION_METHODS";

I assume you can do this by writing the list of values directly in the
Xpath expression.  Not at all as nice, but at least it would work.

Dale

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] How to constrain a leaf to a read-only list of supported values?

[Dale R. Worley]

Ladislav Lhotka  writes:
>> typedef Compression-Method {
>>   ...
>> }
>>
>> list node {
>>   config true;
>>   key name;
>>
>>   string name;
>>
>>   leaf-list supported-compression-methods {
>> type Compression-Method;
>> config false;
>>   }
>>
>>   Compression-Method compression-method;
>>   must "compression-method ... supported-compression-methods";
>> }

> The only technical problem with your mock-up is that "must" expressions
> on config nodes cannot refer to state data.

Ouch!  That means that any technique like the one I proposed isn't going
to work.  Indeed, it may be that there is no way to constrain a config
leaf based on value(s) provided by the implementation.

Dale

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Using an empty type in a list key

[Dale R. Worley]

Andy Bierman  writes:
> Using a key of type empty is utterly pointless unless the point
> is to make the instance identifier longer.

IMO using a key of type empty (or any type with only one value) is
*pointless* but should be *valid*.  Things should be valid unless
processing them according to the ordinary rules can't work.  Indeed,
specifically banning them increases the complexity of the
specification.

The reason for this is that the code (in this case, the module
definition) may be generated by an automatic process, and those
processes are easier to construct if the rules contain fewer
irregularities.  E.g., multiplying a number by zero is pointless, in
that the result is always zero, and one might ask, Why not just write 0
instead of the multiplication?  But everyone agrees that the statement

a = 0 * b;

is *valid*, and can easily imagine situations where a process might
generate it as an output.

>> Unless I'm off, the line should be fixed to avoid the string
>> conversion:
>>
>>  /ex:system/ex:service[ex:name='foo'][ex:enabled]
>>
>> and a negation should be:
>>
>>  /ex:system/ex:service[ex:name='foo'][not(ex:enabled)]
>
> There is only one value provided by type empty.  The 2nd instance
> identifier is invalid.
> There is no instance possible that does not include the 'enabled' leaf.

The 2nd instance identifier is (should be) *valid* even if it always
returns the empty set.  (Assuming it is used in contexts where a set can
be returned.)

Dale

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Using an empty type in a list key

[Dale R. Worley]

"Sterne, Jason (Nokia - CA)"  writes:
> I saw the addition of empty types in list keys in YANG 1.1 but had
> troubles finding more details in the NETMOD list.  Is it discussed in
> the YANG 1.1 issues page (and if so, where is that now ?  I tried an
> old link and it didn't work) ?

> Doesn't the empty type have two states and the absence/presence of the
> leaf/tag indicates those states ?

The empty type has two states in the fullest sense, but remember that
missing values are not treated as first-class values.  In particular, if
a leaf is a key for a list, the leaf element must be present in all list
elements:

   7.8.2.  The list's key Statement

   The combined values of all the leafs specified in the key are used to
   uniquely identify a list entry.  All key leafs MUST be given values
   when a list entry is created.  Thus, any default values in the key
   leafs or their types are ignored.  It also implies that any mandatory
   statement in the key leafs are ignored.

So a leaf with empty type can be included in the key, but since it
always has the same value, it has no effect.

Dale

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] How to constrain a leaf to a read-only list of supported values?

[Dale R. Worley]

Balazs Lengyel  writes:
> Problem: how do you restrict values for (3) - file-compression so that 
> it is one of the nodes-supported-compression-types. The natural solution 
> would be to use a must expression or a leaf-ref, but as 
> nodes-supported-compression-types is config-false data, it is not 
> allowed to constrain the config=true leaf, file-compression, with it.

I'm no expert at this, but it seems to me that the way to do it is to
have the overall data structure be config-true but make the contained
supported-compression-types be config-false.  You can nest config-false
nodes in a config-true structure.  The Yang would be something like
this:

typedef Compression-Method {
  ...
}

list node {
  config true;
  key name;

  string name;

  leaf-list supported-compression-methods {
type Compression-Method;
config false;
  }

  Compression-Method compression-method;
  must "compression-method ... supported-compression-methods";
}

Dale

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts

[Dale R. Worley]

Andy Bierman  writes:
> An Internet-Draft is NOT a means of "publishing" a specification;

As I said, that's the theory, but practice is considerably different.

Dale

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts

[Dale R. Worley]

William Lupton  writes:
> Regardless of the discussion about “published”, other organisations
> may be planning to use YANG modules that are currently within
> IDs. Obviously it’s vastly preferable if such IDs become RFCs before
> these other organisations publish any specifications or data models
> that use such draft IETF YANG, but it might occasionally be necessary
> to reference a draft model (hopefully one that has already been sent
> for AD review) in a published standard. This is why I would like the
> clarification to cover IDs (at least WG-adopted ones)!

Unfortunately, this sort of problem has to be considered.  I remember
when the "SIP multiple line appearances" draft was being worked on.
Ultimately, there were products on the market that supported the -03
version, the -04 version, and the final (RFC) version.

My suggestion is that any time a version of a module is "published", it
must either be identical to the previous "published" version, or have a
newer revision date.  As far as I can see, the *practical* meaning of
"published" is a document that has a permanent URL, because you can't
convince a customer that a document is a "specification" if it doesn't
have a stable URL.  For Internet Drafts, that seems to mean each
numbered version entered into the Data Tracker.

But there is a further problem:  A sequence of versions of a module with
different revision dates are required to be related by the rules of
section 11 of RFC 6020 (or draft-ietf-netmod-rfc6020bis), i.e., each
newer version is a proper extension of the older version(s).  Clearly,
we *don't* want to have that constraint between versions of modules in a
sequence of I-Ds, we want to be able to delete elements.

Dale

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] YANG 1.1: XML naming restriction

[Dale R. Worley]

William Lupton  writes:
> But the errata at https://www.w3.org/XML/xml-V10-5e-errata
>  say the following. There
> are also related changes to Section 2.6 (processing instructions) and
> Section 3 (logical structures).

>> Section 2.3 Common Syntactic Constructs 
>> 
>> Delete the following paragraph:
>>
>> Names beginning with the string "xml", or with any string which would
>> match (('X'|'x') ('M'|'m') ('L'|'l')), are reserved for
>> standardization in this or future versions of this specification.

Hmmm, I'd not heard of that.  But let me also quote this part of the
same errata, which is the new version of section 3:

>> This specification does not constrain the application semantics, use,
>> or (beyond syntax) names of the element types and attributes, except
>> that names beginning with "xml:" are reserved for standardization in
>> this or future specifications from the XML Core Working Group or its
>> successors.

If I read everything correctly, the only reserved names are now:

- beginning with "xml:" (the revised XML spec)
- the attribute "xmlns" (XML Namespaces spec)
- attributes beginning "xmlns:" (XML Namespaces spec)
- the attributres "xml:base" and "xml:id" (other XML specs, per Wikipedia)

And it seems that the only way to use Yang to cause the creation of an
XML name that violates those rules is to define a prefix "xml", which
will appear on element names.  But maybe even that one exclusion isn't
true, since the use of a Yang prefix as an XML namespace name is not
mandatory; the processor is allowed to use a different prefix if there
is a "conflict".  (6020bis, section 7.1.4)

Dale

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] YANG 1.1: XML naming restriction

[Dale R. Worley]

Andy Bierman  writes:
> The YANG 1.1 ABNF says:
>
>;; An identifier MUST NOT start with (('X'|'x') ('M'|'m') ('L'|'l'))
>identifier  = (ALPHA / "_")
>  *(ALPHA / DIGIT / "_" / "-" / ".")
>
>
> There is no explanation given why.
> The same restriction was copied to RESTCONF, also without explanation.
> Supposedly, XML does not allow identifiers to start with XML.
>
> Looks like this restriction only applies to the PITarget [17], not Name [5]
> https://www.w3.org/TR/REC-xml/#sec-pi
>
> We have been applying this restriction to element names
> but it only applies to processing instructions.
>
> IMO it should be removed.
> It confuses people when they get an error for naming a data node
> with a string that matches.

Eh?  Looking at "Extensible Markup Lanuage (XML) 1.0 (Fifth Edition)",
section 3.1 (http://www.w3.org/TR/xml/#sec-starttags) says that the
element name of a start in end tag is a "Name".  Looking at section 2.3
(http://www.w3.org/TR/xml/#sec-common-syn), I see

Names beginning with the string "xml", or with any string which
would match (('X'|'x') ('M'|'m') ('L'|'l')), are reserved for
standardization in this or future versions of this specification.

And since Yang data node names can appear as XML element names, Yang has
to forbid node names that start with "XML".

Dale

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] should the must statement be listed as a "Common Statement"?

[Dale R. Worley]

Xiang Li  writes:
> I find it is a bit strange that the must statement (7.5.3 and 7.5.4)
> is organized under 7.5 The container statement. I would think it
> makes more sense to be listed as a "Common Statements".

That's true.  "must" can be a substatement of the container, leaf,
leaf-list, list, anydata, anyxml, refine, input, output, notification,
deviate-add, and deviate-delete statements.

Dale

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] grouping if-feature

[Dale R. Worley]

Martin Bjorklund  writes:
> Michal Vasko  wrote:
>> in NETCONF server draft [1] there is ietf-ssh-server model. It defines
>> feature "ssh-x509-certs" and then uses it twice in a
>> grouping. Referring to RFC 6020 [2] (I haven't noticed any difference
>> in the YANG 1.1 draft), in a grouping prefixes, type names, grouping
>> names, and extensions should be resolved in the context of the uses
>> that referenced this grouping. What about if-feature, where should
>> that be resolved?
>
> It is resolved locally (lexically).

The feature name is resolved in the context where a data node is
created.  Feature names are local to the module:

6.2.1

   o  All feature names defined in a module and its submodules share the
  same feature identifier namespace.

So the uses of the feature "ssh-x509-certs" in ietf-netconf-server and
ietf-ssh-server are different features.  It seems to me that the feature
must be declared in both modules, which it is, by separate declarations
in each module.  In principle you could put the feature statement in the
grouping statement, but the syntax doesn't allow that; a feature
statement has to be the child of a module or submodule statement.

Dale

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Request to review the YANG compiler annotations draft.

[Dale R. Worley]

Martin Bjorklund  writes:
> "vinods.kumar"  wrote:
>> We have written a draft, to add annotation in YANG definition which can
>> be used by the YANG compilers.
>
>   1)  What you propose is not valid YANG.  This new syntax would
>   require a new version of the YANG language.

I must vigorously agree with the other commentators that if the
annotations are permitted to be in-line in a Yang module, then you must
develop a syntax that is valid Yang.  Otherwise, an annotated Yang file
isn't processable by an arbitrary Yang processor, it is bound to a
special processor, and isn't really a Yang file at all.

If the concept of more-or-less implementation independent annotations is
adopted, it seems to be best to put it conceptually in the framework by
which one Yang module extends another module.

Dale

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] contact statement content

[Dale R. Worley]

Kent Watsen  writes:
> 1) Remove the text "In addition, the Area Director and other contact
> information MAY be present", as there is no reason to hint that
> listing ADs makes sense.

If there's a role email address for the relevant Area Director, that is
likely to be more stable than the working group address, since areas are
expected to be semi-permanent, whereas WGs are assumed to have a finite
lifetime.  Of course, a personal address for an AD will likely be less
stable.

Dale

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] contact statement content

[Dale R. Worley]

Kent Watsen  writes:
> One related nit, is the "WG" acronym widely known enough to use it in
> the template?   How the following instead?
>
> OLD
>contact
>"WG Web:   
> WG List:  
>
> NEW
> contact
>"Web Page:
>  Mailing List:  

If you take out the acronym "WG", in what way does that make the
remaining words more descriptive?  I can see arguing for "WG Web Page"
and "WG Mailing List", though.

Dale

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Must on actions without input or output parameters

[Dale R. Worley]

Balazs Lengyel  writes:
> BALAZS:  From 6.4.1.  XPath Context
> "If the XPath expression is defined in a substatement to an "input"
>statement in an "rpc" or "action" statement, the accessible tree
>is the RPC or action operation instance, all state data in the
>server, and the running configuration datastore."
>
> So if I define a "must" in the input of an action the normal data tree 
> IS visible.

Interesting...

I'm not sure, but I think that the spec may omit something:

6.4.1:

   o  If the XPath expression is defined in a substatement to an "input"
  statement in an "rpc" or "action" statement, the accessible tree
  is the RPC or action operation instance, all state data in the
  server, and the running configuration datastore.  The root node
  has top-level data nodes in all modules as children.
  Additionally, for an RPC, the root node also has the node
  representing the RPC operation being defined as a child.  The node
  representing the operation being defined has the operation's input
  parameters as children.

6.4.1.1:

   Given the following module:

 module example-a {
   yang-version 1.1;
   namespace urn:example:a;
   prefix a;

   container a {
 list b {
   key id;
   leaf id {
 type string;
   }
   notification down {
 leaf reason {
   type string;
 }
   }
   action reset {
 input {
   leaf delay {
 type uint32;
   }
 }
 output {
   leaf result {
 type string;
   }
 }
   }
 }
   }
   [...]
 }

   The accessible tree for an action invocation of "reset" on /a/
   b[id="1"] with the "when" parameter set to "10" would be:

 
   
 1
 
   10
 
   
   
 2
   
 
 // possibly other top-level nodes here

I don't see where the insertion of the action node (the "reset") into
the datastore tree is specified for XPath evaluation.  (7.15 describes
how the combined XML is encoded for the request and response, and 6.4.1
describes the combined tree for input nodes for RPCs.)

Dale

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Must on actions without input or output parameters

[Dale R. Worley]

Balazs Lengyel  writes:
[edited]
> container myThing {
> leaf enabled { type boolean;}
> action start {
>input {
>   // optional so I can just ignore it
>   leaf dummy-leaf-never-use-it { type empty; }
>   must "../enabled = 'true'";
>}
>
> My question is why do I need to do this ugly solution? Is there a better 
> way?
> Is there a reason why I really need the dummy leaf?
> Is there a reason why the rfc does not allow an input field with a 
> single must statement in it?

I suspect that is because nobody envisioned that an input statement with
only a 'must' could be useful.  You've provided a counterexample to that
idea.

Dale

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] list keys out of order

[Dale R. Worley]

Andy Bierman  writes:
> Where does is say the server MUST reject list keys provided by the client
> that are out of order?  Where does is say what error-tag is returned?

Maybe this is due to my inexperience, but I read the text of 7.8.4, "A
list is encoded ..." as "When translating an abstract data structue into
XML, you encode ...".  That is, these are the rules for how a server
*writes* XML.

What this leaves unspecified, or only implied, are the rules for
*reading* XML.

The correct solution, IMO, is that the text should explicitly address
writing and reading seperately, or state that they are identical.
(Generally, programming language specs describe input and output
operations seperately.)

Dale

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Must on actions without input or output parameters

[Dale R. Worley]

Balazs Lengyel  writes:
> We only want to allow starting myThing (calling the start action) if
> it is enabled.
> However we
> - can not put a must under action according to the RFC/draft
> - while the RFC would allow us to put an empty input under action with
> only the must statement in it, pyang complains about the absence of
> data definition nodes.

Reading the specification of the must statement (section 7.5.3), the
concept that must declares a *constraint*, which is evaluated at commit
time as specified in section 8.

Reading 8.1, I see that it describes which constraints are applied at
what times.  No only are they used to validate the datastore at commit
time, they also are used to validate the inputs and outputs of actions,
etc.  The scope of the XPath expression in such a must is the input data
tree of the action, not the datastore.

So there is no way to specify in Yang a constraint on the datastore that
must be satisfied for an action to be valid.

In regard to "input", it isn't said plainly in section 7.14, but the
ABNF makes clear that it must contain at least one data-def-stmt.  But
if the action has no inputs, the input statement can be omitted.

Dale

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] The Restconf root

[Dale R. Worley]

(I'm new to the Netconf mailing list, so it's possible that this issue
has already been disposed of.)

Looking at draft-ietf-netconf-restconf-13, it looks like the RFC 7320
mechanism is used to find the root URL, from which all the Restconf URLs
are derived by appending path components as specified in the draft.

But looking at RFC 6570, which is referenced by both 7320 and the draft,
it seems that specifying path components to be appended a configured
base URL is no longer best practice, because it requires the HTTP server
to be able to connect all those URLs to the Restconf server despite
their different paths.  It seems that the new, improved method is to
advertise a URL template, and the client should use the template and the
Restconf "additional path" to construct the URL to be used.

E.g., now, the second example in section 3.1 shows how the Restconf root
is obtained:

  Request
  ---
  GET /.well-known/host-meta HTTP/1.1
  Host: example.com
  Accept: application/xrd+xml

  Response
  
  HTTP/1.1 200 OK
  Content-Type: application/xrd+xml
  Content-Length: nnn

  
  
  

and used, with the sub-URL "operations":

  Request
  ---
  GET /top/restconf/operations  HTTP/1.1
  Host: example.com
  Accept: application/yang.api+json

RFC 6570 seems to suggest that the first lookup should return a URL
template:

  Request
  ---
  GET /.well-known/host-meta HTTP/1.1
  Host: example.com
  Accept: application/xrd+xml

  Response
  
  HTTP/1.1 200 OK
  Content-Type: application/xrd+xml
  Content-Length: nnn

  
  
  

The value of this being that a different server might return the
template 'http://example.com/top/restconf{?resource}', causing the
second request to use the URL
'http://example.com/top/restconf?resource=operations'.

Although this probably requires a revision of the href attribute of the
Link element, since it now carries a URL template rather than a URL.

Dale

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Tokenizing and strings (was: Gen-ART IETF Last Call review of draft-ietf-netmod-rfc6020bis-12 (part 2))

[Dale R. Worley]

Juergen Schoenwaelder  writes:
> I think we should consider this for a future version of YANG but not
> now. I am not aware what implementors had problems to implement YANG
> strings in YANG 1 or YANG 1.1 and we are at a point in the process
> where I like to not run the risk to make bigger changes to the
> specification that may turn out to introduce incompabilities.

I've written an issue about it
(https://github.com/netmod-wg/yang-next/issues/6), so it can be
considered for the next revision.

Dale

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] The Restconf root

[Dale R. Worley]

Looking at draft-ietf-netconf-restconf-13, it looks like the RFC 7320
mechanism is used to find the root URL, from which all the Restconf URLs
are derived by appending path components as specified in the draft.

But looking at RFC 6570, which is referenced by both 7320 and the draft,
it seems like appending path components to a configured base URL is no
longer best practice, because it requires the HTTP server to be able to
connect all those URLs to the Restconf server despite their different
paths.  It seems like the new, improved method is for a URL template to
be advertised, and the Restconf client should use the template and the
Restconf specification to construct the URL to be used.

E.g., now, the example in section 3.1 shows how the Restconf root is
obtained:

  Request
  ---
  GET /.well-known/host-meta HTTP/1.1
  Host: example.com
  Accept: application/xrd+xml

  Response
  
  HTTP/1.1 200 OK
  Content-Type: application/xrd+xml
  Content-Length: nnn

  
  
  

and used, with the sub-URL "operations":

  Request
  ---
  GET /top/restconf/operations  HTTP/1.1
  Host: example.com
  Accept: application/yang.api+json

RFC 6570 seems to suggest that the first lookup should return a URL
template:

  Request
  ---
  GET /.well-known/host-meta HTTP/1.1
  Host: example.com
  Accept: application/xrd+xml

  Response
  
  HTTP/1.1 200 OK
  Content-Type: application/xrd+xml
  Content-Length: nnn

  
  
  

The value of this being that a different server might return the
template 'http://example.com{?resource}', causing the second request to
use the URL 'http://example.com?resource=operations'.

Although this probably requires a redefinition of the href attribute of
the Link element.

Dale

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] update on "rdns" URN for enterprise YANG models

[Dale R. Worley]

When I see a requirement for globally unique names, I always think
fondly of the "oid" series of URNs, which are based on the ITU object
identifiers.  See RFC 3001.  You write to IANA to get an assignment of a
"private enterprise number", which you can use to coin object
identifiers which are guaranteed to be unique.  For instance, I've been
assigned OID 1.3.6.1.4.1.14490.

So I can use urn:oid:1.3.6.1.4.1.14490.1,
urn:oid:1.3.6.1.4.1.14490.2, urn:oid:1.3.6.1.4.1.14490.3, etc., and be
assured that they're globally unique.

(If you want a subtree to experiment with, I can allocate on to you!)

Sadly, nobody else seems to be taken with the extreme elegance of the
OID system.

Dale

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Tokenizing and strings

[Dale R. Worley]

"Jernej Tuljak"  writes:
> You are also forgetting the fact that the existing 'string' production
> expects  an "unquoted string as returned by the scanner" (no quotes,
> no concats, no pretty printing whitespace).

I must admit I've never understood what that bit of the text means.

Dale

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Tokenizing and strings (was: Gen-ART IETF Last Call review of draft-ietf-netmod-rfc6020bis-12 (part 2))

[Dale R. Worley]

At this point, I think there are some aspects of the use of strings and
identifiers that aren't completely specified, but I'd have to check the
current text to know for certain.  However, that's a minor matter.

The issue that concerns me is that the ABNF doesn't specify what is
allowed as a string.  I'm used to programming language definitions,
where the grammar is specified quite rigidly, to the point that the ABNF
can be input to a parser generator.  In this document, the ABNF is quite
complete except for a specification of strings.  On the other hand, the
text description of strings seems to be sufficient for an implementer,
so we don't actually need to provide ABNF.  My strong preference is to
provide a complete ABNF, as is the norm for programming languages.

The following is a complete ABNF for Yang strings.  Of course, it's a
bit complicated, because the definition of strings in Yang actually is a
bit complicated.

   string  = unquoted-string / quoted-string

   unquoted-string = *unquoted-item ( unquoted-item /
  "/" /
  "*" *"*" )
 ;; a sequence of one or more characters from
 ;; ordinary-char / "/" / "*", not containing
 ;; "//", "/*", or "*/"

   unquoted-item   = ordinary-char /
 "/" ordinary-char /
 "*" *"*" ordinary-char

   ordinary-char   = < any character matching yang-char, except >
 < space, tab, newline, carriage return,>
 < semicolon, left brace, right brace,  >
 < slash, and asterisk  >

*** Hmmm, is an unaccompanied CR allowed in an unquoted string?  If
so, "ordinary-char" and my previous text regarding line breaks need
to be amended.

   quoted-string  = ( single-quoted-string / double-quoted-string )
*( optsep "+" optsep
   ( single-quoted-string / double-quoted-string ) )

(I think you said that there can be whitespace around + but not comments.)

   single-quoted-string = SQUOTE *sq-char SQUOTE

   sq-char= < any character matching yang-char, except >
< SQUOTE   >

   double-quoted-string = DQUOTE *dq-item DQUOTE

   dq-item= dq-char /
"\n" /
"\t" /
"\" DQUOTE /
"\\"

   dq-char= < any character matching yang-char, except >
< DQUOTE and backslash >

(The existing production for yang-string is removed.)

   ;; any Unicode or ISO/IEC 10646 character including tab, carriage
   ;; return, and line feed, but excluding the other C0 control
   ;; characters, the surrogate blocks, and the noncharacters.
   yang-char = %x09 / %x0A / %x0D / %x20-D7FF /
   [continuing as before]

Dale

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Gen-art] Gen-ART IETF Last Call review of draft-ietf-netmod-rfc6020bis-12 (part 1)

[Dale R. Worley]

Martin Bjorklund  writes:
> Do you have an suggestion for what to write?  These kinds of
> multi-line strings are almost always 'description' statements,
> used for human consumption.  It is not clear to me what the warning
> would be.

>> So you can't write an isolated CR in most of a Yang module.  But am I
>> correct in understanding that you *can* write an isolated CR inside a
>> single-quoted string (and presumably, a double-quoted string)?
>
> Yes.

I think all of this could be summarized well by putting a paragraph that
tells everything about line ends in Yang at the end of section 6.
Section 6 already deals with the valid characaters for Yang, how they're
encoded, etc.

Lines in a YANG module may end with a carriage return-line feed
combination or with a line feed alone.  A carriage return that is not
followed by a line feed may only appear inside a quoted string.  Note
that carriage returns and line feeds that appear inside quoted strings
become part of the value of the string without modification; the value
of a multi-line quoted string contains the same form of line ends as
those lines of the YANG module.

In a way, that doesn't add much to the specification.  As I think you
said, "Line ends aren't special in Yang."  But it does spell out exactly
when CR and LF can be used, and it warns readers against misleading
analogies from other programming languages (where line ends usually are
special).

Dale

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Replacing a YANG submodule with a module

[Dale R. Worley]

Martin Bjorklund  writes:
>> If I understand Yang correctly, that error can't be fixed by revising
>> the new module test to clone mod:util as test:util, because though the
>> new grouping is semantically identical to the old grouping, it's still a
>> change in its definition:
>
> Hmm, why do you think that this isn't allowed?  If the syntax and
> semantics are the same it should be allowed.  Section 11 has:
>
> - Any set of data definition nodes may be replaced with another set of
>   syntactically and semantically equivalent nodes.  For example, a set
>   of leafs may be replaced by a uses of a grouping with the same
>   leafs.

Ugh, that's my mistake.  I started skimming the list of criteria and saw
that they were all specific changes as to what was allowed and didn't
realize that the ones near the bottom were quite general.  In that case,
this version should be OK in that the grouping util is still defined by
module test:

 module test {
   namespace "urn:bbf:yang:test";
   prefix test;

   import mod {
 prefix mod;
 revision-date 2016-06-08;
   }

   revision 2016-06-08 {
   }

   uses mod:util;

+  grouping util {
+uses mod:util;
+  }
 }

Dale

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Gen-art] Gen-ART IETF Last Call review of draft-ietf-netmod-rfc6020bis-12 (part 2)

[Dale R. Worley]

From: Juergen Schoenwaelder 
> An unquoted string is any sequence of characters and does not
> contain any space, tab, or newline characters, a single or double
> quote character, a semicolon (";"), braces ("{" or "}"), or
> comment sequences ("//", "/*", or "*/").
> 
> Note that any keyword can legally appear as an unquoted string.

That text seems to be quite clear to me.  As Juergen notes, it directly
points out to the implementor an important fact about lexing Yang.
(Similarly, some programming languages allow keywords to be used as
identifiers, they're not reserved.)

Martin Bjorklund  writes:
>> If I understand correctly, the tokens of Yang (as the term is usually
>> used in programming languages) are:
>> 
>> whitespace (which is ignored)
>> comments (which is ignored)
>> single-quoted strings
>> double-quoted strings
>> unquoted strings (including keywords)
>> ;
>> {
>> }
>> 
>> >From the point of view of the tokenizer, these tokens fall into the
>> obvious classes:
>> 
>>  typeunquoted string
>>  "type"  double-quoted string
>>  abc unquoted-string
>>  "abc"   double-quoted string
>>  '---'   single-quoted string
>> 
>> I'm not quite sure how they are classified from the parser's point of
>> view, though.
>> 
>>  type"type"  abc "abc"   '---'
>> 
>> Is a string? ?   Y   ?   Y   Y
>> (Can it appear as the
>> argument of "description"?)
>> 
>> Is a keyword?Y   ?   N   N   N
>> (Can it appear as the first
>> token of some statement?)
>> 
>> Is an identifier?Y   ?   Y   ?   N
>> (Can it appear as the second
>> token of a type statement?)
>> 
>> Usually programming languages use the particular syntax of different
>> types of tokens to determine where they can be used in the
>> context-free grammar.  Yang seems to be more relaxed, but I'm not sure
>> whether it is so relaxed thay any of the types of string tokens can be
>> used anywhere.
>
> No; a keyword must be written w/o quotes, so it is special.

OK, that answers one '?'.  But there are effectively two that remain:

Is abc   valid as a string?
Is "abc" valid as an identifier?

I *think* the answer is No for both of those, but I can't put my finger
on the rules that make that definite.

>> There are two types that don't have a canonical form, identityref and
>> instance-identifier.  It seems that comparisons in XPath expressions
>> are inexact if the type doesn't have a canonical form (section 6.4).
>> But if I understand you correctly, the implicit comparisons in leafref
>> are done based on the abstract values involved, not the lexical
>> representation.
>
> Yes.

I'm willing to take that as understood.

>> > > The current ABNF doesn't allow for "+" for joining quoted strings.
>> > > Also, it doesn't show that \" can be included in a double quoted string
>> > > to include a literal ", and allows the string contents to continue --
>> > > the current ABNF "DQUOTE string DQUOTE" matches "abcd\", despite that
>> > > the latter is not a proper double-quoted string.
>> > 
>> > Note that the prose text (within <...>) says "a string that
>> > matches...".  That string can be any YANG token string, for example
>> > one of:
>> > 
>> >"hello"
>> >"he" + "llo"
>> 
>> If I haven't gotten confused, you're referring to
>> 
>>string  = < an unquoted string as returned by >
>>  < the scanner, that matches the rule >
>>  < yang-string >
>> 
>>yang-string= *yang-char
>> 
>>;; any Unicode or ISO/IEC 10646 character including tab, carriage
>>;; return, and line feed, but excluding the other C0 control
>>;; characters, the surrogate blocks, and the noncharacters.
>>yang-char = %x09 / %x0A / %x0D / %x20-D7FF /
>>; exclude surrogate blocks %xD800-DFFF
>>   %xE000-FDCF /; exclude noncharacters %xFDD0-FDEF
>>   %xFDF0-FFFD /; exclude noncharacters %xFFFE-
>>   %x1-1FFFD /  ; exclude noncharacters %x1FFFE-1
>>   %x2-2FFFD /  ; exclude noncharacters %x2FFFE-2
>>   %x3-3FFFD /  ; exclude noncharacters %x3FFFE-3
>>   %x4-4FFFD /  ; exclude noncharacters %x4FFFE-4
>>   %x5-5FFFD /  ; exclude noncharacters %x5FFFE-5
>>   %x6-6FFFD /  ; exclude noncharacters %x6FFFE-6
>>   %x7-7FFFD /  ; exclude noncharacters %x7FFFE-7
>>   %x8-8FFFD /  ; exclude noncharacters %x8FFFE-8
>>   %x9-9FFFD /  ; exclude noncharacters %x9FFFE-9
>>   %xA-AFFFD /  ; exclude noncharacters %xAFFFE-A
>>   %xB-BFFFD /  ; exclude noncharacters %xBFFFE-B
>>   %xC-CFFFD /  ; exclude noncharacters %xCFFFE-C
>>

Re: [netmod] [Gen-art] Gen-ART IETF Last Call review of draft-ietf-netmod-rfc6020bis-12 (part 1)

[Dale R. Worley]

Martin Bjorklund  writes:
>> > > > > It is worth noting (either here or in 6.1.3) how line-breaks inside
>> > > > > quoted strings are transcribed into the string's value.  As now
>> > > > > written, it seems that the line-break is transcribed identically to
>> > > > > how it is represented in the source.  That means (1) If the source is
>> > > > > recoded with the other type of line break, the semantics of the Yang
>> > > > > code change; and (2) if the source uses line-breaks of one type (CRLF
>> > > > > or LF), only that type can be directly transcribed into string 
>> > > > > values.
>> > > > > (But regardless of the source line-breaks, an LF can be transcribed
>> > > > > into a double-quoted string with "\n".  But a CRLF cannot be
>> > > > > transcribed into a double-quoted string with escape sequences.  Was
>> > > > > that intended, or was "\r" intended to be legal?)
>> > > 
>> > > Don't forget this.
>> 
>> I was wondering that (as the text is written) the value of a quoted
>> string that includes a line end will change if the line ends are
>> changed (say, by moving the Yang file to a different host).  Normally
>> computer languages are defined so that changing how the program is
>> "represented", e.g., by transforming it into a form with different
>> line-ends, won't change the semantics of the program.
>> 
>> But if it's true, I seems desirable to provide an explicit warning
>> about it.

It still seems to me to be valuable to warn about this.

>> > You can always get the same effect by using single quoted strings.
>> 
>> I don't see how you can get a single CR using single-quoted strings,
>> because line ends are only allowed to be LF and CR-LF; writing a CR
>> without an LF following it isn't allowed.  Or is it that in practice,
>> Yang 1 allows people to use CR alone, and it is not interpreted as a
>> line-end?
>
> If the module has a string like this:
>
>0x27 0x0d 0x27
>
> it is a string with a single CR.

I see in the grammar:

   line-break  = CRLF / LF

So you can't write an isolated CR in most of a Yang module.  But am I
correct in understanding that you *can* write an isolated CR inside a
single-quoted string (and presumably, a double-quoted string)?

Dale

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] leafref value space and constraint

[Dale R. Worley]

Martin Bjorklund  writes:
> The text for "path" already says:
>
>   It takes as an argument a
>   string that MUST refer to a leaf or leaf-list node.

Given what the text must mean, that's sufficient for me.

Ladislav Lhotka  writes:
> Which of the two "foo" leaf nodes does the path argument point at? If
> the path is interpreted in the schema tree, it may appear it is the
> one inside the choice. Yes, we all know it points at the other one,
> but will all readers of the spec come to the same conclusion?

Well, in 9.9.2 it says:

   The "path" XPath expression is conceptually evaluated in the
   following context, in addition to the definition in Section 6.4.1:

   o  If the "path" statement is defined within a typedef, the context
  node is the leaf or leaf-list node in the data tree that
  references the typedef.

   o  Otherwise, the context node is the node in the data tree for which
  the "path" statement is defined.

What's really going on is that the XPath expression will always be
evaluated in the context of a particular element of a particular data
tree, but that it can be shown to be always valid by doing a "generic
evaluation" of the expression looking at the schema tree -- the schema
tree is a generic description of all possible data trees.  Of course
there are various complications because not all nodes in the schema tree
are represented in the XML tree.

In mathematics, abstracting an operation in a particular structure to a
similar operation in a "generic" structure is called "lifting", and
using that term, it's easy to notify the reader what you're doing
without spelling out the details.  What's difficult here is that it's
"obvious" what the text has to mean, but we have no simple vocabulary
for pointing that out, and the reader who is not careful might not
realize everything that is going on.

At this point, I'm willing to ignore the issue.  There doesn't seem to
be a simple way to explain the critical issue.  And if the reader
attempts to work out the details of Yang processing, he eventually has
to come to the correct conclusion; there is only one self-consistent
interpretation.

Dale

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] leafref value space and constraint

[Dale R. Worley]

wor...@ariadne.com (Dale R. Worley) writes:
> [...]
> Yes, it's difficult to explain, though once one gets the idea, it's
> straightforward enough.  The problem I have is that it's not pointed out
> explicitly anywhere.  (E.g., Juergen suggests section 9.9.2, but I don't
> see it there.)
>
> The crucial points seem to be:
>
> - The XPath expression is limited by the syntax "path-arg" and the rules
>   in 9.9.2.
>
> - Because of those restrictions, there exists one data node in the
>   schema such that:  evalutating the expression for any leaf or
>   leaf-list node in any data tree returns a set of nodes, all of which
>   are instances of that one schema node.

Interestingly, there's a sort-of dependency on the fact that
grouping/uses can't be recursive.  If I could define a general binary
tree data structure:

grouping tree-grouping {
  container left-child {
uses tree-grouping;
  }
  container right-child {
uses tree-grouping;
  }
  leaf data1 {
type string;
  }
  leaf data2 {
type leafref {
  path "../left-child/data1";
}
  }
}

container a {
  use tree-grouping;
  container left-child {
leaf data1 {
  type integer;
}
  }
}

statically validating the leafref would take a clever algorithm, because
the parent element of a data2 element can be a left-child container, a
right-child container, or an 'a' container.

But since groupings cannot be instantiated recursively, the validator
can "macro expand" all 'uses' statements and then validate every
instance of the leaf data2; for each instance of data2, the parent
element is unique, making interpretation of the path simple.

Dale

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Replacing a YANG submodule with a module

[Dale R. Worley]

William Lupton  writes:
> Consider the YANG module, submodule and tree files shown
> below. Suppose that I regret the decision to make "submod" be a
> submodule and want to replace it with a module (see listings further
> down). This works, the tree file is identical, and pyang
> --check-update-from is happy, but strictly the interface has changed
> (the util grouping has moved from the urn:bbf:yang:test namespace to
> the urn:bbf:yang:mod namespace). Is this intended to be valid (I don't
> see it mentioned in RFC 6020bis Section 11)?

I'm not sure what a "tree file" is.  But it turns out that the XML for
data trees doesn't change.  The reason for that is that in the second
example, the util *grouping* is in the module mod, but the schema node
(which is the prototype of an XML element in a data tree) is in the
module test, where the uses statement is, and so the "util" XML element
will be in the XML namespace of module test.  See section 7.13:

   The identifiers defined in the grouping are not bound to a namespace
   until the contents of the grouping are added to the schema tree via a
   "uses" statement that does not appear inside a "grouping" statement,
   at which point they are bound to the namespace of the current module.

In regard to assigning schema nodes to an XML namespace, the uses acts
like a macro expansion, while in regard to resolving references to Yang
identifiers, uses/grouping is lexically scoped.

Martin Bjorklund  writes:
> You have removed the "util" grouping from the module "test".  This is
> not allowed according to the upgrade rules.

["upgrade" means "updating" and refers to section 11.]

If I understand Yang correctly, that error can't be fixed by revising
the new module test to clone mod:util as test:util, because though the
new grouping is semantically identical to the old grouping, it's still a
change in its definition:

 module test {
   namespace "urn:bbf:yang:test";
   prefix test;

   import mod {
 prefix mod;
 revision-date 2016-06-08;
   }

   revision 2016-06-08 {
   }

   uses mod:util;

+  grouping util {
+uses mod:util;
+  }
 }

Dale

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] leafref value space and constraint

[Dale R. Worley]

Ladislav Lhotka  writes:
> "Dale R. Worley"  writes:
>> A difficulty I have with the current wording is that it doesn't point
>> out the crucial fact about leafref that the XPath expression can only
>> select elements that are instantiations of one particular data node.  I
>> don't know XPath, but it seems that that is not a general property of
>> XPath expressions, you seem to be able to write XPath expressions that
>> select heterogenous groups of elements.  So it's worth pointing out that
>> the allowed XPath expressions can't do that, and that is because of the
>> restriction that the expression must match path-arg.
>
> Right, this is the slightly hand-waving part that I also objected to. An
> XPath expression in a leafref's "path" statement indeed selects a node
> set from an instance data tree. The node seet can be empty, but if it is
> non-empty, all its members necessarily have the same type, which is
> defined in a certain "leaf" schema node.
>
> The relationship is relatively straightforward but difficult to explain
> concisely. One basically has to follow the steps in the XPath
> expression, ignore all path-predicates, and skip all schema nodes that
> aren't data nodes (i.e., "choice" and "case" nodes).

Yes, it's difficult to explain, though once one gets the idea, it's
straightforward enough.  The problem I have is that it's not pointed out
explicitly anywhere.  (E.g., Juergen suggests section 9.9.2, but I don't
see it there.)

The crucial points seem to be:

- The XPath expression is limited by the syntax "path-arg" and the rules
  in 9.9.2.

- Because of those restrictions, there exists one data node in the
  schema such that:  evalutating the expression for any leaf or
  leaf-list node in any data tree returns a set of nodes, all of which
  are instances of that one schema node.

- The type of that schema node is the base type of the leafref.

- Once you learn this, it's easy to see, for any particular
  leaf/leaf-list node and path expression in a module, which schema node
  is the one.  But it's rather hard to describe that process.

Actually, there's an ugly question:  If the path expression references
an element name that doesn't exist in the module.  Perhaps there are
rules in XPath that prevent it, but it seems to me that you could write

 leaf mgmt-interface {
   mandatory false;
   type leafref {
 path "../interface/name";
 require-instance true;
   }
 }

when the current module doesn't have a "name" child defined for
"interface".  As long as a data tree didn't contain a mgmt-interface
elememt, the constraint would not be violated.

But a later revision of the module, the "name" child could be added,
allowing data trees to contain mgmt-interface elements, because data
trees could now have "name" elements.

The point being that when you're figuring out which schema node is the
base type for the leafref, that schema node has to exist so the base
type can be extracted.  But there's no direct statement of that as a
requirement for path validity.

Dale

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Gen-art] Gen-ART IETF Last Call review of draft-ietf-netmod-rfc6020bis-12 (part 2)

[Dale R. Worley]

(This is the second part of my response.)

> > > > - section 6.1
> > > > 
> > > >This section details the rules for recognizing tokens from an input
> > > >stream.
> > > > 
> > > > Generally, language definitions intersperse the narrative text with
> > > > the relevant grammar definitions.  Yang's statement grammar is simple
> > > > enough that one doesn't need to see the context-free part of the
> > > > grammar to understand the narrative for statements.  But when reading
> > > > about tokenization, not having the grammar presented at the same time
> > > > is quite a burden.  I'd recommend duplicating the relevant productions
> > > > from section 14 into the subsections of section 6.
> > > > 
> > > > There is some sort of exposition problem.  The result of
> > > > "tokenization" is that the sequence of characters of the source is
> > > > converted into a sequence of "tokens".  Then some subset of the tokens
> > > > is discarded as being non-significant (e.g., whitespace and comments),
> > > > and the remainder is parsed with a context-free grammar.  Here I can't
> > > > figure out what the set of tokens is.  Looking at the grammar in
> > > > section 14, it seems to be a context-free grammar on characters.  But
> > > > that implies that there is no separate tokenization phase.
> > > > 
> > > > An example that shows the problems:
> > > > 
> > > >mod:ext
> > > > 
> > > > Is this one token, which is also an extension keyword, or is it a
> > > > sequence of three tokens?
> > > 
> > > The text says:
> > > 
> > >   A token in YANG is either a keyword, a string, a semicolon (";"), or
> > >   braces ("{" or "}").
> > > 
> > > and:
> > > 
> > >   A keyword is [...] or a prefix identifier, followed by a colon
> > >   (":"), followed by a language extension keyword.
> > > 
> > > So "mod:ext" is one token.
> > 
> > Certainly it can be one token.  My question is how do verify that it is
> > not a string?  I think that may be the origin of my confusion here is
> > that I haven't spotted a clear syntax for unquoted string.  In most
> > programming languages, mod:ext would be parsed as an identifier, a
> > colon, and an identifier.  In YANG, identifiers are usually tokenized as
> > strings, so I ask whether YANG tokenizes it as a string, a colon, and a
> > string.
> > 
> > Looking at the beginning of 6.1.3, it doesn't appear that an unquoted
> > string is forbidden from containing a colon.
> > 
> > I think that the underlying problem is that I'm not clear on what gets
> > tokenized as an unquoted string.
> 
> Note that this is legal YANG:
> 
>leaf type {
>  type string;
>}

So keywords aren't reserved; they can also be used as identifiers.

> I think there are two ways to look at this.  Either we describe the
> tokenizer as being context-dependent, or we describe the "argument" in
> a "statement" to be a "string or keyword".
> 
> In the latter case maybe we can do:
> 
> OLD:
> 
>   If a string contains any space, tab, or newline characters, a single
>   or double quote character, a semicolon (";"), braces ("{" or "}"),
>   or comment sequences ("//", "/*", or "*/"), then it MUST be enclosed
>   within double or single quotes.
> 
> NEW:
> 
>   An unquoted string is any sequence of characters that does not start
>   with a double or single quote character, is not a keyword, and does
>   not contain any space, tab, or newline characters, a single or
>   double quote character, a semicolon (";"), braces ("{" or "}"), or
>   comment sequences ("//", "/*", or "*/").

That's a lot clearer.  Though you can shorten it to:

   An unquoted string is any sequence of characters that is not a
   keyword, and does not contain any space, tab, or newline
   characters, a single or double quote character, a semicolon (";"),
   braces ("{" or "}"), or comment sequences ("//", "/*", or "*/").

> In section 6.3 we must also do:
> 
> OLD:
> 
>The argument is a string, as defined in Section 6.1.2.
> 
> NEW:
> 
>The argument is a string or a keyword, as defined in Section 6.1.2.

If I understand correctly, the tokens of Yang (as the term is usually
used in programming languages) are:

whitespace (which is ignored)
comments (which is ignored)
single-quoted strings
double-quoted strings
unquoted strings (including keywords)
;
{
}

>From the point of view of the tokenizer, these tokens fall into the
obvious classes:

typeunquoted string
"type"  double-quoted string
abc unquoted-string
"abc"   double-quoted string
'---'   single-quoted string

I'm not quite sure how they are classified from the parser's point of
view, though.

type"type"  abc "abc"   '---'

Is a string??   Y   ?   Y   Y
(Can it appear as the
argument of "description"?)

Is a keyword?   Y   ?   N   N   N
(Can it appear as the first
token of some statement?)

Is an ide

Re: [netmod] [Gen-art] Gen-ART IETF Last Call review of draft-ietf-netmod-rfc6020bis-12 (part 1)

[Dale R. Worley]

(This is the first part of my response, which I am sending seperately to
speed things up.)

Martin Bjorklund  wrote:
> wor...@ariadne.com (Dale R. Worley) wrote:
> > Martin Bjorklund  wrote on Mon, 23 May 2016 15:43:09 +0200 
> > (CEST):
> > > wor...@ariadne.com (Dale R. Worley) wrote:
> > 
> > Almost all of these points I'm happy with the authors fixing in the
> > manner they suggest.  The points where I have further comment are:
> > 
> > > > The incompatibilities should be marked whether the old, incompatible
> > > > usage always causes an error "at compile time", "at run time", or
> > > > changed behavior.
> > > 
> > > Ok, but I'd like to avoid the term "compile-time" here.
> > 
> > True...  The distinction I'm looking for is "Incompatible usage will
> > cause an error report before the software is put into operation."
> > vs. "Incompatible usage will cause an error report when the software is
> > in operation." vs. "Incompatible usage will cause a difference in
> > behavior without an error report."
> 
> The spec defines what is legal YANG.  How this is enforced by tools
> must be up to the tools, right?

It depends.  When reading about incompatibilities, it's really nice to
be informed what will happen.  E.g., if the compiler will catch it,
you just recompile the code and watch for error messages.  If it will
cause incompatible run-time behavior, you have to inspect the code,
which is a lot of work.

> > > How about:
> > > 
> > >The following changes are not backwards compatible with YANG version
> > >1:
> > > 
> > >o  Changed the rules for the interpretation of escaped characters in
> > >   double quoted strings.  This is an backwards incompatible change
> > >   from YANG version 1.  A module that uses a character sequence that
> > >   is now illegal must change the string to match the new rules.  See
> > >   Section 6.1.3 for details.
> > > 
> > >o  An unquoted string cannot contain any single or double quote
> > >   characters.  This is an backwards incompatible change from YANG
> > >   version 1.  A module that uses such quote characters must change
> > >   the string to match the new rules.  See Section 6.1.3 for details.
> > 
> > I assume that the first two situations will cause an error report before
> > the module is put into production.
> > 
> > >o  Made noncharacters illegal in the built-in type "string".  This
> > >   change affects the run-time behavior of YANG-based protocols.
> > 
> > What happens if you attempt to use a noncharacter in a string?
> 
> This depends on the protocol.  noncharacters are illegal.  Maybe in
> protocol A you can't even encode noncharacters, but in protocol B
> you'll get a protocol error from the other side if you send
> noncharacters.

Really, the question is "What does 'illegal' mean?"  Of course, it
means that you shouldn't do it, but does it also contain assertions
that some particular stage of processing will explicitly flag it?

> > It might be worth inserting a definition of "node" as shorthand for
> > "data node", as there seems to be no definition of "node" alone, but it
> > is commonly used to mean "data node".  In particular, the reader needs
> > to be fully aware that "node" is a node in the schema tree, not an
> > instantiation thereof.
> 
> But saying that "node" means "data node" is not correct.  Sometimes
> the text talk about "schema nodes" etc.  I think it is better to
> qualify the usage of "node" where necessary to avoid the ambiguity.

OK, I see.  But since I was getting confused, it suggests that there
are various places where "node" is used where it wasn't clear from
context whether it was a data node or a schema node.

> > > > It would be useful to insert a note somewhere that all data is either
> > > > "configuration" or "state" data.  It's hard to learn that now, because
> > > > the terms "configuration data" and "state data" are defined only by
> > > > reference to RFC 6241.
> > > 
> > > But this is not strictly correct.  For example RPC input is neither
> > > config nor state.  Section 3 has:
> > > 
> > >   o data tree: An instantiated tree of any data modeled with YANG,
> > > e.g., configuration data, state data, combi

Re: [netmod] leafref value space and constraint

[Dale R. Worley]

A difficulty I have with the current wording is that it doesn't point
out the crucial fact about leafref that the XPath expression can only
select elements that are instantiations of one particular data node.  I
don't know XPath, but it seems that that is not a general property of
XPath expressions, you seem to be able to write XPath expressions that
select heterogenous groups of elements.  So it's worth pointing out that
the allowed XPath expressions can't do that, and that is because of the
restriction that the expression must match path-arg.

Perhaps my problem is that XPath is almost always used in this style,
and so the limitations in leafref aren't anything unusual.

Dale

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] leafref value space and constraint

[Dale R. Worley]

Martin Bjorklund  wrote:
> Also, the text needs to mention leaf-lists.  This gives:
> 
>   The leafref type is restricted to the value space of some leaf or
>   leaf-list node in the schema tree and optionally further restricted
>   by corresponding instance nodes in the data tree.  The "path"
>   substatement (Section 9.9.2) is used to identify the referred leaf
>   or leaf-list node in the schema tree. The value space of the
>   referring node is the value space of the referred node.
> 
>   If the "require-instance" property is "true", there MUST exist an
>   node in the data tree, or a node with a default value in use (see
>   Section 7.6.1 and Section 7.7.2), of the referred schema tree leaf
>   or leaf-list node with the same value as the leafref value in a
>   valid data tree.
> 
>   If the referring node represents configuration data, and the
>   "require-instance" property (Section 9.9.3) is "true", the referred
>   node MUST also represent configuration.

How about:

The leafref type contains an XPath expression in the "path"
substatement.  Due to the restrictions on the expression, all
instances in the result set of the expression evaluated on all
possible data tree are instances of one single data node, called the
"referred node".

The leafref type has the value space of the type of the referred
node.
  
If the "require-instance" property is "true", the leafref type also
imposes a constraint on any node of its type:  the value must be the
same as that of some instance in the data tree, or an instance with
a default value in use, selected by the XPath expression.  Such a
constraint is enforced according to the rules in Section 8.

If the referring node represents configuration data, and the
"require-instance" property (Section 9.9.3) is "true", the referred
node MUST also represent configuration.

I started with a discussion of the XPath expression to state explicitly
that all selected instances must be instances of one data node, and used
that to define "referred node".  With that clarified, it's easier to
state the conditions that we care about.

I want to clearly separate the question of value space (which is
enforced roughly any time XML using the module is parsed) from the
constraint (which is enforced only at the times specified in section 8).

I do exploit the convention that default values cause instance nodes to
exist in the data tree in a sort of virtual sense, in that the XPath
expression can return them in its data set.  But I think that is
consistent with the philosophy of Yang.  Does that need to be stated
more explicitly?



Also, in the lexicon:

   o  anydata: A data node that can contain an unknown set of nodes that
  can be modelled by YANG, except anyxml.

   o  anyxml: A data node that can contain an unknown chunk of XML data.

Both definitions should start with "a data node *whose instances* can
contain..."

Dale

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Fwd: if-feature in default value

[Dale R. Worley]

Martin Bjorklund  wrote:
> mbj> OLD:
> mbj>
> mbj>   The definition of the default value MUST NOT be marked with an
> mbj>   "if-feature" statement.
> mbj>
> mbj> NEW:
> mbj>
> mbj>   If the definition of the default value is conditional based
> mbj>   on one or more features (see ^if-feature^), then the leaf
> mbj>   node MUST also be conditional based on at least the same
> mbj>   set of features.
> mbj>
> mbj> (modelled after the text in 9.9)
>
> Does anyone have comments on this proposal?

> I was careful to use the same wording as is used in section 9.9 on
> leafrefs:
> 
>If the leaf that the leafref refers to is conditional based on one or
>more features (see Section 7.20.2), then the leaf with the leafref
>type MUST also be conditional based on at least the same set of
>features.
> 
> So we already have the complexity.

That sounds good to me.  As y'all say, it's complex to check, but it's
the same check being done for leafrefs, so there's no additional
conceptual complexity.

Dale

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Gen-ART IETF Last Call review of draft-ietf-netmod-rfc6020bis-12

[Dale R. Worley]

Martin Bjorklund  wrote on Mon, 23 May 2016 15:43:09 +0200 
(CEST):
> wor...@ariadne.com (Dale R. Worley) wrote:

Almost all of these points I'm happy with the authors fixing in the
manner they suggest.  The points where I have further comment are:

> > The incompatibilities should be marked whether the old, incompatible
> > usage always causes an error "at compile time", "at run time", or
> > changed behavior.
> 
> Ok, but I'd like to avoid the term "compile-time" here.

True...  The distinction I'm looking for is "Incompatible usage will
cause an error report before the software is put into operation."
vs. "Incompatible usage will cause an error report when the software is
in operation." vs. "Incompatible usage will cause a difference in
behavior without an error report."

> How about:
> 
>The following changes are not backwards compatible with YANG version
>1:
> 
>o  Changed the rules for the interpretation of escaped characters in
>   double quoted strings.  This is an backwards incompatible change
>   from YANG version 1.  A module that uses a character sequence that
>   is now illegal must change the string to match the new rules.  See
>   Section 6.1.3 for details.
> 
>o  An unquoted string cannot contain any single or double quote
>   characters.  This is an backwards incompatible change from YANG
>   version 1.  A module that uses such quote characters must change
>   the string to match the new rules.  See Section 6.1.3 for details.

I assume that the first two situations will cause an error report before
the module is put into production.

>o  Made noncharacters illegal in the built-in type "string".  This
>   change affects the run-time behavior of YANG-based protocols.

What happens if you attempt to use a noncharacter in a string?

> >o  leaf: A data node that exists in at most one instance in the data
> >   tree.  A leaf has a value but no child nodes.
> > 
> > I'm not sure that this is correct; a leaf schema node inside a list
> > schema node can have many instances in a data tree.  The real
> > criterion is that it has a value but no child nodes.
> 
> Would "one instance per parent node" work?

I think that's correct.  The case I would expect to be tricky is be a
leaf contained in a list, but the XML for lists wraps an element around
each list member, so each leaf has "one instance per parent node".

It might be worth inserting a definition of "node" as shorthand for
"data node", as there seems to be no definition of "node" alone, but it
is commonly used to mean "data node".  In particular, the reader needs
to be fully aware that "node" is a node in the schema tree, not an
instantiation thereof.

> > It would be useful to insert a note somewhere that all data is either
> > "configuration" or "state" data.  It's hard to learn that now, because
> > the terms "configuration data" and "state data" are defined only by
> > reference to RFC 6241.
> 
> But this is not strictly correct.  For example RPC input is neither
> config nor state.  Section 3 has:
> 
>   o data tree: An instantiated tree of any data modeled with YANG,
> e.g., configuration data, state data, combined configuration and
> state data, RPC or action input, RPC or action output, or
> notification.

Section 4.1 contains a similar statement.

I think the problem I'm having is with the first sentences of 4.2.3:

   YANG can model state data, as well as configuration data, based on
   the "config" statement.

At first read, this suggests that data is partitioned into
"configuration data" and "state data".  What's really happening is that
there are various sorts of data, but some contexts admit a mixture of
configuration and state data, so the data model definitions of those
contexts requires that individual data items can be flagged as
configuration vs. data.  Maybe starting 4.2.3 like this would work:

   In some contexts, data modeled by YANG can contain mixtures of state
   data and configuration data, based on the "config" statement.  When a
   node is tagged with "config false", its subhierarchy is flagged as
   state data.

> > - section 3.1
> > 
> > There is an overall question regarding whitespace in XML in
> > "non-significant" places.  Is it allowed in the XML representation of
> > data trees?  And if so, precisely what whitespace is allowed?  Also,
> > to what degree is the whitespace shown in examples what is allowed on
> > the wire, and to what degree is it there ju

Re: [netmod] Gen-ART IETF Last Call review of draft-ietf-netmod-rfc6020bis-12

[Dale R. Worley]

(I've not received some of the discussion e-mails, so I am just now
responding.)

Ladislav Lhotka  writes:
> This follows from the fact that YANG doesn't support mixed content:
> there is no way how this whitespace can be made significant.

It seems to me that this is the restriction that should be stated:  "In
NETCONF XML, non-whitespace character content is only allowed as content
of elements that provide values.  Non-whitespace character content in
other locations is ignored."  (Maybe XML defines a better way to say
this.)

Of course, this is a general statement about the XML encoding, not about
any specific Yang element.

> What about comments and processing instructions?

My understanding is that comments are always allowed, because they're
understood to be deleted by the XML parsing process.  Processing
instructions seem to be defined to be significant.  I would assume that
by default no processing instructions are allowed unless Netconf defines
one.

Dale

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Gen-ART IETF Last Call review of draft-ietf-netmod-rfc6020bis-12

[Dale R. Worley]

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-netmod-rfc6020bis-12
Reviewer: Dale R. Worley
Review Date: 2016-05-12
IETF LC End Date: 2016-05-12
IESG Telechat date: 2016-05-19

Summary: This draft is basically ready for publication, but has nits
that should be fixed before publication.  I have a large number of
editorial comments.  A few of these comments address technical
uncertainties, but I strongly suspect that the technical issues have
long since been fixed, as this is a revision of Yang 1, and the
only needed work is clarifying the text.

- Abstract

This Abstract does not list what the document does.  E.g., define Yang
1.1.  Also might help to mention upward-incompatibility.  Basically,
go through section 1 to see what should be in Abstract.  Perhaps:

   YANG is a data modeling language originally designed to model
   configuration and state data manipulated by the Network
   Configuration Protocol (NETCONF), NETCONF remote procedure calls,
   and NETCONF notifications.  This document describes the syntax and
   semantics of version 1.1 of the YANG language.  YANG version 1.1 is
   a maintenance release of the YANG language, addressing ambiguities
   and defects in the original specification.  There are a small
   number of upward-incompatibilities from Yang 1.  This document also
   describes how a data model defined in a YANG module is encoded in
   the Extensible Markup Language (XML), and how NETCONF operations
   are used to manipulate the data.

- section 1.1

The incompatibilities should be marked whether the old, incompatible
usage always causes an error "at compile time", "at run time", or
changed behavior.

A number of later items seem to be upward-incompatibilities but not
marked as such:

   o  Made the "yang-version" statement mandatory.

   o  Made noncharacters illegal in the built-in type "string".

- section 3

   o  identifier: Used to identify different kinds of YANG items by
  name.

This item, unlike the others, does not start with a noun phrase.
Perhaps, "A string used to ..."?

   o  leaf: A data node that exists in at most one instance in the data
  tree.  A leaf has a value but no child nodes.

I'm not sure that this is correct; a leaf schema node inside a list
schema node can have many instances in a data tree.  The real
criterion is that it has a value but no child nodes.

   o  leaf-list: Like the leaf node but defines a set of uniquely
  identifiable nodes rather than a single node.  Each node has a
  value but no child nodes.

Better to say a "sequence of nodes".  Without the concept that the
nodes are a sequence (and can be identified by location within the
sequence), there's no assurance that the nodes are uniquely
identifiable (since they can have duplicate values in state data).

   o  mandatory node: A mandatory node is one of:
  ...
  *  A container node without a "presence" statement, which has at
 least one mandatory node as a child.

Perhaps replace the comma with "and"?

It would be useful to insert a note somewhere that all data is either
"configuration" or "state" data.  It's hard to learn that now, because
the terms "configuration data" and "state data" are defined only by
reference to RFC 6241.

There are general issues with the terms "namespace" and "prefix".

"namespace" is used to identify both the namespaces of identifiers in
Yang source (6.2.1) as well as XML namespaces in the XML encodings of
data trees.  It would make things clearer if all uses that refer to
XML namespaces used the form "XML namespace".

"prefix" is used to name both identifier prefixes in Yang source code
and XMLNS prefixes.  Worse, the prefix statement is used to declare
one string, which is then both the prefix used within the Yang source
code and also the preferred (but not mandatory!) XMLNS prefix used to
refer to the associated XML namespace.  It would help if "XMLNS
prefix" was used whenever talking specifically about prefixes used in
XML.  See also comments on section 7.1.4.

- section 3.1

There is an overall question regarding whitespace in XML in
"non-significant" places.  Is it allowed in the XML representation of
data trees?  And if so, precisely what whitespace is allowed?  Also,
to what degree is the whitespace shown in examples what is allowed on
the wire, and to what degree is it there just to make the example
easier to read?  (It's possible that XML has implemented some sort of
global solution for the issue of n