Re: Blog: YANG Really Takes Off in the Industry

[Ted Lemon <[e-mail]>]

On Dec 9, 2014, at 9:31 AM, t.p. <[e-mail]> 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.