On Dec 9, 2014, at 9:31 AM, t.p. <daedulus@xxxxxxxxxxxxx> 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.