Comparing inet data types

YANG
1

Is there any builtin to compare inet types (thought it is a derived string)

2

In what context are you looking for a way to compare them? For most “well-known” types, ConfD will parse the string form, and use the parsed value for its internal representation as well as in the “language APIs” - see the confd_types(3) manual page.

3

Basically i am looking something like <, > or equal kind checks

4

OK, but I asked for the context where you wanted to do the comparison. I’ll take a guess that you want to do it in your application code, in which case I will again point you to the confd_types(3) manual page, where the representation of “well-known” types (YANG built-in, ietf-yang-types and ietf-inet-types, as well as tailf-specific ones) is described when it differs from the “string with pattern restriction” that the YANG modules typically specify.

As for doing the comparison, the C API provides the confd_val_eq() function, described in the confd_lib_lib(3) manual page. < / > comparisons are not generally meaningful - e.g. for inet:ipv4-address, represented as a confd_value_t with type C_IPV4 and the standard struct in_addr for the value. But you can of course extract the values with the CONFD_GET_IPV4() macro and compare them as you see fit, within the bounds of the C language.

5

Ya. I am aware of doing validation in the application code. Was thinking if something supported where i can use the comparison in the data-model itself than going to the application code for doing validation.

Like the example validate (mtest a_val and b_val). This can be compared using the must and checks done in data-model itself than triggering a validation in application code.

6

Finally! In the future, please try to provide some detail up-front with your questions, so we don’t waste time discussing things that you are specifically not interested in.

Yes indeed, using ‘must’ expressions in the data model is basically always preferable to writing code in validation callbacks. The argument to ‘must’ is a standard XPath expression, as specified in XML Path Language (XPath) Version 1.0, and described and discussed in many other documents and even books.

XPath has all the “normal” comparison operators - =, !=, <=, <, >=, and > - but (simplified but basically true) only = and != can be used with operands that aren’t “numbers”. Thus the “more_a_than_b” constraint in the validate/c example can trivially (and much better than code) be expressed with ‘must’, e.g. as

container mtest {
  must "a_number > b_number" {
    error-message "a_number is <= b_number";
  }
  ...

The validate/xpath_must example has some more “exotic” examples of ‘must’ expressions, as well as debugging tips. I still don’t know what you want to do with the “inet data types” (and which of them), but the YANG modules have everything you need for writing ‘must’ expressions - ConfD’s internal representation is irrelevant. Unless you want it to be relevant - see the description of the compare() function in the XPATH FUNCTIONS section of the tailf_yang_extensions(5) manual page.

7

I’ll join in because it’s a question I wanted to ask myself.
Let’s say I have two leaves x and y, both of which are IPv4 addresses (using the corresponding inet type).

Let’s say and x and y are the min and max of a range of IP addresses, for example x=192.168.30.1 and y=192.168.30.254

From the discussion above it seems to me that there is no way to directly compare x and y (for instance x <= y) in a must expression in a yang file. I’m bound to do this by calling an external validation code (I would code it in python, for instance).

Is that correct?

1 Like
8

“no way to directly compare x and y (for instance x <= y)” is correct, but “bound to do this by calling an external validation code” is not. Directly compare using = or != should work (but is not what you need), and compare using the compare() function I pointed to should work “indirectly” for all the operators. E.g. (untested) ‘must “compare(x, y) = -1”’.

1 Like
9

This the way i am doing it currently. Thanks for all the comments.