Per Hedeland píše v St 23. 08. 2017 v 22:03 +0200: > On 2017-08-23 20:09, Vladimir Vassilev wrote: > > 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. > > If I may offer a more "philosophical" view: in my mind, a YANG module is > not an instruction for a server (or client) implementation as to what > validation to perform (and I say that with the bias of working for a > company that uses YANG modules precisely for that, and with the specific > components that translate them into such instructions) - it is a > specification of the data model. If the pattern statement allows values > that are actually invalid, the specification is incorrect. > > I.e. I'm with your original comment - if you can't get it right, leave > it out. "Under-specification" will always exist, and is acceptable in my > opinion. Specification that gives the appearance of being complete > (admittedly this is also subjective), but actually isn't, is not (in my > opinion).
I completely agree. Lada > > --Per > > > 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
