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

[Ladislav Lhotka <[e-mail]>]

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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67