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

[Robert Wilton <[e-mail]>]

On 23/08/2017 12:52, Vladimir Vassilev wrote:
> On 08/21/2017 05:14 PM, Robert Wilton wrote:
>
>> Hi Acee,
>>
>> That makes sense.
>>
>> The other thing that I think that we have got wrong is modelling 
>> regex pattern statements.  I think that it would be much better if 
>> these were written to be less exhaustive and much simpler.
>>
>> E.g. the "route distinguisher" pattern in 
>> draft-ietf-rtgwg-routing-types-09 is defined as this:
>>
>>           pattern
>>             '(0:(6553[0-5]|655[0-2][0-9]|65[0-4][0-9]{2}|'
>>           +     '6[0-4][0-9]{3}|'
>>           +     '[0-5]?[0-9]{0,3}[0-9]):(429496729[0-5]|'
>>           +     '42949672[0-8][0-9]|'
>>           +     '4294967[01][0-9]{2}|429496[0-6][0-9]{3}|'
>>           +     '42949[0-5][0-9]{4}|'
>>           +     '4294[0-8][0-9]{5}|429[0-3][0-9]{6}|'
>>           +     '42[0-8][0-9]{7}|4[01][0-9]{8}|'
>>           +     '[0-3]?[0-9]{0,8}[0-9]))|'
>>           + '(1:((([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|'
>>           +     '25[0-5])\.){3}([0-9]|[1-9][0-9]|'
>>           +     '1[0-9]{2}|2[0-4][0-9]|25[0-5])):(6553[0-5]|'
>>           +     '655[0-2][0-9]|'
>>           +     '65[0-4][0-9]{2}|6[0-4][0-9]{3}|'
>>           +     '[0-5]?[0-9]{0,3}[0-9]))|'
>>           + '(2:(429496729[0-5]|42949672[0-8][0-9]|'
>>           +     '4294967[01][0-9]{2}|'
>>           +     '429496[0-6][0-9]{3}|42949[0-5][0-9]{4}|'
>>           +     '4294[0-8][0-9]{5}|'
>>           + '429[0-3][0-9]{6}|42[0-8][0-9]{7}|4[01][0-9]{8}|'
>>           +     '[0-3]?[0-9]{0,8}[0-9]):'
>>           +     '(6553[0-5]|655[0-2][0-9]|65[0-4][0-9]{2}|'
>>           +     '6[0-4][0-9]{3}|'
>>           +     '[0-5]?[0-9]{0,3}[0-9]))|'
>>           + '(6(:[a-fA-F0-9]{2}){6})|'
>>           + '(([3-57-9a-fA-F]|[1-9a-fA-F][0-9a-fA-F]{1,3}):'
>>           +     '[0-9a-fA-F]{1,12})';
>>         }
>>
>> But I think that it would be much easier to read, and quite possibly 
>> more performant to execute, if the pattern regex was written 
>> something like the following:
>>
>>  pattern:
>>     '(0:[0-9]{1,5}:[0-9]{1,10})|
>>      (1:([0-9]{1,3}\.){4}:[0-9]{1,5})|
>>      (2:[0-9]{1,10}:0:[0-9]{1,5})|
>>      (6(:[a-fA-F0-9]{2}){6})';
>>
>> Of course, this would allow more invalid values, but most servers 
>> would be expected to reject those when it converts them into an 
>> internal binary format any way.
>>
>> What do you, and others, think?
> You still need the 
> |(([3-57-9a-fA-F]|[1-9a-fA-F][0-9a-fA-F]{1,3}):[0-9a-fA-F]{1,12}) in 
> the end to not reject valid values though.
Sure, OK.

>
> IMO a pattern statement has value if it absolutely defines the set of 
> valid strings.
It still has value if it also performs some simple checks and removes 
obvious mistakes.

But even if a value passes the regex filter, it still doesn't guarantee 
that is the value is correct.  Someone could put a typo in there, or 
perhaps configure a multicast IP address where only unicast addresses 
are allowed, or put the same IP address on two separate interfaces, or 
use a IP address that they don't own, etc ...

> In general I do not see the benefit of pattern statements that do not 
> reject all invalid string instances. I prefer the original pattern or 
> none at all.
OK, so some potential counter examples:
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.
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, 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.

Thanks,
Rob


>
> Vladimir
>
>> Thanks,
>> Rob
>
> .
>