Re: [netmod] Pattern statements [was Re: Query about augmenting module from submodule in YANG 1.0]

[Vladimir Vassilev <[e-mail]>]

On 08/23/2017 03:36 PM, Juergen Schoenwaelder wrote:

> On Wed, Aug 23, 2017 at 02:23:12PM +0100, Robert Wilton wrote:
>> 1) Email address.  I understand that the full regex to validate all email
>> addresses is very complex, but checking that it at least contains an @
>> symbol still has benefit.  It would seem that a short imperfect regex is
>> better than a complete perfect regex.
> What is your definition of 'better'? A stricter pattern catches more
> errors. An imperfect pattern is better than none.
In the case of e-mail address string pattern complying without 
exceptions to rfc5322#section-3.4 specification a ~500 characters of 
pattern expression is needed. There is value in defining data types that 
can be automatically verified by YANG. IMO in this case a strict pattern 
is justified.
>> 2) A list of VLAN ranges, e.g. want to allow strings that look like this:
>> "1-10,20-400,600,2000-3000", but only with non overlapping values in
>> ascending order.  It is easy to write a regex to check that the structure is
>> right, but AFAIK it is hard (impossible?) to write a regex that ensures that
>> the ranges don't overlap and are specified in ascending order.
> So what. Does this provide a helpful argument whether patterns should
> be strict or imperfect?
IMO loading strings with semantics instead of using YANG is example of 
bad model design. There is no RFC (like in the e-mail example) that 
mandates use of string with complex format instead of YANG to model 
range configuration. Complex strings can and should be avoided in cases 
like this one.
>> So, I propose that we use regexes for checking that the string is
>> structurally correct, but don't use regexes to perform numerical range
>> checks of string encoded numbers, since it makes the regexes hard to
>> read/verify, and doesn't improve the readability of the YANG file either.
> So here is the point I think:
> c.
>     It is desirable that regexes are as strict as they can be.
>     However, if regexes become so complicated that they become a
>     verification and maintenance problem by themself, then less strict
>     regexes may be a better choice.
I agree. But it is the enthropy of having configuration that can not be 
strictly validated by model aware automation tools that has been the 
reason for introduction of leafref, must, when, range, pattern etc. So 
giving up the goal of handling validation in automated model driven way 
to the advantage of readability is a tough compromise.

I agree with Rob that the pattern in draft-ietf-rtgwg-routing-types-09 
is complicated to read. I have the feeling the design can be improved 
without compromising the strictnes of the data type. Redefinig the 
typedef as a union of 5 string based types with seperate strict patterns 
is one suggestion for moving logic from the string type to YANG.

Vladimir
> /js
>