> On Apr 2, 2019, at 22:16, Alex Campbell <[email protected]> wrote:
> 
> 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.

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.

> 
> 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 protected]> on behalf of Christian Hopps 
> <[email protected]>
> Sent: Wednesday, 3 April 2019 7:52 a.m.
> To: Martin Bjorklund
> Cc: [email protected]
> Subject: Re: [netmod] 6991bis: address-with-prefix-length
> 
>> On Apr 2, 2019, at 2:27 PM, Martin Bjorklund <[email protected]> wrote:
>> 
>> "Rob Wilton (rwilton)" <[email protected]> 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.
> 
> (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.
> 
>> 
>> 
>> /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
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: Acee Lindem (acee) <[email protected]>
>>>> Sent: 02 April 2019 16:52
>>>> To: Rob Wilton (rwilton) <[email protected]>; Martin Bjorklund
>>>> <mbj@tail-
>>>> f.com>; [email protected]
>>>> Cc: [email protected]
>>>> Subject: Re: [netmod] 6991bis: address-with-prefix-length
>>>> 
>>>> Hi Rob,
>>>> 
>>>> On 4/2/19, 11:37 AM, "netmod on behalf of Rob Wilton (rwilton)"
>>>> <netmod-
>>>> [email protected] on behalf of [email protected]> wrote:
>>>> 
>>>> 
>>>> 
>>>>> -----Original Message-----
>>>>> From: netmod <[email protected]> On Behalf Of Martin
>>>> Bjorklund
>>>>> Sent: 02 April 2019 13:47
>>>>> To: [email protected]
>>>>> Cc: [email protected]
>>>>> Subject: Re: [netmod] 6991bis: address-with-prefix-length
>>>>> 
>>>>> Juergen Schoenwaelder <[email protected]> wrote:
>>>>>> If you go back ~20 messages, my proposal was ip-address-prefix,
>>>>>> 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.
>>>> 
>>>>   Isn't an "IP prefix" made up of an "IP address" and a "prefix length"?
>>>> 
>>>> 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.";
>>>> 
>>>>   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?
>>>> 
>>>> I think the original suggestion of ipxx-address-prefix would be ok.
>>>> 
>>>> Thanks,
>>>> Acee
>>>> 
>>>>   Thanks,
>>>>   Rob
>>>> 
>>>> 
>>>>> 
>>>>> 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
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>> 
>>>>>> /js
>>>>>> 
>>>>>> On Tue, Apr 02, 2019 at 11:13:09AM +0000, tom petch wrote:
>>>>>>> ----- Original Message -----
>>>>>>> From: "Jeff Tantsura" <[email protected]>
>>>>>>> To: <[email protected]>; "Kristian Larsson" <[email protected]>
>>>>>>> Sent: Monday, April 01, 2019 11:09 PM
>>>>>>> 
>>>>>>> What Kristian has proposed makes sense, in favor.
>>>>>>> 
>>>>>>> <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
>>>>>>> <[email protected]>, wrote:
>>>>>>>> Hello Mahesh,
>>>>>>>> 
>>>>>>>> On 2019-04-01 21:40, Mahesh Jethanandani wrote:
>>>>>>>>> 
>>>>>>>>>> On Apr 1, 2019, at 10:29 AM, Martin Bjorklund <mbj@tail-
>>>> f.com>
>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>> 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.
>>>>>>>>> 
>>>>>>>>> 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.
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> netmod mailing list
>>>>>>>> [email protected]
>>>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>> --------------------------------------------------------------------
>>>>>>> ----
>>>>>>> --------
>>>>>>> 
>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> netmod mailing list
>>>>>>>> [email protected]
>>>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> netmod mailing list
>>>>>>> [email protected]
>>>>>>> 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/>
>>>>>> 
>>>>>> _______________________________________________
>>>>>> netmod mailing list
>>>>>> [email protected]
>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> netmod mailing list
>>>>> [email protected]
>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>> 
>>>>   _______________________________________________
>>>>   netmod mailing list
>>>>   [email protected]
>>>>   https://www.ietf.org/mailman/listinfo/netmod
>>>> 
>>>> 
>>> 
>> _______________________________________________
>> netmod mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/netmod
> 

_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to