Subject: [netmod] 6991bis: address-with-prefix-length

From: Kristian Larsson <[email-masked]>
Date: Mon, 1 Apr 2019 16:38:34 +0200

Hello,

seeing that 6991 is up for a refresh I wonder if this would be the time 
to suggest the addition of a type for address-and-prefix-length, for 
example like 192.0.2.1/24?

I find that it's the most natural way express the address and 
prefix-length to configure on an interface or for some other use. We 
currently have an ip-prefix type which allows CIDR style prefixes but 
since all bits to the right of the mask is to be 0 it is only possible 
to use for describing the IP prefix / network address itself - not the 
address of a host in that network.

I actually wish the interface-ip modules would have used a combined leaf 
for these settings rather than the dual-leaf approach it currently has, 
but I suppose that ship has sailed :/

Regardless, can we add such a type? Is this the document and time to do 
it? :)

Kind regard,
    Kristian.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 1 Apr 2019 18:13:21 +0200

This is the right time for this and I would call these
ip-address-prefix, ipv4-address-prefix and ipv6-address
prefix.

/js

On Mon, Apr 01, 2019 at 04:38:34PM +0200, Kristian Larsson wrote:
> Hello,
> 
> seeing that 6991 is up for a refresh I wonder if this would be the time to
> suggest the addition of a type for address-and-prefix-length, for example
> like 192.0.2.1/24?
> 
> I find that it's the most natural way express the address and prefix-length
> to configure on an interface or for some other use. We currently have an
> ip-prefix type which allows CIDR style prefixes but since all bits to the
> right of the mask is to be 0 it is only possible to use for describing the
> IP prefix / network address itself - not the address of a host in that
> network.
> 
> I actually wish the interface-ip modules would have used a combined leaf for
> these settings rather than the dual-leaf approach it currently has, but I
> suppose that ship has sailed :/
> 
> Regardless, can we add such a type? Is this the document and time to do it?
> :)
> 
> Kind regard,
>    Kristian.
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 1 Apr 2019 16:31:12 +0000

I believe the "address-" could be omitted from the type identifiers. At least within the routing area, "ipv4-prefix" is unambiguous. 
Thanks,
Acee

On 4/1/19, 12:14 PM, "netmod on behalf of Juergen Schoenwaelder" <[email-masked] on behalf of [email-masked]> wrote:

    /js

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 1 Apr 2019 17:23:37 +0000

Ok, now I'm confused. I see that the ietf-inet-type model already has the types ipv4-prefix and ipv6-prefix. How are these any different??? 
Thanks,
Acee

On 4/1/19, 12:31 PM, "Acee Lindem (acee)" <[email-masked]> wrote:

    
        
        /js

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 01 Apr 2019 19:29:51 +0200 (CEST)

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" :)

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.

/martin

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 1 Apr 2019 17:38:52 +0000

On 4/1/19, 1:30 PM, "Martin Bjorklund" <[email-masked]> wrote:

    Hi,

Ok - I understand now. 

Agreed. It seems a prefix with a prefix length of 32 for IPv4 or 128 for IPv6 would allow specification. The convenience is primarily for mapping to CLI.

Thanks,
Acee

    /martin

---

From: Kristian Larsson <[email-masked]>
Date: Mon, 1 Apr 2019 21:37:55 +0200

> "ip-address-and-prefix-length" :)

Right you are, though I'm open to other names but let's first agree on 
use case / need :)

> input, but I wonder if it really is good practice to squeeze two

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.

Similarly, in a routing table you have prefixes, which consist of an 
address and a length - it got its own data type yet you could apply your 
argument to it and say they should be separated. It's just that *that* 
data type forbids bits to be set in the mask portion of the address, 
which is correct for the routing table use case, but means it can't be 
used to describe an interface address and mask.

    kll

---

From: Kristian Larsson <[email-masked]>
Date: Mon, 1 Apr 2019 21:40:09 +0200

On 2019-04-01 19:38, Acee Lindem (acee) wrote:
> Agreed. It seems a prefix with a prefix length of 32 for IPv4 or 128 for IPv6 would allow specification.

No, it does not. You must be referring to some other use case. I want to 
configure the IP address and prefix-length on an interface. The 
prefix-length naturally needs to align with the prefix-length / subnet 
mask used on the network to which the interface is connected. If it is a 
/24 network then the prefix-length needs to be 24. I can't just say it's 
a /32 so I can enter this information - the router wouldn't understand 
what is then connected to that network / interface and wouldn't be able 
to route packets correctly.

At the same time, I need to specify the exact IP address to be used by 
this device on the interface, so I need to have bits set to the right of 
the mask, thus I can't use current ip-prefix type.

> The convenience is primarily for mapping to CLI.

Heh, I don't understand what it has to do with CLI but since you're the 
second person mentioning there must be some connection I don't see.

Kind regards,
    Kristian.

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 1 Apr 2019 12:40:18 -0700

> On Apr 1, 2019, at 10:29 AM, Martin Bjorklund <[email-masked]> wrote:
> 

Agree. The combination makes sense for CLI, but for modeling the address and prefix should be separate.

Mahesh Jethanandani
[email-masked]

---

From: Kristian Larsson <[email-masked]>
Date: Mon, 1 Apr 2019 22:08:47 +0200

Hello Mahesh,

> Agree. The combination makes sense for CLI, but for modeling the address and prefix should be separate.

Okay, then why do we have an ip-prefix data type at all? With the same 
line of argument you apply, it should be split up.

So you're the third person bringing up CLI. I don't get this at all. I 
don't see how CLI are different from everything else. This is about data 
modeling and data modeling is about expressing the world in a data 
modeling language. It's like painting a picture but instead of a brush 
you have a schema language like YANG. What do you see? Express it. It 
doesn't matter if the purpose is a CLI, a web page or just exposing it 
via NETCONF for another system to consume.

I think address-and-prefix-length is natural. JUNOS uses this format. XR 
uses this format (for IPv6 at least). Nokia SROS uses this format.

We have written a bunch of models where the lack of this IMHO makes them 
less elegant. I'd like for there to be an IETF standard data type to 
make those models more elegant.

Kind regards,
    Kristian.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 1 Apr 2019 20:29:14 +0000

Hi Kristian,
Ok - I see that even though the existing ipv4-prefi type requires all 4 octets of the address, the description indicates that the host portion must be zero in the canonical format. Now that I understand your requirement, I'm in favor of adding a type that removes this restriction (i.e., the last statement in the description). 
Thanks,
Acee

On 4/1/19, 3:40 PM, "Kristian Larsson" <[email-masked]> wrote:

    

    
    
    Kind regards,
        Kristian.

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 1 Apr 2019 13:51:26 -0700

> On Apr 1, 2019, at 12:37 PM, Kristian Larsson <[email-masked]> wrote:
> 
> 
> 
> Right you are, though I'm open to other names but let's first agree on use case / need :)
> 
> 
> 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. 

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.

> 
> Similarly, in a routing table you have prefixes, which consist of an address and a length - it got its own data type yet you could apply your argument to it and say they should be separated. It's just that *that* data type forbids bits to be set in the mask portion of the address, which is correct for the routing table use case, but means it can't be used to describe an interface address and mask.
> 
>  kll

Mahesh Jethanandani
[email-masked]

---

From: Kristian Larsson <[email-masked]>
Date: Mon, 1 Apr 2019 23:29:23 +0200

> 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

---

From: Christian Hopps <[email-masked]>
Date: Mon, 1 Apr 2019 17:50:05 -0400

> On Apr 1, 2019, at 1:29 PM, Martin Bjorklund <[email-masked]> wrote:
> 
> Hi,
> 

This has value more than just convenience. In particular it captures and enforces the fact that the address has to be contained by the prefix (e.g., an interfaces address on the network it attaches to's prefix).

Thanks,
Chris.

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 1 Apr 2019 15:09:21 -0700

What Kristian has proposed makes sense, in favor.

Cheers,
Jeff

---

From: tom petch <[email-masked]>
Date: Tue, 2 Apr 2019 11:13:09 +0000

----- Original Message -----
From: "Jeff Tantsura" <[email-masked]>
To: <[email-masked]>; "Kristian Larsson" <[email-masked]>
Sent: Monday, April 01, 2019 11:09 PM

<tp>

Yes, I support this idea and we should be able to come up with a more
user-friendly name;  address-prefix or address-length ?

Tom Petch

p.s.

   identifier          = (ALPHA / "_")
                         *(ALPHA / DIGIT / "_" / "-" / ".")

Cheers,
Jeff
On Apr 1, 2019, 1:09 PM -0700, Kristian Larsson
> make those models more elegant.

------------------------------------------------------------------------
--------

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 2 Apr 2019 14:15:50 +0200

If you go back ~20 messages, my proposal was ip-address-prefix,
ipv4-address-prefix, and ipv6-address-prefix.

/js

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tue, 2 Apr 2019 12:17:12 +0000

> -----Original Message-----
> From: netmod <[email-masked]> On Behalf Of Martin Bjorklund
> Sent: 01 April 2019 18:30
> To: Acee Lindem (acee) <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [netmod] 6991bis: address-with-prefix-length
> 
> Hi,
> 
> *and* a prefix length in one value.  Hence the name "ip-address-and-prefix-
> length" :)
> 
> 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.

Perhaps allowing YANG to support a tuple type would be an elegant solution.  I.e. the value exists on a single path, and has to be atomically updated, but the value can still be composed from different types.

Thanks,
Rob

> > Ok, now I'm confused. I see that the ietf-inet-type model already has the
> types ipv4-prefix and ipv6-prefix. How are these any different???
> > Thanks,
> > Acee
> >
> >     I believe the "address-" could be omitted from the type identifiers. At
> least within the routing area, "ipv4-prefix" is unambiguous.
> >     Thanks,
> >     Acee
> >
> >     On 4/1/19, 12:14 PM, "netmod on behalf of Juergen Schoenwaelder"
> <[email-masked] on behalf of j.schoenwaelder@jacobs-
> university.de> wrote:
> >
> to

---

From: Kristian Larsson <[email-masked]>
Date: Tue, 2 Apr 2019 14:28:15 +0200

Hi Rob,

> Perhaps allowing YANG to support a tuple type would be an elegant solution.  I.e. the value exists on a single path, and has to be atomically updated, but the value can still be composed from diffe…

I think that would be a great addition to YANG. I've had numerous 
discussions over the awkardness of using a grouping to group multiple 
leaves together when you really want to define some form of compound / 
tuple type.

However, that is a longer term project and IMHO not something that 
should stop adding a ip-address-and-prefix-length type to 6991bis today :)

Kind regards,
    Kristian.

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tue, 2 Apr 2019 12:37:44 +0000

Hi Kristian,

Completely agree.  My suggestion for a tuples type is really for YANG Next.  I'll add it to the tracker so that it can be discussed.

For the immediate problem, I agree with defining a combined type.  Juergen's proposal looks good to me.

Thanks,
Rob

> From: netmod <[email-masked]> On Behalf Of Kristian Larsson
> Sent: 02 April 2019 13:28
> To: [email-masked]
> >> "ip-address-and-prefix- length" :)
> >>
> >> input, but I wonder if it really is good practice to squeeze two values into
> one.
> >
> > Perhaps allowing YANG to support a tuple type would be an elegant
> solution.  I.e. the value exists on a single path, and has to be atomically
> updated, but the value can still be composed from different types.
> 
> discussions over the awkardness of using a grouping to group multiple leaves
> together when you really want to define some form of compound / tuple
> type.
> 
> However, that is a longer term project and IMHO not something that should
> stop adding a ip-address-and-prefix-length type to 6991bis today :)
> 
> Kind regards,
>     Kristian.
>

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 02 Apr 2019 14:46:40 +0200 (CEST)

> ipv4-address-prefix, and ipv6-address-prefix.

Do we agree that this type really specifies two values in one?  If so
I think the "and" is useful.

Also note that the current text in RFC 6991 says:

     The ipv4-prefix type represents an IPv4 address prefix.

so having a type ipv4-address-prefix for something that is not (only) an
"ipv4 address prefix" is imo confusing.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 2 Apr 2019 15:58:21 +0200

> "ipv4 address prefix" is imo confusing.

I can fix the wording. But I can also use ip*-address-and-prefix if
people think this a better name. Perhaps I should do both, fix the
wording (at other places the text just says "ip prefix") and use
ip*-address-and-prefix for the new types.

/js

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tue, 2 Apr 2019 15:37:08 +0000

> Sent: 02 April 2019 13:47
> To: [email-masked]
> Cc: [email-masked]
> Do we agree that this type really specifies two values in one?  If so I think the
> "and" is useful.

Isn't an "IP prefix" made up of an "IP address" and a "prefix length"?

So, I think that the names above are probably right, or otherwise if you want the "and" then perhaps it should be "ip-address-and-prefix-length" - which seems clunky?

Thanks,
Rob

> > > Yes, I support this idea and we should be able to come up with a
> > > more user-friendly name;  address-prefix or address-length ?
> > >
> > > Tom Petch
> > >
> > > p.s.
> > >
> > > > > > 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.
> > > > >
> > > > Okay, then why do we have an ip-prefix data type at all? With the
> > > > same line of argument you apply, it should be split up.
> > > >
> > > > So you're the third person bringing up CLI. I don't get this at
> > > > all. I don't see how CLI are different from everything else. This
> > > > is about
> > > data
> > > > modeling language. It's like painting a picture but instead of a
> > > > brush you have a schema language like YANG. What do you see?
> > > > Express it. It doesn't matter if the purpose is a CLI, a web page
> > > > or just exposing it via NETCONF for another system to consume.
> > > >
> > > > We have written a bunch of models where the lack of this IMHO
> > > > makes
> > > them
> > > > less elegant. I'd like for there to be an IETF standard data type
> > > > to make those models more elegant.
> > > >
> > > > Kind regards,
> > > > Kristian.
> > > >

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 2 Apr 2019 15:52:26 +0000

Hi Rob, 

On 4/2/19, 11:37 AM, "netmod on behalf of Rob Wilton (rwilton)" <[email-masked] on behalf of [email-masked]> wrote:

    

This was my confusion as well since the ipv4-prefix and ipv6-prefix types (ietf-inet-types) have been used when they probably shouldn't have been.  Note that they both have the constraint of not allowing the host bits to be set should they should be used in situations like interface address assignment. 

Excerpted from RFC6991 ipv4-type definition (note the last sentence): 
     description
        "The ipv4-prefix type represents an IPv4 address prefix.
         The prefix length is given by the number following the
         slash character and must be less than or equal to 32.

         A prefix length value of n corresponds to an IP address
         mask that has n contiguous 1-bits from the most
         significant bit (MSB) and all other bits set to 0.

         The canonical format of an IPv4 prefix has all bits of
         the IPv4 address set to zero that are not part of the
         IPv4 prefix.";

I think the original suggestion of ipxx-address-prefix would be ok. 

Thanks,
Acee
    
    Thanks,
    Rob

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tue, 2 Apr 2019 16:19:32 +0000

Hi Acee,

Having re-read the thread, I think that "ip-address-prefix" is going to be confusing, since I had incorrectly assumed that the type being defined was an IP prefix, but as you have pointed out there is already a type for that.

I think that we need to choose this name very carefully or otherwise I suspect that folks will accidentally use the wrong type.

So having the type as "ip-address-and-prefix-length" or "ip-addr-and-prefix-len" now seems like a clearer choice to me.  I think that I also now agree with Martin that this is really merging two values into one leaf.

Where is this type going to be used?  Is it only used for configuring host address/prefix?  Or are there other uses cases as well?

Thanks,
Rob

> From: Acee Lindem (acee) <[email-masked]>
> Sent: 02 April 2019 16:52
> To: Rob Wilton (rwilton) <[email-masked]>; Martin Bjorklund <mbj@tail-
> f.com>; [email-masked]
> Cc: [email-masked]
> On 4/2/19, 11:37 AM, "netmod on behalf of Rob Wilton (rwilton)" <netmod-
> [email-masked] on behalf of [email-masked]> wrote:
> 
> 
> 
> This was my confusion as well since the ipv4-prefix and ipv6-prefix types
> (ietf-inet-types) have been used when they probably shouldn't have been.
> Note that they both have the constraint of not allowing the host bits to be set
> should they should be used in situations like interface address assignment.
> 
>     So, I think that the names above are probably right, or otherwise if you
> want the "and" then perhaps it should be "ip-address-and-prefix-length" -
> which seems clunky?
> 
>     > > > > > > On Apr 1, 2019, at 10:29 AM, Martin Bjorklund <mbj@tail-
> f.com>
>     > > > wrote:
>     > > > > > >

---

From: tom petch <[email-masked]>
Date: Tue, 2 Apr 2019 16:34:29 +0000

----- Original Message -----
From: "Rob Wilton (rwilton)" <[email-masked]>
Sent: Tuesday, April 02, 2019 4:37 PM
> Isn't an "IP prefix" made up of an "IP address" and a "prefix length"?

No; that is the point.  A prefix is not an address.  What we specifying
here is an address and an address mask, except that now we can use a
shorthand for the mask since the one bits of the mask are contiguous and
left justified (which they used not to be:-).

Including 'and' in the identifier of this type may be semantically more
accurate but IMHO just clutters up the identifier, makes it longer,
harder to type, read and do anything else with.

'ipv6-address-prefix'

is quite long enough (if not too long).

Tom Petch

>
> So, I think that the names above are probably right, or otherwise if
you want the "and" then perhaps it should be
"ip-address-and-prefix-length" - which seems clunky?
> > > > > > > On Apr 1, 2019, at 10:29 AM, Martin Bjorklund
<[email-masked]>
> > > > > > Agree. The combination makes sense for CLI, but for modeling
the
> > > > address and prefix should be separate.
> > > > >
> > > > > I think address-and-prefix-length is natural. JUNOS uses this
format.
> > > > XR

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tue, 2 Apr 2019 16:44:12 +0000

Hi Tom,

But having joined this thread midway through, I thought that what was being described was an ip-prefix.

I wonder how many folks will mistakenly think that "ip-address-prefix" means "ip-prefix"?

Thanks,
Rob

> From: tom petch <[email-masked]>
> Sent: 02 April 2019 17:34
> No; that is the point.  A prefix is not an address.  What we specifying here is
> an address and an address mask, except that now we can use a shorthand
> for the mask since the one bits of the mask are contiguous and left justified
> (which they used not to be:-).
> 
> accurate but IMHO just clutters up the identifier, makes it longer, harder to
> type, read and do anything else with.
> 
> 'ipv6-address-prefix'
> 
> you want the "and" then perhaps it should be "ip-address-and-prefix-length"
> - which seems clunky?
> >
> > Thanks,
> > Rob
> >
> >
> > >

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Tue, 2 Apr 2019 16:49:33 +0000

If we do go with this, seems to make sense to have "and" in the name, anyway the description will have the details if the name isn't self-explanatory. And this is just to be able to have 1 node instead of 2 nodes (1 IP address and 1 prefix-length), I should go back to the beginning of the thread...

Regards,
Reshad.

On 2019-04-02, 12:20 PM, "netmod on behalf of Rob Wilton (rwilton)" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Acee,

    

    Thanks,
    Rob

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 02 Apr 2019 20:27:32 +0200 (CEST)

"Rob Wilton (rwilton)" <[email-masked]> wrote:
> Hi Acee,
> 
> Having re-read the thread, I think that "ip-address-prefix" is going
> to be confusing, since I had incorrectly assumed that the type being
> defined was an IP prefix, but as you have pointed out there is already
> a type for that.
> 
> I think that we need to choose this name very carefully or otherwise I
> suspect that folks will accidentally use the wrong type.
> 
> So having the type as "ip-address-and-prefix-length" or
> "ip-addr-and-prefix-len" now seems like a clearer choice to me.

The combined type really specifies (i) an ip address and (ii) an ip
prefix.  The prefix happens to be specified with a length indicator.
So I think the name "ip-address-and-prefix" is the correct one.

> 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.

/martin

> Where is this type going to be used?  Is it only used for configuring
> host address/prefix?  Or are there other uses cases as well?
> 
> Thanks,
> Rob
> 
> 
> >     > I think

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 2 Apr 2019 11:37:32 -0700

> On Apr 2, 2019, at 11:27 AM, Martin Bjorklund <[email-masked]> wrote:
> 

+1

Mahesh Jethanandani
[email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 2 Apr 2019 20:48:13 +0200

> 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. ;-)

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.

/js

---

From: Christian Hopps <[email-masked]>
Date: Tue, 2 Apr 2019 14:52:00 -0400

> On Apr 2, 2019, at 2:27 PM, Martin Bjorklund <[email-masked]> wrote:
> 

(Again :) this is not just joining two values, it is also constraining the address value to be a value covered by the prefix. The common use case is for interface state where the interface has an address which should be within the prefix assigned to the network the interface attaches to.

This isn't just about saving space.

I also agree that "-and-" is a really good idea, saving a few characters in an identifier when doing so has shown to cause the identifier to be misunderstood is not an optimization IMO.

Thanks,
Chris.

---

From: Alex Campbell <[email-masked]>
Date: Wed, 3 Apr 2019 02:16:42 +0000

I don't think this is joining an address with a prefix - this is joining an address with a prefix *length*.
If it was two separate values, it would still be constraining the address to be covered by the prefix, since there would be no way to define a prefix that the address didn't cover.

Also a distinction from ipv4-prefix is that an ipv4-prefix is completely meaningless if either part is removed, whereas an ip-address-and-prefix-length still specifies an IP address if you remove the prefix length.

Alex

________________________________________
From: netmod <[email-masked]> on behalf of Christian Hopps <[email-masked]>
Sent: Wednesday, 3 April 2019 7:52 a.m.
To: Martin Bjorklund
Cc: [email-masked]
Subject: Re: [netmod] 6991bis: address-with-prefix-length

Thanks,
Chris.

---

From: Christian Hopps <[email-masked]>
Date: Tue, 2 Apr 2019 23:53:19 -0400

> On Apr 2, 2019, at 22:16, Alex Campbell <[email-masked]> wrote:
> 

It is joining the two things as far as what data it *represents* (i.e., how it can be used). You are correct if we are just talking about the physical bits being stored, but semantics count. Otherwise I think you are agreeing with me that by representing the 2 values this way it necessarily constrains their values the way we want it to.

Thanks,
Chris.

---

From: Kristian Larsson <[email-masked]>
Date: Wed, 17 Apr 2019 21:07:48 +0200

Juergen,

not sure where we really landed with this. I see 6991bis-00 is available 
but without any of these types. I still think these data types makes 
sense and would like to see them included. There are some people against 
and there are some people for. Would it help if I wrote a few lines of 
YANG for this and sent to you?

Kind regards,
    Kristian.

---

From: Kristian Larsson <[email-masked]>
Date: Wed, 17 Apr 2019 21:19:38 +0200

> 'pattern'. So ip-address-and-prefix is actually three values in

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).

> 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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 17 Apr 2019 21:20:13 +0200

Kristian,

I was instructed to upload draft-ietf-netmod-6991bis-00 without any
changes relative to draft-schoenw-netmod-6991bis-01 and this explains
why there is no address-with-prefix-length. The next version will have
definitions for ip-address-and-prefix, ipv4-address-and-prefix, and
ipv6-address-and-prefix - so not action needed from your side at this
point in time.

/js

On Wed, Apr 17, 2019 at 09:07:48PM +0200, Kristian Larsson wrote:
> Juergen,
> 
> not sure where we really landed with this. I see 6991bis-00 is available but
> without any of these types. I still think these data types makes sense and
> would like to see them included. There are some people against and there are
> some people for. Would it help if I wrote a few lines of YANG for this and
> sent to you?
> 
> Kind regards,
>    Kristian.
> 
> 
>

---

From: Kristian Larsson <[email-masked]>
Date: Wed, 17 Apr 2019 21:35:51 +0200

> ipv6-address-and-prefix - so not action needed from your side at this

Ah, okay, I see! :)

Very well, then I'll leave Emacs alone ;)

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.

    kll

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 17 Apr 2019 21:54:37 +0200

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
> 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. ;-)

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.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 18 Apr 2019 09:40:33 +0200

> address and the prefix that this address belongs to. ;-)

Strictly speaking, what is being defined by the number is a subnet mask.

> consistent with what we have was the main reason for me to prefer

I am not in favour of adding this type. Having ip-prefix next to
ip-address-and-prefix is confusing. 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.

Lada

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: Kristian Larsson <[email-masked]>
Date: Thu, 18 Apr 2019 10:09:45 +0200

> 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 
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 :)

> 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 
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

Like I said in another mail, I think it is nice if these common 
datatypes become used by vendors and implementors. Many use proprietary 
models but at least using standard datatypes allows us to easily parse 
the data into sensible datatypes on our end, like Python's 
ipaddress.IPv4Interface.

   kll

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 18 Apr 2019 10:41:11 +0200

On Thu, 2019-04-18 at 10:09 +0200, Kristian Larsson wrote:
> > > > or if
> > > > you

No.

> 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.

> 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.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 18 Apr 2019 14:03:53 +0200

On Thu, Apr 18, 2019 at 10:41:11AM +0200, Ladislav Lhotka wrote:
> 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.

I think we should be pragmatic. There are other common types that are
in fact constructed out of simpler types, date-and-time is a prime
example of a type constructed out of a date value and a time value. It
is sometimes convenient to treat something that is in fact constructed
as an atomic value.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 18 Apr 2019 14:18:43 +0200 (CEST)

Juergen Schoenwaelder <[email-masked]> wrote:
> example of a type constructed out of a date value and a time value.

I think that date-and-time represents one thing - a single point in
time.

> It

Convenient for users that enter these values, perhaps.  But not as
convenient for a program (or a filter) that needs one of the combined
values.  For example, suppose I want to find all entries with a given
prefix; that is non-trivial with a combined ip-address-and-prefix
type.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 18 Apr 2019 14:36:51 +0200

> prefix; that is non-trivial with a combined ip-address-and-prefix

Syntactically, ip-prefix and ip-address-and-prefix look the same, it
is all about whether the non-prefix bits carry a meaning or not. Once
these bits carry a meaning, you argue that this combination is a bad
idea? Or do you argue that ip-prefix also is a bad idea (and if so do
you propose ip-prefix to be deprecated)? And what do we do with url?

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 18 Apr 2019 14:43:36 +0200 (CEST)

Juergen Schoenwaelder <[email-masked]> wrote:
> idea? Or do you argue that ip-prefix also is a bad idea

No, filtering works b/c ip-prefix has a canonical format.

I argue that in general it is a bad idea to combine two values into
one.

/martin

> (and if so do

---

From: Per Hedeland <[email-masked]>
Date: Thu, 18 Apr 2019 15:14:20 +0200

> 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.

> can be used in the next revision of RFC 7277. This would be my preferred

 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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 18 Apr 2019 18:02:28 +0200

> interface is connected to.

The property relevant for the network is the _prefix_, not the
prefix-length. The prefix-length 12 does not tell the system the
network prefix that is valid on the link, the prefix tells it. In
other words, you have a single value that gives you an address and a
prefix, hence ip-address-and-prefix. The question is whether we name
it according to the pieces that go into the combined value or whether
we name it according to the meaning of the combined value. What goes
in is "address + prefix length" and the meaning is "address + prefix".

> statement could warn against this.

Some bundled types are widely used and practically useful. See the uri
type, which is a big complicated combination of many different pieces.
Yes, filtering for a port number in a uri is likely not easy. These
are tradeoffs. The notion that "bundles types" are generally bad is I
think not true. I am not saying we should make it an art to create
"bundled types", I am just challenging the idea that they are
generally bad.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 18 Apr 2019 18:25:32 +0200 (CEST)

> type, which is a big complicated combination of many different pieces.

A uri represents a single entity; a resource.   From RFC 3986:

   A Uniform Resource Identifier (URI) is a compact sequence of
   characters that identifies an abstract or physical resource.

> Yes, filtering for a port number in a uri is likely not easy.

Right, but the port is just one part of the uri syntax for a resource
(for some schemes).  The uri type doesn't represent multiple "things"
(scheme, host, port, etc).  If you use a URI to model a port you have
likely a bad model.  Whereas for the proposed ip-address-and-prefix,
it is clear that you're suppose to use it when you need to model an
ip-address and an ip-prefix.

/martin

> These

---

From: Kristian Larsson <[email-masked]>
Date: Thu, 18 Apr 2019 22:34:43 +0200

> I think that date-and-time represents one thing - a single point in

Convenient for users to enter a single point in time in terms of year, 
month, day, hours, minutes and seconds, perhaps. But not as convenient 
for a program that needs to compare two date-and-times. Clearly for a 
program comparing times against each other we must represent a point in 
time as the number of vibrations of cesium since an arbitrarily chosen 
epoch.

> values.

Really? Are you using a text representation of IP addresses when you 
handle them in your program?

If you are to deal with IP addresses, prefixes etc in a robust way in 
your program, you need an internal datatype that understands what an 
address is - it needs to handle it as bits and massage it to any other 
presentation you want. It needs to understand relevant comparisons and 
operations, like is prefix A contained in prefix B?

Or if we are dealing with time, then a class that understands leap 
years, leap seconds, time zones etc can be fairly useful so you don't 
have to fall in any of those pitfalls.

I don't think we choose a format or representation in our YANG models 
primarily to suit the algorithmic needs of a computer program, in that 
case an IPv4 address would just be a uint32 and not the dotted quad 
format we have today.

>  For example, suppose I want to find all entries with a given

This seems like a very weird example since it doesn't support your case; 
it is not easier with two separate leaves!?

The alternative to using ip-address-and-prefix-length would be to use 
two leaves; one for the address and the other for the subnet mask / 
prefix-length.

combined:
ip-address-and-prefix-length: 1.2.3.4/24

split:
address: 1.2.3.4
prefix-length: 24

Say we have another interface with address '1.2.3.5' (prefix-length 24 
still). In what way is it easier to determine these are part of the same 
IP prefix / subnetwork by having the values split in two leaves? There 
is no text operation that can easily do this for us - we need to parse 
the values with some class / type in our programming language that helps 
us make this comparison so in what way is ip-address-and-prefix-length 
worse?

Let us look at some examples how this is typically done. Again, 
postgresql has the 'inet' type. From the docs:

"The input format for this type is address/y where address is an IPv4 or 
IPv6 address and y is the number of bits in the netmask. If the /y 
portion is missing, the netmask is 32 for IPv4 and 128 for IPv6, so the 
value represents just a single host. On display, the /y portion is 
suppressed if the netmask specifies a single host."

It wants it combined, which means the two leaves need to be formatted 
into something that looks like 1.2.3.4/24.

Python ipaddress.IPv4, from example:

   interface = IPv4Interface('192.0.2.5/24')

Same thing. Rust ipaddress? Same thing. Go net? Same. Our internal 
classes that compute IP addressing? Same thing. It seems most of the 
datatypes that natively handle this kind of information takes a text 
format like 1.2.3.4/24 as input (and not as separate fields), which is 
what is being suggested we have a datatype for.

   kll

---

From: Kristian Larsson <[email-masked]>
Date: Thu, 18 Apr 2019 23:11:10 +0200

> The property relevant for the network is the _prefix_, not the

Agreed.

> The prefix-length 12 does not tell the system the

Very good analysis on why we have different opinions for the name :)

I can tell someone "enter the address and prefix-length" and they will 
understand what I mean. I don't think it is clear what to enter if 
someone says "enter the address and prefix".. this is why I think 
ip*-address-and-prefix-length is the more natural name :)

Kind regards,
    Kristian.

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 23 Apr 2019 12:55:03 +0200 (CEST)

Kristian Larsson <[email-masked]> wrote:
> for a program that needs to compare two date-and-times.

Actually, *comparing* works quite ok, but calculating diff is not as
easy.

> Clearly for a
> program comparing times against each other we must represent a point
> in time as the number of vibrations of cesium since an arbitrarily
> chosen epoch.

We do have yang:timeticks as well.  In some cases that's a better type
than yang:date-and-time.

> operations, like is prefix A contained in prefix B?

I agree.  Note that I wrote *filter* above.  It also extends to
must/when expressions.  The problem is that these mechanisms use
XPath, and XPath is quite limited when it comes to "understanding"
types.  I even wrote a (now expired) draft with a proposed solution:
https://tools.ietf.org/html/draft-bjorklund-netmod-yang-xpath-extensions-00

> This seems like a very weird example since it doesn't support your
> case; it is not easier with two separate leaves!?
> 
> still). In what way is it easier to determine these are part of the
> same IP prefix / subnetwork by having the values split in two leaves?

As have been said before in this thread, it is not an address and a
prefix length, it is an address and a prefix.  So the split model
would have a leaf "ip-prefix: 1.2.3.0/24", which can be compared.

> There is no text operation that can easily do this for us - we need to
> parse the values with some class / type in our programming language
> that helps us make this comparison so in what way is
> ip-address-and-prefix-length worse?
> 
> "The input format for this type is address/y where address is an IPv4
> or IPv6 address and y is the number of bits in the netmask. If the /y
> portion is missing, the netmask is 32 for IPv4 and 128 for IPv6, so
> the value represents just a single host. On display, the /y portion is

Is your point that there exist libraries that _can_ handle
"<addr>/<plen>", or are you suggesting that it is problematic to have
separate objects b/c libraries _only_ handle "<addr>/<plen>"?

If it is the former, I agree.  There exist functions that can handle
this format.

/martin

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tue, 23 Apr 2019 16:45:53 +0000

I'm with Kristian on this. :-)

I also think that "1.2.3.4/24" contains an IP addresses, and the length of the IP prefix.

For me, the natural encoding of:
  ip-address-and-prefix would be "1.2.3.4/1.2.3.0"
  ip-address-and-prefix-mask would be "1.2.3.4/255.255.255.0"
  ip-address-and-prefix-len would be "1.2.3.4/24"

I think that only the first one actually contains both the IP address and the prefix.  For the other two the prefix is derived from the provided values.

----

I also think that it is useful to define this type, because types like this are being used in various vendor models.

However, I do have a concern that we may be opening IETF up for inconsistency with the IETF YANG models if different protocols define this in different ways.  Perhaps the answer is to define both the combined type and the equivalent grouping, and also perhaps highlight in the description of the grouping of the two alternative representations that are available.

Thanks,
Rob

-----Original Message-----
From: netmod <[email-masked]> On Behalf Of Martin Bjorklund
Sent: 23 April 2019 11:55
To: [email-masked]
Cc: [email-masked]
Subject: Re: [netmod] 6991bis: address-with-prefix-length

Kristian Larsson <[email-masked]> wrote:
> >>>> 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 think we should be pragmatic. There are other common types that 
> >> are in fact constructed out of simpler types, date-and-time is a 
> >> prime example of a type constructed out of a date value and a time value.

Actually, *comparing* works quite ok, but calculating diff is not as easy.

> in time as the number of vibrations of cesium since an arbitrarily 

We do have yang:timeticks as well.  In some cases that's a better type than yang:date-and-time.

> >> is sometimes convenient to treat something that is in fact 
> >> constructed as an atomic value.
> > convenient for a program (or a filter) that needs one of the 
> > combined values.
> 

I agree.  Note that I wrote *filter* above.  It also extends to must/when expressions.  The problem is that these mechanisms use XPath, and XPath is quite limited when it comes to "understanding"
types.  I even wrote a (now expired) draft with a proposed solution:
https://tools.ietf.org/html/draft-bjorklund-netmod-yang-xpath-extensions-00

> ip-address-and-prefix-length: 
[RW] 
> same IP prefix / subnetwork by having the values split in two leaves?

As have been said before in this thread, it is not an address and a prefix length, it is an address and a prefix.  So the split model would have a leaf "ip-prefix: 1.2.3.0/24", which can be compared.

> what is being suggested we have a datatype for.

Is your point that there exist libraries that _can_ handle "<addr>/<plen>", or are you suggesting that it is problematic to have separate objects b/c libraries _only_ handle "<addr>/<plen>"?

If it is the former, I agree.  There exist functions that can handle this format.

/martin

---

From: tom petch <[email-masked]>
Date: Wed, 24 Apr 2019 10:10:26 +0000

----- Original Message -----
From: "Rob Wilton (rwilton)" <[email-masked]>
ent: Tuesday, April 23, 2019 5:45 PM

> I think that only the first one actually contains both the IP address
and the prefix.  For the other two the prefix is derived from the
provided values.
>
> ----
>
> I also think that it is useful to define this type, because types like
this are being used in various vendor models.
>
> However, I do have a concern that we may be opening IETF up for
inconsistency with the IETF YANG models if different protocols define
this in different ways.  Perhaps the answer is to define both the
combined type and the equivalent grouping, and also perhaps highlight in
the description of the grouping of the two alternative representations
that are available.

I think that the other trap we are falling into is that of trying to
make an identifier do all the work, convey the semantics, and in doing
so make the identifier clumsy and hard to use - the IETF is good at
this:-(

As was said three weeks ago, this type has three elements, an address -
10.0.0.1 - a prefix - 10.0.0.0 - and a prefix length - /24.  If you do
not have the length, then you cannot tell 10.0.0.0 (with a length of 24)
from 10.0.0.0 (with a length of 16).  But to then call it 'ip address
with prefix and with prefix length' is - well, silly comes to mind.

We need to bear in mind the namespace we are slotting this into, namely

 ip-address
 ipv4-address
 ipv6-address
 ip-address-no-zone
 ipv4-address-no-zone
 ipv6-address-no-zone
 ip-prefix
 ipv4-prefix
 ipv6-prefix

which steers me towards
ip-address-prefix
with perhaps an alternative of
ip-address-mask
except that I fear that the latter would fall foul of the IESG with
their insistence that all must be IPv6 and having to cater for those who
are not old enough to know what a mask is.

If the namespace were large, e.g. Webster's Dictionary, then our
identifier would need to be longer - but it isn't

Tom Petch

easy.
than yang:date-and-time.
> I agree.  Note that I wrote *filter* above.  It also extends to
must/when expressions.  The problem is that these mechanisms use XPath,
and XPath is quite limited when it comes to "understanding"
> types.  I even wrote a (now expired) draft with a proposed solution:
https://tools.ietf.org/html/draft-bjorklund-netmod-yang-xpath-extensions
-00
> As have been said before in this thread, it is not an address and a
prefix length, it is an address and a prefix.  So the split model would
have a leaf "ip-prefix: 1.2.3.0/24", which can be compared.
this format.

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 25 Apr 2019 10:31:13 +0200

> "/" is not a prefix but a *prefix-length*. Another way of putting it

Yes, you are right, mea culpa.

> RFC 7277. A grouping could be nice, but it is still two separate

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.

> already *use* the "bundled" type, i.e. it "needs" to be a single leaf

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

---

From: Kristian Larsson <[email-masked]>
Date: Fri, 26 Apr 2019 14:19:51 +0200

On 2019-04-23 12:55, Martin Bjorklund wrote:
>>>>>> different

By relying on the lexical order? Time zone is at the end so it will 
probably mess things up. Maybe that's why you said only *quite* ok.

Speaking of time-zone, shouldn't that be modeled as a separate leaf?

I think you could probably have a conversation around the combination or 
split of time / time-zone rather similar to the conversation we are 
having here about the combination or split of address / prefix-length.

> We do have yang:timeticks as well.  In some cases that's a better type

In some cases it might be better to have a ip*-address-and-prefix-length 
type than two separate leaves ;)

> https://tools.ietf.org/html/draft-bjorklund-netmod-yang-xpath-extensions-00

I can see how it is challenging with XPath but it seems equally as 
challenging with a combined leaf as with split leaves.

I think you were trying to argue for how it is beneficial to have split 
leaves, one for address and another for mask/prefix-length, as it makes 
filtering easier. I don't think you've shown that.

> prefix length, it is an address and a prefix.

There are multiple opinions on what "it is" in this thread. 
authoritatively restating your opinion does not help. Juergen called 
this "what goes in" vs "the meaning".

Perhaps easier to agree on, is the information that is contained, which 
is a superset of "what goes in" and "the meaning"

1.2.3.4/24
^^^^^^^ ----- address
         ^^ -- prefix-length
^^^^^ + ^^ -- prefix

24 is a prefix-length and it is in there. I'm fine with anyone claiming 
that there is "prefix information" contained within 1.2.3.4/24, just as 
there is an address and a prefix-length in there but I think claiming, 
as you did, that there is no prefix-length in there is patently false.

The representation of a prefix includes a prefix-length so I think your 
statement is incorrect as it contradicts itself.

Since you are adamant about the definition I suppose you had no part in 
the creation of tailf:ipv4-address-and-prefix-length or it would have 
been called ipv4-address-and-prefix!? Or maybe it wouldn't have existed 
at all.

> So the split model

No, it would not. The split model is what is in RFC7277/8344, which you 
wrote, and there is no ip-prefix in that model so I don't know why you 
would say that the split model would have it.

> separate objects b/c libraries _only_ handle "<addr>/<plen>"?

Neither, really.

You suggested that a combined type is worse from a program perspective 
and use a filter example to prove it.

I show how:
- filtering is equally non-trivial with two separate leaves (the leaf 
you want to filter on doesn't exist)
- you need to use some ip address library to parse and filter with
- that probably rules out any XPath filter
- most such ip addressing libraries actually use the combined form and 
not separate leaves, so if anything a slight convenience factor to the 
combined form

    kll