On 2019-04-02 20:48, Juergen Schoenwaelder wrote:
On Tue, Apr 02, 2019 at 08:27:32PM +0200, Martin Bjorklund wrote:
I
think that I also now agree with Martin that this is really merging
two values into one leaf.
And for the record (again, perhaps), I think this is a bad idea in
general, and I am not sure an exception is needed in this case.
This format is used and convenient where it is used (and I do
sometimes miss it at other places where it is not used). I would not
be religious about this combination of values. Note that even
ip-prefix is a combination of a prefix length and an address
'pattern'. So ip-address-and-prefix is actually three values in
one. ;-)
I agree that it's useful and please avoid religious. Though I think
ip-address-and-prefix-length is still two values at max. ip-prefix is
two values in the common storage form since we typically use a fixed
length 32 bit integer for storing an IP address and then need a second
field to tell us how many bits are significant for the prefix. A more
natural way of storing it could have used a variable length field in
which case a /8 network really would only be 8 bit long (but then again,
variable length field typically are stored as TLV or LV, so two values
again... but way below our abstraction level now).
We have yang:date-and-time, a combination of date and time (we are
adding these right now). yang:date-and-time actually clumps together
year, month, day, hours, minutes, seconds, optional subseconds,
timezone. For me, it seems useful to adopt commonly used formats.
This rings very true to me. Even if the IETF interfaces-ip model doesn't
use these types, they are being used by Cisco, Juniper etc in their
proprietary models, it's just that the type is currently string or
something like that - if they could use a common IETF data type then it
would be easier to cast this to a proper data type in a programming
language, so like when you parse the config you'd get a Python
ipaddress.IPv4Network object out of this or similar.
kll
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
