ietf
[Top] [All Lists]

Re: Blog: YANG Really Takes Off in the Industry

2014-12-09 08:55:39
On Dec 9, 2014, at 9:31 AM, t.p. <daedulus(_at_)btconnect(_dot_)com> wrote:
The expression that controls the permissible format of IPv6 addresses in
yang-types is of this ilk.
"       type string {
        pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}'
              + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|'
              + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}'
              + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))'
              + '(/(([0-9])|([0-9]{2})|(1[0-1][0-9])|(12[0-8])))';
        pattern '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|'
              + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)'
              + '(/.+)'; "
which was got wrong several times before it became what it is now (which
rings alarm bells for me).

Wow, so there's no way to do this ABNF-style?

netmod-routing-cfg-02 on the netmod WG list 29feb2012 tripped over that
fact that a unique-stmt for container/list/leaf is not allowed in trying
to make a name unique (because there is a 'list' in there) which led to
a debate as to what YANG(RFC6020) was actually trying to say on this
topic with the conclusion that the RFC is ambiguous.

By the time this I-D  was up to netmod-routing-cfg-08 13feb2013 Martin
suggested
"> I think the majestic must expression for the connected-routing-table
might be wrong.  The problem is that it checks that:
  not (*some* preceding-sibling has same afi
       AND
       *some* preceding-sibling has same safi)  "
so it was revised from
"                  must "not(/routing/routing-tables/"
                   + "routing-table[name=current()/"
                   + "preceding-sibling::connected-routing-table/"
                   + "name]/address-family=/routing/routing-tables/"
                   + "routing-table[name=current()/name]/"
                   + "address-family and /routing/routing-tables/"
                   + "routing-table[name=current()/"
                   + "preceding-sibling::connected-routing-table/"
                   + "name]/safi=/routing/routing-tables/"
                   + "routing-table[name=current()/name]/safi)" {
                  error-message "Duplicate address family for "
                              + "connected routing tables.";   "
to
"    must "not(/routing/routing-tables/"
      + "routing-table[name=current()/"
      + "preceding-sibling::connected-routing-table/"
      + "name and address-family=/routing/routing-tables/"
      + "routing-table[name=current()/name]/"
      + "address-family and safi=/routing/routing-tables/"
      + "routing-table[name=current()/name]/safi])" {
     error-message "Duplicate address family for "
                 + "connected routing tables.";    "

draft-ietf-netmod-snmp-cfg-00 started out with
"     when "../type = trap or ../type = inform";  "
which looks ok, but isn't, generating the error message
"Warning: no child nodes found in XPath expr '../type = trap or ../type
= inform'
ietf-snmp-proxy.yang:123.42: warning(432): no child node available "
because unquoted strings are node names not values.  And
"      when "snmp:params/snmp:v1 or snmp:params/snmp:v2c"; "
generates the same error message because a solidus is missing while
"         must '/snmp/usm/remote[engine-id=current()]/'
          + 'user[name=current()/../usm/user-name]' "
also generates the same error message which led to a lengthy discussion
about interactions of 'augment', 'when' and such like; the condition got
removed, but the discussions about those interactions continue still, as
in issue Y26 of the enhacements for YANG 1.1.

This certainly seems quite ugly.   If it can be fixed in an update, that's a 
positive thing.

On a slightly different tack, YANG enumerations have no mandatory value,
unlike SMI, and this has triggered a number of discussions, such as an
ambiguity when RFC6020 says
"the assigned value is one greater than the current highest enum value."
as to what the next value should be. This then has an impact on the
ordering of lists.

Can this be fixed in an update, or is there some reason why this decision was 
made?

Do I know what I am talking about?  On a good day, after I have been
browsing recent posts to the netmod WG list (all of which I read),
maybe; but after a time away from netmod, I struggle.  And the issues
that arise on the netmod WG list suggests to me that those whom I
clearly see are the experts on this topic in the IETF may, at times,
struggle too.

This is certainly something to be concerned about.   A syntax that is difficult 
to internalize without working on it full-time is not a good idea.   OTOH, it's 
hard to have a syntax that is not at least _somewhat_ difficult to internalize 
if you aren't working on it full time, so to some extent this is a matter of 
degree.