----- Original Message -----
From: "Ted Lemon" <Ted.Lemon@xxxxxxxxxxx>
To: "t.p." <daedulus@xxxxxxxxxxxxx>
Cc: "Dean Bogdanovic" <deanb@xxxxxxxxxxx>; "IETF-Discussion list"
<ietf@xxxxxxxx>
Sent: Wednesday, December 03, 2014 8:28 PM
> On Dec 3, 2014, at 5:18 AM, t.p. <daedulus@xxxxxxxxxxxxx> wrote:
> > The YANG models of the IETF seem to be diving into complex code from
> > which it is hard to discern what the purpose is, and the fact that
most
> > of the exemplars are written by those highly expert in YANG, and so
use
> > the wide range of constructs available, does not help.
>
> Can you give an example of the problem you are talking about here?
Ted,
Apologies for the delay.
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).
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.
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.
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.
Tom Petch
>
>