On 2019-04-01 22:51, Mahesh Jethanandani wrote:
On Apr 1, 2019, at 12:37 PM, Kristian Larsson <[email protected]> wrote:
On 2019-04-01 19:29, Martin Bjorklund wrote:
Hi,
The request was for a combined type that contains both an ip address
*and* a prefix length in one value. Hence the name
"ip-address-and-prefix-length" :)
Right you are, though I'm open to other names but let's first agree on use case
/ need :)
I know that this type is convenient, esp. if you use it for manual
input, but I wonder if it really is good practice to squeeze two
values into one.
Dunno how "manual" has any bearing. This is IMHO just about natural data
modeling.
You say it's two values but when one can't be used without the other, are they
so separated? You can't configure an interface with just an address or just a
subnet mask. You need both - they belong together.
That can be modeled into the data module, I.e. that you have to specify both
the address and the prefix length.
I am aware. It wasn't for ip-prefix though, presumably because ip-prefix
is more natural and so is ip-address-and-prefix-length.
The reason Martin mentioned two values is because even if they are modeled with
a ‘/‘ character, the end system will consume them as two separate values
Not sure if you are arguing against me or just trying to explain :) I
understand full well how it can be done and I'm saying I've written
models like that. They are not elegant. Now I want the prettier way to
do it and preferably with an IETF standardised data type, which is why
I'm suggesting we add one in 6991bis. Two values or not, they belong
together and should not exist without the other. The cost of using
multiple leaves in YANG is quite high so for things that naturally
belong together I think it's perfectly fine to make a datatype that
includes the component values. We do it for ip-prefix already. In fact
you could argue that the normal ipv6-prefix is a compound type since the
zone is really a separate value from the address. Anyway, similar to how
ip-prefix makes it easier to work with things likes routes in a routing
table or how it simplifies the source and destination address matches in
the ACL RFC we worked on together, an ip-address-and-prefix-length
datatype will make other things easier which is why I'm suggesting it be
added.
kll
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
