Re: [netmod] Alexey Melnikov's Discuss on draft-ietf-netmod-module-tags-07: (with DISCUSS)

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Juergen,

> -----Original Message-----
> From: Schönwälder, Jürgen <[e-mail]>
> Sent: 18 February 2020 11:20
> To: Rob Wilton (rwilton) <[e-mail]>
> Cc: [e-mail]
> 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: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://www.jacobs-university.de/>