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
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
