Per Hedeland <[email protected]> writes: > 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
Yes, you are right, mea culpa. > 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. Yes, and it is IMO how it should be. As Martin pointed out, complicated lexical representations are difficult to deal with, e.g. in XPath expressions. > > 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. I doubt this is a real problem - a netconf/restconf server backend can easily translate the two separate leaves into a single string if necessary. Backends on other devices may well need to use the IP address and mask separately. Lada > > 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 -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
