On 2019-04-18 10:41, Ladislav Lhotka wrote:
On Thu, 2019-04-18 at 10:09 +0200, Kristian Larsson wrote:
On 2019-04-18 09:40, Ladislav Lhotka wrote:
Juergen Schoenwaelder <[email protected]> writes:
On Wed, Apr 17, 2019 at 09:35:51PM +0200, Kristian Larsson wrote:
I wonder though, isn't ipX-address-and-prefix-length the clearer name,
or if
we do want to shorten then ipX-address-and-plen. I think Martin stated
the
case for ipX-address-and-prefix but that is IMHO not the way this is
typically perceived by people.
1.2.3.4/24
^^^^^^^----- ipv4 address
^^^-- ipv4 prefix length
now, taking the prefix-length you know that 1.2.3 is the prefix but does
that mean the above is an IPv4 address and a prefix? Or is it just that
you
can infer the prefix from the above? It's just different ways of looking
at
it. My experience tells me ipX-address-and-prefix-length is the clearer
way
of conveying what this is.
I guess this is somewhat subjective. The prefix length is the number
used to convey what the prefix is. So you are effectively defining an
address and the prefix that this address belongs to. ;-)
Strictly speaking, what is being defined by the number is a subnet mask.
Heh, amazing how something so binary can turn out to be so subjective ;)
This sort of turns into philosophical questions and I'm not sure we need
to straighten it all out. I'd still call the prefix-length the
prefix-length. It directly maps to the typical subnet mask
representation and as you say, they can be thought of as the same thing.
Does this mean you prefer ipX-address-and-subnet-mask? Because I think
No.
that when someone reads that they are going to expect a value that looks
like 1.2.3.4/255.255.255.0 rather than 1.2.3.4/24, which is why I still
think ipX-address-and-prefix-length (possibly s/prefix-length/plen/) is
the better name :)
Given that we already have ip-prefix (which does as well use a prefix
length to convey what the prefix is), it seems ip-address-and-prefix
is more consistent with the existing RFC 6991 definitions. Being
consistent with what we have was the main reason for me to prefer
ip-address-and-prefix.
I am not in favour of adding this type. Having ip-prefix next to
ip-address-and-prefix is confusing.
Confusing or not, they are NOT interchangeable and actually do different
things, which is why both are needed. There's plenty of precedence to
I actually agree with you. It is a historical accident that these two different
things got mixed up (and some vendors contributed to this). I would argue that
- IP prefix is a set of IP addresses, and as such can be thought of as a single
entity.
- IP address and subnet mask/prefix are two separate things, the latter being an
instruction for routing to *other* destination addresses.
Agreed - except the not entirely minor nit that the thing after the
"/" is not a prefix but a *prefix-length*. Another way of putting it
is that the IP address is a property of an interface, while the
prefix-length or subnet mask is a property of the network that an
interface is connected to.
So this would clearly be two separate values "bundled" into one, and
despite the similar syntax, it is radically different from the
existing ip*-prefix types, which really do represent a single value -
as Kristian pointed out earlier in the thread, the value is the
initial N bits of a set of IP addresses - i.e. a prefix, as the name
says.
Thus if these types should be added, I don't think there is any reason
to have a naming that is "consistent" with the existing ip*-prefix
types - rather the naming should highlight the difference. And since
the two values given are an IP address and a prefix-length, the
natural choice would be ip*-address-and-prefix-length.
Using ip*-address-and-prefix would be both inaccurate (neither of the
two values is a prefix, although they can of course be combined to
compute a one) and IMHO confusing due to the similarity in naming of
the existing ip*-prefix types.
If ip*-address-and-prefix-length is considered too verbose/clunky
(although I don't know why this matters for a type name), a reasonable
shorter form could IMHO be ip*-address-and-length - the prefix-length
is of course a length, but it is not a prefix. Kristian's
ip*-address-and-plen is of course even shorter, and could be
considered to have more information, but I believe we generally try to
avoid at least non-obvious abbreviations in the YANG modules.
this, like postgresql has data types (cidr and inet) that map exactly to
this behaviour, i.e. both store something that looks like an IP address
and a prefix-length but one (cidr for pg) forces bits in host portion to
be set to all 0. Python ipaddress has the same with IPv4Address and
IPv4Interface.
Moreover, the most natural use for
this type would be the address specification in the "ietf-ip" module,
but we already have two leaves there: ip and prefix-length.
Like I said in another mail, I think it is nice if these common
datatypes become used by vendors and implementors. Many use proprietary
That's fine, but we can also define a *grouping* of IP address and subnet prefix
length. And if we stick to the leaves "ip" and "prefix-length", this grouping
can be used in the next revision of RFC 7277. This would be my preferred
solution.
From a data modelling perspective, having separate leafs for separate
values should be the natural choice, and I don't think anyone is
suggesting that the "bundled" type, if added, should be used in e.g.
RFC 7277. A grouping could be nice, but it is still two separate
leafs.
This is no solution to Kristian's problem, which as far as I
understand is about having a YANG model for existing devices that
already *use* the "bundled" type, i.e. it "needs" to be a single leaf
in the YANG module.
Whether this need is enough motivation to actually add these types to
ietf-inet-types I don't really know. There is no real cost in doing it
per se, but it could have the negative consequence that it is taken as
an encouragement/"blessing" to use these types when writing new
modules that *don't* "need" to use them. Bad from a data modelling
perspectve, and bad for the operational reasons that Martin gave an
example of while I was writing this. But maybe the 'description'
statement could warn against this.
--Per
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
