Hi Juergen,
> -----Original Message-----
> From: Schönwälder, Jürgen <j.schoenwael...@jacobs-university.de>
> Sent: 18 February 2020 11:20
> To: Rob Wilton (rwilton) <rwil...@cisco.com>
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Alexey Melnikov's Discuss on draft-ietf-netmod-
> module-tags-07: (with DISCUSS)
>
> On Tue, Feb 18, 2020 at 11:12:47AM +0000, Rob Wilton (rwilton) wrote:
> >
> > I'm also not convinced of how many implementations would properly honour
> the XML regex property categories, e.g., if the pattern statement has been
> translated to another regex engine.
> >
>
> That's a weird argument. If there is agreement on a restriction and we can
> express that restriction in a pattern, we should IMHO do so.
Not really.
I believe that ultimately the configuration is the responsibility of the
client. If there are reasonable steps that a server can take to help police
that configuration and reject obvious errors then that is obviously helpful,
but it most cases a server cannot check that the value provided by the client
is correct, which I suspect is the far more likely error (e.g. a client
configures the wrong IP address rather than a malformed IP address).
So, in the case of regexes, I still prefer a shorter, easier to
read/understand, and likely more performant pattern statement instead of a
longer, complex, and harder to verify pattern statement.
In particular, I note that unicode properties do not seem to be widely used in
YANG pattern statements (e.g. perhaps only 10 unique pattern instances in all
YANG modules on github YANG repo, some of which look plausibly wrong to me
(unless they intended to include ASCII control characters), and hence I
question whether it is worth using them, but maybe I am being biased towards
languages using the Latin alphabet.
Further, I was concerned that there didn't seem to be widespread support for
unicode properties within standard regex engines, but it looks like this may
have changed, and perhaps support for them is more widespread now, even if the
exact specification of what character properties are defined and what
characters are included in those properties seem to able to vary over time
depending on the unicode version, and presumably between implementations.
In the case of module tags, I'm not sure what would go wrong if a space was
included in the tag name. I suspect nothing, just that it could be confusing
to a user when displayed.
So, I'm still think that pragmatically the existing regex is fine. But if the
consensus is to use \P{Z} or better \P{Separator} then I would also be okay
with that.
>
> Note the order: It is backwards if there is first a pattern and as a
> consequence we agree on that specific restriction.
>
> Ideally, the agreed upon restriction is stated in the description and if
> possible also expressed as a pattern. This way it does not matter how
> implementations enforce the restriction and it is clear to everyone what
> the pattern is trying to achieve.
Yes. I agree to both these points.
Thanks,
Rob
>
> /js
>
> --
> Juergen Schoenwaelder Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
