"Rob Wilton (rwilton)" writes:
>> -Original Message-
>> From: netmod On Behalf Of Ladislav Lhotka
>> Sent: 02 May 2019 13:39
>> To: Mikael Abrahamsson ; Randy Presuhn
>>
>> Cc: netmod@ietf.org
>> Subject: Re: [netmod] 6021 ipv4-prefi
> -Original Message-
> From: netmod On Behalf Of Ladislav Lhotka
> Sent: 02 May 2019 13:39
> To: Mikael Abrahamsson ; Randy Presuhn
>
> Cc: netmod@ietf.org
> Subject: Re: [netmod] 6021 ipv4-prefix
>
> Mikael Abrahamsson writes:
>
> > On
Mikael Abrahamsson writes:
> On Wed, 1 May 2019, Randy Presuhn wrote:
>
>> Hi -
>>
>> On 5/1/2019 12:46 PM, Mikael Abrahamsson wrote:
>>
>>> Where is the text that tells the server implementor whether to throw an
>>> error when client commits non-zero bits, or to just throw the bits away
>>>
On Wed, 1 May 2019, Randy Presuhn wrote:
Hi -
On 5/1/2019 12:46 PM, Mikael Abrahamsson wrote:
Where is the text that tells the server implementor whether to throw an
error when client commits non-zero bits, or to just throw the bits away
and store the value in the canonical format?
Such
- Original Message -
From: "Juergen Schoenwaelder"
Sent: Wednesday, May 01, 2019 12:17 PM
> On Wed, May 01, 2019 at 10:55:38AM +0200, Mikael Abrahamsson wrote:
> >
> > So while you seem to think I am not reading your text, it seems to
me you're
> > not reading what I am saying either. You
Hi -
On 5/1/2019 12:46 PM, Mikael Abrahamsson wrote:
Where is the text that tells the server implementor whether to throw an
error when client commits non-zero bits, or to just throw the bits away
and store the value in the canonical format?
Such text would be an inappropriate constraint
On Wed, 1 May 2019, Juergen Schoenwaelder wrote:
The basic disconnect here may be that for me the prefix is the value
while for you the value is the prefix plus the unused bits.
My disconnect is what the server should do when it encounters a value
where the bits are non-zero.
Where is the t
> -Original Message-
> From: Juergen Schoenwaelder
> Sent: 01 May 2019 16:53
> To: Mikael Abrahamsson
> Cc: Rob Wilton (rwilton) ; netmod@ietf.org
> Subject: Re: [netmod] 6021 ipv4-prefix
>
> On Wed, May 01, 2019 at 03:12:47PM +0200, Mikael Abrahamsson wrote:
On Wed, May 01, 2019 at 03:12:47PM +0200, Mikael Abrahamsson wrote:
>
> I am fine with c), but I am also saying I disagree with your view that this
> this behaviour has been specified "since the beginning". This might have
> been obvious to you from the beginning, but it's not wrotten down properl
Hi Mikael,
> -Original Message-
> From: Mikael Abrahamsson
> Sent: 01 May 2019 14:13
> To: Juergen Schoenwaelder
> Cc: Rob Wilton (rwilton) ; netmod@ietf.org
> Subject: Re: [netmod] 6021 ipv4-prefix
>
> On Wed, 1 May 2019, Juergen Schoenwaelder wrote:
>
&
On Wed, 1 May 2019, Juergen Schoenwaelder wrote:
I personally do take the standpoint that irrelevant bits do not matter
for the value of a prefix, i.e., 192.168.0.1/24 and 192.168.0.0/24 are
two different representations for the same prefix. You seem to take
the standpoint that 192.168.0.1/24 an
On Wed, May 01, 2019 at 10:55:38AM +0200, Mikael Abrahamsson wrote:
>
> So while you seem to think I am not reading your text, it seems to me you're
> not reading what I am saying either. You're not responding to the points I
> am trying to make anyway.
>
> https://tools.ietf.org/html/rfc7950#sec
On Tue, 30 Apr 2019, Randy Presuhn wrote:
Hi -
On 4/30/2019 1:46 AM, Mikael Abrahamsson wrote:
Is it generally ok that the canonical value potentially represents a
different bit field/value than what the client sent?
The *value* represented is the same. The sequences of bytes used
On Tue, 30 Apr 2019, Juergen Schoenwaelder wrote:
On Tue, Apr 30, 2019 at 10:46:34AM +0200, Mikael Abrahamsson wrote:
On Tue, 30 Apr 2019, Juergen Schoenwaelder wrote:
I think we go in circles in this thread and I will stop explaining
things again and again. I suggest people look at the next
Hi -
On 4/30/2019 1:46 AM, Mikael Abrahamsson wrote:
Is it generally ok that the canonical value potentially represents a
different bit field/value than what the client sent?
The *value* represented is the same. The sequences of bytes used
to represent that value may be different.
On Tue, Apr 30, 2019 at 10:46:34AM +0200, Mikael Abrahamsson wrote:
> On Tue, 30 Apr 2019, Juergen Schoenwaelder wrote:
>
> > I think we go in circles in this thread and I will stop explaining
> > things again and again. I suggest people look at the next revision
> > and if anything remains unclea
On Tue, 30 Apr 2019, Juergen Schoenwaelder wrote:
I think we go in circles in this thread and I will stop explaining
things again and again. I suggest people look at the next revision
and if anything remains unclear, people can send concrete edit
proposals.
You don't have to explain it. Let me
I think we go in circles in this thread and I will stop explaining
things again and again. I suggest people look at the next revision
and if anything remains unclear, people can send concrete edit
proposals.
/js
On Tue, Apr 30, 2019 at 07:24:17AM +0200, Mikael Abrahamsson wrote:
> On Mon, 29 Apr
On Mon, 29 Apr 2019, Juergen Schoenwaelder wrote:
I believe we are not in the position to tell clients that they should or
should not do. If I push the config value 2001:DB8::/64 (since my
database has values stored using uppercase characters) and it comes back
as 2001:db8::/64, then so be it;
On Mon, Apr 29, 2019 at 05:08:41PM +, Rob Wilton (rwilton) wrote:
>
> If YANG allows a typedef to refine the canonical definition of a
> base type, then I think that the YANG RFC should be explicit on this
> (e.g. in YANG Next). Particularly, because this requires a server
> implementation to
On Mon, 2019-04-29 at 15:58 +, Rob Wilton (rwilton) wrote:
> > -Original Message-
> > From: Ladislav Lhotka
> > Sent: 29 April 2019 16:51
> > To: Rob Wilton (rwilton)
> > Cc: NETMOD WG
> > Subject: Re: [netmod] 6021 ipv4-prefix
> >
> &g
> -Original Message-
> From: Juergen Schoenwaelder
> Sent: 29 April 2019 17:12
> To: Rob Wilton (rwilton)
> Cc: Ladislav Lhotka ; NETMOD WG
> Subject: Re: [netmod] 6021 ipv4-prefix
>
> On Mon, Apr 29, 2019 at 03:58:03PM +, Rob Wilton (rwilton) wrote:
>
On Mon, Apr 29, 2019 at 03:58:03PM +, Rob Wilton (rwilton) wrote:
>
>
> But according to RFC-7950, from a language POV, I think that it is reasonable
> to interpret the canonical format of ipv4-prefix to match that of its base
> YANG type, i.e. string.
>
> 9.4.2. Canonical Form
>
>Th
> -Original Message-
> From: Ladislav Lhotka
> Sent: 29 April 2019 16:51
> To: Rob Wilton (rwilton)
> Cc: NETMOD WG
> Subject: Re: [netmod] 6021 ipv4-prefix
>
> On Mon, 2019-04-29 at 15:32 +, Rob Wilton (rwilton) wrote:
> > BTW, did you mean
; > To: Rob Wilton (rwilton)
> > Subject: Re: [netmod] 6021 ipv4-prefix
> >
> > On Mon, 2019-04-29 at 14:53 +, Rob Wilton (rwilton) wrote:
> > > Hi Lada,
> > >
> > > > -Original Message-
> > > > From: netmod On Behalf Of Ladisla
On Mon, Apr 29, 2019 at 02:53:40PM +, Rob Wilton (rwilton) wrote:
>
> My aim with this text is to:
> - encourage clients to use canonical format, since that seems to cause the
> least problems.
> - align the v4 and v6 definitions.
> - retain the existing flexibility for servers to choose w
Hi Lada,
> -Original Message-
> From: netmod On Behalf Of Ladislav Lhotka
> Sent: 29 April 2019 15:24
> To: netmod@ietf.org
> Subject: Re: [netmod] 6021 ipv4-prefix
>
> On Mon, 2019-04-29 at 14:02 +, Rob Wilton (rwilton) wrote:
> > > -Original Me
On Mon, 2019-04-29 at 14:02 +, Rob Wilton (rwilton) wrote:
> > -Original Message-
> > From: Juergen Schoenwaelder
> > Sent: 29 April 2019 14:46
> > To: Rob Wilton (rwilton)
> > Cc: Acee Lindem (acee) ; netmod@ietf.org
> > Subject: Re: [netmod] 6021
> -Original Message-
> From: Juergen Schoenwaelder
> Sent: 29 April 2019 14:46
> To: Rob Wilton (rwilton)
> Cc: Acee Lindem (acee) ; netmod@ietf.org
> Subject: Re: [netmod] 6021 ipv4-prefix
>
> On Mon, Apr 29, 2019 at 01:33:22PM +, Rob Wilton (rwilton) wr
On Mon, Apr 29, 2019 at 01:33:22PM +, Rob Wilton (rwilton) wrote:
>
> But I'm not convinced that allowing ipv4-prefix values in the non-canonical
> format is necessarily the right thing to do. If we were defining these as a
> new type today then would we make the same choice of typedef defi
> -Original Message-
> From: Juergen Schoenwaelder
> Sent: 29 April 2019 11:35
> To: Rob Wilton (rwilton)
> Cc: Acee Lindem (acee) ; netmod@ietf.org
> Subject: Re: [netmod] 6021 ipv4-prefix
>
> On Mon, Apr 29, 2019 at 10:19:01AM +, Rob Wilton (rwilt
On Mon, Apr 29, 2019 at 10:19:01AM +, Rob Wilton (rwilton) wrote:
>
> It is obvious to me that internally the router should treat these the same,
> i.e. in the canonical format.
> It is also obvious to me that the operational value reported for this should
> be "10.0.0.0/8".
>
> But it isn'
> -Original Message-
> From: Juergen Schoenwaelder
> Sent: 29 April 2019 11:02
> To: Rob Wilton (rwilton)
> Cc: Acee Lindem (acee) ; netmod@ietf.org
> Subject: Re: [netmod] 6021 ipv4-prefix
>
> On Mon, Apr 29, 2019 at 09:51:41AM +, Rob Wilton (rwilto
On Mon, Apr 29, 2019 at 09:51:41AM +, Rob Wilton (rwilton) wrote:
> Hi Juergen,
>
> > -Original Message-
> > From: netmod On Behalf Of Juergen
> > Schoenwaelder
> > Sent: 26 April 2019 18:30
> > To: Acee Lindem (acee)
> > Cc: netmod@ie
On Mon, Apr 29, 2019 at 10:48:25AM +0200, Martin Bjorklund wrote:
>
> I did some digging, and it turns out that we had this type internally
> before it was part if ietf-inet-types, where we did not require that
> all non-prefix bits were zero, but at one point (after
> draft-ietf-netmod-yang-types
Hi Juergen,
> -Original Message-
> From: netmod On Behalf Of Juergen
> Schoenwaelder
> Sent: 26 April 2019 18:30
> To: Acee Lindem (acee)
> Cc: netmod@ietf.org
> Subject: Re: [netmod] 6021 ipv4-prefix
>
> On Fri, Apr 26, 2019 at 04:55:02PM +, Acee
On Mon, 2019-04-29 at 10:48 +0200, Martin Bjorklund wrote:
> Kristian Larsson wrote:
> >
> > On 2019-04-25 23:51, Juergen Schoenwaelder wrote:
> > > On Thu, Apr 25, 2019 at 11:20:57PM +0200, Kristian Larsson wrote:
> > > >
> > > > On 2019-04-18 13:12, Juergen Schoenwaelder wrote:
> > > > > On Th
Kristian Larsson wrote:
>
>
> On 2019-04-25 23:51, Juergen Schoenwaelder wrote:
> > On Thu, Apr 25, 2019 at 11:20:57PM +0200, Kristian Larsson wrote:
> >>
> >>
> >> On 2019-04-18 13:12, Juergen Schoenwaelder wrote:
> >>> On Thu, Apr 18, 2019 at 12:53:22PM +0200, Mikael Abrahamsson wrote:
>
"Acee Lindem (acee)" writes:
> Hi Juergen,
>
> On 4/26/19, 11:36 AM, "netmod on behalf of Juergen Schoenwaelder"
>
> wrote:
>
> On Fri, Apr 26, 2019 at 05:07:52PM +0200, Kristian Larsson wrote:
> >
> > I think the canonical representation is quite clear as is the part that
> th
On Sat, Apr 27, 2019 at 12:23:05PM +, tom petch wrote:
>
> No way can I approach being Martin but ..
>
> this topic has been active on the 6man list and to some extent on the
> main IETF list with one very active participant arguing that because
> widely-used implementations allow something t
- Original Message -
From: "Kristian Larsson"
Sent: Thursday, April 25, 2019 11:07 PM
> On 2019-04-25 23:51, Juergen Schoenwaelder wrote:
> > On Thu, Apr 25, 2019 at 11:20:57PM +0200, Kristian Larsson wrote:
> >> On 2019-04-18 13:12, Juergen Schoenwaelder wrote:
> >>> On Thu, Apr 18, 20
On Fri, Apr 26, 2019 at 04:55:02PM +, Acee Lindem (acee) wrote:
> Hi Juergen,
>
> I must admit that I think this is the worst possible outcome. Independent of
> the original intent, at a high level it is just not a good idea to accept the
> non-canonical prefix format and return the canonic
Hi Juergen,
On 4/26/19, 11:36 AM, "netmod on behalf of Juergen Schoenwaelder"
wrote:
On Fri, Apr 26, 2019 at 05:07:52PM +0200, Kristian Larsson wrote:
>
> I think the canonical representation is quite clear as is the part that
the
> server must return data (and conceptually
On Fri, Apr 26, 2019 at 05:07:52PM +0200, Kristian Larsson wrote:
>
> I think the canonical representation is quite clear as is the part that the
> server must return data (and conceptually store) in canonical format. What
> is much less clear is the allowed input formats which then includes
> 200
On 2019-04-26 13:28, Ladislav Lhotka wrote:
On Fri, 2019-04-26 at 12:56 +0200, Kristian Larsson wrote:
On 2019-04-26 09:39, Ladislav Lhotka wrote:
On Thu, 2019-04-25 at 23:51 +0200, Juergen Schoenwaelder wrote:
On Thu, Apr 25, 2019 at 11:20:57PM +0200, Kristian Larsson wrote:
Vice versa,
On 2019-04-26 13:18, Juergen Schoenwaelder wrote:
On Fri, Apr 26, 2019 at 12:56:57PM +0200, Kristian Larsson wrote:
I'm having trouble unifying the following:
- Juergen says RFC6021 and 6991 consider 2001:db8::1/64 to be valid input
that can safely be interpreted to mean 2001:db8::/64
- NSO
On Fri, 2019-04-26 at 12:56 +0200, Kristian Larsson wrote:
>
> On 2019-04-26 09:39, Ladislav Lhotka wrote:
> > On Thu, 2019-04-25 at 23:51 +0200, Juergen Schoenwaelder wrote:
> > > On Thu, Apr 25, 2019 at 11:20:57PM +0200, Kristian Larsson wrote:
> > > > On 2019-04-18 13:12, Juergen Schoenwaelder
On Fri, Apr 26, 2019 at 12:56:57PM +0200, Kristian Larsson wrote:
>
> I'm having trouble unifying the following:
> - Juergen says RFC6021 and 6991 consider 2001:db8::1/64 to be valid input
> that can safely be interpreted to mean 2001:db8::/64
> - NSO instead treats 2001:db8::1/64 as a syntax erro
Agreed.
Thanks,
Acee
On 4/26/19, 1:52 AM, "netmod on behalf of Jeff Tantsura"
wrote:
+1
Cheers,
Jeff
> On Apr 18, 2019, at 6:12 AM, Lou Berger wrote:
>
> Having worked with UIs that have the behavior of accepting an
address/prefix-len and mapping it to a
On 2019-04-26 09:39, Ladislav Lhotka wrote:
On Thu, 2019-04-25 at 23:51 +0200, Juergen Schoenwaelder wrote:
On Thu, Apr 25, 2019 at 11:20:57PM +0200, Kristian Larsson wrote:
On 2019-04-18 13:12, Juergen Schoenwaelder wrote:
On Thu, Apr 18, 2019 at 12:53:22PM +0200, Mikael Abrahamsson wrote
On Fri, 2019-04-26 at 00:07 +0200, Kristian Larsson wrote:
>
> On 2019-04-25 23:51, Juergen Schoenwaelder wrote:
> > On Thu, Apr 25, 2019 at 11:20:57PM +0200, Kristian Larsson wrote:
> > >
> > > On 2019-04-18 13:12, Juergen Schoenwaelder wrote:
> > > > On Thu, Apr 18, 2019 at 12:53:22PM +0200, Mi
On Thu, 2019-04-25 at 23:51 +0200, Juergen Schoenwaelder wrote:
> On Thu, Apr 25, 2019 at 11:20:57PM +0200, Kristian Larsson wrote:
> >
> > On 2019-04-18 13:12, Juergen Schoenwaelder wrote:
> > > On Thu, Apr 18, 2019 at 12:53:22PM +0200, Mikael Abrahamsson wrote:
> > > > On Thu, 18 Apr 2019, Juerg
+1
Cheers,
Jeff
> On Apr 18, 2019, at 6:12 AM, Lou Berger wrote:
>
> Having worked with UIs that have the behavior of accepting an
> address/prefix-len and mapping it to a prefix, (i.e., network/prefix-len and
> zeroing out the non-significant bits) - some users really like it as they
> don
On 2019-04-25 23:51, Juergen Schoenwaelder wrote:
On Thu, Apr 25, 2019 at 11:20:57PM +0200, Kristian Larsson wrote:
On 2019-04-18 13:12, Juergen Schoenwaelder wrote:
On Thu, Apr 18, 2019 at 12:53:22PM +0200, Mikael Abrahamsson wrote:
On Thu, 18 Apr 2019, Juergen Schoenwaelder wrote:
On T
On Thu, Apr 25, 2019 at 11:20:57PM +0200, Kristian Larsson wrote:
>
>
> On 2019-04-18 13:12, Juergen Schoenwaelder wrote:
> > On Thu, Apr 18, 2019 at 12:53:22PM +0200, Mikael Abrahamsson wrote:
> > > On Thu, 18 Apr 2019, Juergen Schoenwaelder wrote:
> > > > On Thu, Apr 18, 2019 at 11:43:05AM +020
On 2019-04-18 13:12, Juergen Schoenwaelder wrote:
On Thu, Apr 18, 2019 at 12:53:22PM +0200, Mikael Abrahamsson wrote:
On Thu, 18 Apr 2019, Juergen Schoenwaelder wrote:
On Thu, Apr 18, 2019 at 11:43:05AM +0200, Mikael Abrahamsson wrote:
+17.4 is not an integer, so this is an error (not becaus
+1
It also would be nice if we could loosen the YANG migration rules so we could
change leaves from ipv4-prefix to ipv4-address-and-length (or whatever we
decide to call it) to handle the cases where the former has been used
incorrectly. However, this is a separate issue.
Acee
On 4/18/19,
On Thu, 18 Apr 2019 at 09:10, Acee Lindem (acee) wrote:
> Since the constraint on the non-masked portion of the prefix is solely in
> the description, there is nothing to prevent this and I'm sure the
> ipv4-prefix and ipv6-prefix types are being used incorrectly.
>
Is a requirement in a descrip
Having worked with UIs that have the behavior of accepting an
address/prefix-len and mapping it to a prefix, (i.e., network/prefix-len
and zeroing out the non-significant bits) - some users really like it
as they don't have to do the transformation from address to network,
notably for odd leng
On Thu, Apr 18, 2019 at 12:53:22PM +0200, Mikael Abrahamsson wrote:
> On Thu, 18 Apr 2019, Juergen Schoenwaelder wrote:
>
> > On Thu, Apr 18, 2019 at 11:43:05AM +0200, Mikael Abrahamsson wrote:
> >
> > > 2001:db8::/64 and 2001:db8::1/64 are NOT the same if you use them.
> >
> > Why are they not
On Thu, 18 Apr 2019, Juergen Schoenwaelder wrote:
On Thu, Apr 18, 2019 at 11:43:05AM +0200, Mikael Abrahamsson wrote:
2001:db8::/64 and 2001:db8::1/64 are NOT the same if you use them.
Why are they not the same if you define a prefix?
Because they're not. One of them is a valid prefix, the
On Thu, Apr 18, 2019 at 11:43:05AM +0200, Mikael Abrahamsson wrote:
> 2001:db8::/64 and 2001:db8::1/64 are NOT the same if you use them.
Why are they not the same if you define a prefix?
> https://tools.ietf.org/html/rfc6020#section-9.1
>
> " For most types, there is a single canonical repr
On Thu, 18 Apr 2019, Juergen Schoenwaelder wrote:
The values 2001:db8::1/64 and 2001:db8::/64 are both legal inputs but
they result in the same value. In situations where multiple inputs
resolve to the same value, we define a canonical representation. And
in the case of ipv6-prefix, the canonica
Hi Mikael,
On 4/18/19, 3:17 AM, "netmod on behalf of Mikael Abrahamsson"
wrote:
On Tue, 16 Apr 2019, 7ri...@gmail.com wrote:
> We might need to clarify this with the libyang folk.
I see that Michal fixed the bug in libyang. Good.
There is another thing I am unsur
On Thu, Apr 18, 2019 at 09:16:15AM +0200, Mikael Abrahamsson wrote:
> On Tue, 16 Apr 2019, 7ri...@gmail.com wrote:
>
> > We might need to clarify this with the libyang folk.
>
> I see that Michal fixed the bug in libyang. Good.
>
> There is another thing I am unsure about.
>
> What is the netco
On Tue, 16 Apr 2019, 7ri...@gmail.com wrote:
We might need to clarify this with the libyang folk.
I see that Michal fixed the bug in libyang. Good.
There is another thing I am unsure about.
What is the netconf server supposed to do if a client tries to store
192.168.1.1/24 in ipv4-prefix ?
Y'all --
It looks like the text in 6021 around the ipv4-prefix is being... mis-read?
https://github.com/CESNET/libyang/issues/755
The libyang folk seem to be taking the prefix as the mask, rather than the
prefix here? Canonizing should mean replacing anything in the host bits with
0's, so onl
67 matches
Mail list logo
