subject:"\[netmod\] 6021 ipv4\-prefix"

Re: [netmod] 6021 ipv4-prefix

2019-05-03 Thread Ladislav Lhotka

"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-prefix
>> 
>> 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 and store the value in the canonical format?
>> >>
>> >> Such text would be an inappropriate constraint the server's internal
>> >> representation.  We should only specify the externally-visible
>> >> behaviour: that the reported value will be in the canonical format.
>> >> Whether an implementation preserves extraneous cruft in its internal
>> >> representation is purely an implementation decision, and not subject
>> >> to standardization.
>> >
>> > I am talking about what goes on the wire. If the client does an
>> > edit-config with ipv6-prefix 2001:db8::1/64, should the server convert
>> > this into 2001:db8::/64 or throw an error on the edit-config operation.
>> >
>> > Jurgen seems to say it should convert it and not throw an error, and
>> > I'd like text to say that indeed, this is proper behaviour. Nobody has
>> > so far been able to tell me where this text currently is, so that's
>> > why I'm
>> 
>> If we agree that a type defines the set of legal on-the-wire values (possibly
>> modulo representation - JSON/XML/...), then section 4.2.2.1 in RFC 7950 says:
>> 
>> [A leaf instance] has exactly one value of a particular type ...
>> 
>> So why should a server throw an error if this is satisfied?
>
> I don't think that there is text for a derived type that defines a canonical 
> representation that:
> (i) The server must internally treat the data as if it were in the canonical 
> form
> (ii) If the data is returned then it must be in the canonical form.

The text is in subsection 9.1, which really should have been outside
sec. 9 (Built-In Types), and applicable to derived types as well. 

But anyway, Mikael wrote about the case when the client sends a value
(specifically, belonging to the ipv6-prefix type) that is NOT in the
canonical format.

Lada

>
> We should fix this in YANG 1.2 so this is clearer, but YANG 1.2 isn't going 
> to be here for a while.  I don't think that we can do this as an erratum, but 
> perhaps the 6991bis could, for each type state that the it is handled 
> equivalently to RFC 7950 section 9.1.  Or would that just end up being noise?
>
> Thanks,
> Rob
>

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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-05-02 Thread Rob Wilton (rwilton)




> -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 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 text would be an inappropriate constraint the server's internal
> >> representation.  We should only specify the externally-visible
> >> behaviour: that the reported value will be in the canonical format.
> >> Whether an implementation preserves extraneous cruft in its internal
> >> representation is purely an implementation decision, and not subject
> >> to standardization.
> >
> > I am talking about what goes on the wire. If the client does an
> > edit-config with ipv6-prefix 2001:db8::1/64, should the server convert
> > this into 2001:db8::/64 or throw an error on the edit-config operation.
> >
> > Jurgen seems to say it should convert it and not throw an error, and
> > I'd like text to say that indeed, this is proper behaviour. Nobody has
> > so far been able to tell me where this text currently is, so that's
> > why I'm
> 
> If we agree that a type defines the set of legal on-the-wire values (possibly
> modulo representation - JSON/XML/...), then section 4.2.2.1 in RFC 7950 says:
> 
> [A leaf instance] has exactly one value of a particular type ...
> 
> So why should a server throw an error if this is satisfied?

I don't think that there is text for a derived type that defines a canonical 
representation that:
(i) The server must internally treat the data as if it were in the canonical 
form
(ii) If the data is returned then it must be in the canonical form.

We should fix this in YANG 1.2 so this is clearer, but YANG 1.2 isn't going to 
be here for a while.  I don't think that we can do this as an erratum, but 
perhaps the 6991bis could, for each type state that the it is handled 
equivalently to RFC 7950 section 9.1.  Or would that just end up being noise?

Thanks,
Rob

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-05-02 Thread Ladislav Lhotka

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
>>> and store the value in the canonical format?
>>
>> Such text would be an inappropriate constraint the server's
>> internal representation.  We should only specify
>> the externally-visible behaviour: that the reported value
>> will be in the canonical format.  Whether an implementation
>> preserves extraneous cruft in its internal representation is
>> purely an implementation decision, and not subject to standardization.
>
> I am talking about what goes on the wire. If the client does an 
> edit-config with ipv6-prefix 2001:db8::1/64, should the server convert 
> this into 2001:db8::/64 or throw an error on the edit-config operation.
>
> Jurgen seems to say it should convert it and not throw an error, and I'd 
> like text to say that indeed, this is proper behaviour. Nobody has so far 
> been able to tell me where this text currently is, so that's why I'm

If we agree that a type defines the set of legal on-the-wire values
(possibly modulo representation - JSON/XML/...), then section 4.2.2.1 in
RFC 7950 says:

[A leaf instance] has exactly one value of a particular type ...

So why should a server throw an error if this is satisfied?

Lada

> asking for it to be added. Either this should go into an update to 
> https://tools.ietf.org/html/rfc7950#section-9.1 or it should go into each 
> and every definition of types (or both of them).
>
>>> It seems it should "fix it", so we should
>>> have text that reflects this.
>>
>> False dichotomy.  An implementation might actually preserve
>> those bits, though of course they'd never be seen again (at
>> least not on a netconf interface) since the netconf server
>> will always behave as though the value were in its canonical
>> form, regardless of the internal representation.
>
> Again, I am talking about what goes on the wire, what is seen when issuing 
> "get" or "edit-config" etc.
>
> -- 
> Mikael Abrahamssonemail: swm...@swm.pp.se
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-05-02 Thread Mikael Abrahamsson


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 text would be an inappropriate constraint the server's
internal representation.  We should only specify
the externally-visible behaviour: that the reported value
will be in the canonical format.  Whether an implementation
preserves extraneous cruft in its internal representation is
purely an implementation decision, and not subject to standardization.


I am talking about what goes on the wire. If the client does an 
edit-config with ipv6-prefix 2001:db8::1/64, should the server convert 
this into 2001:db8::/64 or throw an error on the edit-config operation.


Jurgen seems to say it should convert it and not throw an error, and I'd 
like text to say that indeed, this is proper behaviour. Nobody has so far 
been able to tell me where this text currently is, so that's why I'm 
asking for it to be added. Either this should go into an update to 
https://tools.ietf.org/html/rfc7950#section-9.1 or it should go into each 
and every definition of types (or both of them).



It seems it should "fix it", so we should
have text that reflects this.


False dichotomy.  An implementation might actually preserve
those bits, though of course they'd never be seen again (at
least not on a netconf interface) since the netconf server
will always behave as though the value were in its canonical
form, regardless of the internal representation.


Again, I am talking about what goes on the wire, what is seen when issuing 
"get" or "edit-config" etc.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-05-02 Thread tom petch

- 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're not responding to the
points I
> > am trying to make anyway.
> >
> > https://tools.ietf.org/html/rfc7950#section-9.1
> >
> > This talks about *values*. If you drop bits in IPv6-prefix, then
it's not
> > the same *value* anymore.
>
> 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 and 192.168.0.0/24 are different
> prefixes since bits that are irrelevant do differ.
>
> Apparently there are different views that people have concerning
> prefixes. I think I have seen the following three alternatives:
>
> a) non-prefix bits that are set to one are illegal in a prefix
> b) non-prefix bits are irrelevant but they need to be preserved
> c) non-prefix bits are irrelevant, ignore them and the canonical
>representation has non-prefix bits set to zero
>
> The RFC 6991 definitions do c). If there is consensus that c) is
> wrong, we need to deprecate the definitions and create new ones after
> finding consensus on either b) or a).

And I think that c) is the correct answer (and would be for those not
involved in netmod but who have experience of the IETF - did I hear 'be
liberal in what you accept'?)

I have worked with systems that made every effort to find a reason not
to accept something that had been input, and I have worked with systems
that bend over backwards to accept something a bit flaky; different
developers have different cultures but I have always found the culture
of the IETF to be very clear on this point.  Mac, Linux and Windows have
different cultures.

There is a caveat and it is that the context must be clear.  Randy cited
' ... 1234567.89 and if it
subsequently chooses to display it as "1.234.567,89 USD" '
Well, where he is, may be, but not here where it could be

1.234.567,89 Euro
1,234,567.89 Euro
123456789 Yen
or ...
depending on the locale.

Going back to
192.168.0.1/24
then the meaning is clear as long as it is unambiguous that it is a
prefix and not more; as has been commented on (a lot of messages ago),
this could be a compound object, specifying
address+ mask
address + prefix + prefix length
etc
so it matters that the context is clear, both for the object instance
and for the organisation doing the specification.

Tom Petch

> System/kernel interfaces seem to show different behaviours. My Linux
> box seems to do a), my MacOS box seems to do c). The system/kernel
> interfaces likely all do the same if all non-prefix bits are zero,
> i.e., when the system receives data in the canonical format.
>
> Option b) seems to be the most expensive to implement (your server may
> have to clear non-prefix bits before pushing the prefix into the
> kernel and it needs to map data received from the kernel back to a
> prefix that has unused bits preserved in the datastore). Hence, for me
> the choice is between a) and c) and given that we have c) already
> defined for years, my first preference is to just keep things as they
> are.
>
> /js
>
> --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-05-01 Thread Randy Presuhn


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 the server's
internal representation.  We should only specify
the externally-visible behaviour: that the reported value
will be in the canonical format.  Whether an implementation
preserves extraneous cruft in its internal representation is
purely an implementation decision, and not subject to standardization.


(Even for the case of simple signed integers, it depends on my internal
number representation whether normalizing +7 to 7 causes a change of
the internal representation or not.)


I think this example is not relevant to this discussion. +7 and 7
doesn't change any integer backend representation. It's the same value.


You don't know whether it does or does not affect the internal
representation used by the backend.  If the backend is a textual
configuration file virtualized through netconf, the "+" might
very well be preserved in the file, even though it would disappear
in response to a query.  We only know that for purposes
of the protocol's operation, the server needs to behave as though
it is in the canonical form.


Again, I have no problem with the server throwing away the bits at
commit time, I just want it to be clear from the specs that this is the
correct behaviour and what the server should do when the above text is
not true:

"The IPv6 address should have all bits that do not belong
   to the prefix set to zero."

Throw an error or "fix it"?


Since the language is "should" an error seems inappropriate.


It seems it should "fix it", so we should
have text that reflects this.


False dichotomy.  An implementation might actually preserve
those bits, though of course they'd never be seen again (at
least not on a netconf interface) since the netconf server
will always behave as though the value were in its canonical
form, regardless of the internal representation.


I have no idea where this text should go,
though.


I agree with the earlier sentiment that anything addressing
this really belongs in whatever further clarification of
canonicalization goes into the update.

Randy

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-05-01 Thread Mikael Abrahamsson


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



(Even for the case of simple signed integers, it depends on my internal
number representation whether normalizing +7 to 7 causes a change of
the internal representation or not.)


I think this example is not relevant to this discussion. +7 and 7 doesn't 
change any integer backend representation. It's the same value.


Again, I have no problem with the server throwing away the bits at commit 
time, I just want it to be clear from the specs that this is the correct 
behaviour and what the server should do when the above text is not true:


"The IPv6 address should have all bits that do not belong
  to the prefix set to zero."

Throw an error or "fix it"? It seems it should "fix it", so we should have 
text that reflects this. I have no idea where this text should go, though.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-05-01 Thread Rob Wilton (rwilton)

> -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:
> >
> > 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 properly (at least I haven't seen text that makes me
> > clearly understand the expected behaviour). I think the text
> > specifying what "canonical format is" referring to "same *value*" is
> > wrong. +17 and 17 is the same integer, 192.168.0.1/24 and
> > 192.168.0.0/24 are not the same *value*. It's misleading to refer to
> > the canonical form having the *same* *value* when we're throwing away
> information.
> >
> 
> 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.

[To frame this comment, I don't object to your currently proposed solution]

I consider the extra bits after the valid part of the prefix to be unwanted 
noise.

For me, one hypothetical question I have is whether the potential convenience 
of allowing 192.168.0.1/24 (for some use cases) outweighs the risk that the 
wrong value has been provided but cannot be checked (e.g. 192.168.0.1/2).

Similarly, if you consider strings with a max length, I would expect a server 
to reject a configured string that was too long rather that treat the excessive 
characters as noise and silently truncate the input.

If it was down to me, and I was defining this now, then I would choose the 
stricter input (as per the should currently in the ipv6-prefix definition).  
But no longer care if the consensus is in the other direction.

Whichever way we change the definitions, I believe that they are being changed 
in a non-backwards-compatible way that will impact some clients or server 
implementations.

Thanks,
Rob

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-05-01 Thread Juergen Schoenwaelder

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 properly
> (at least I haven't seen text that makes me clearly understand the expected
> behaviour). I think the text specifying what "canonical format is" referring
> to "same *value*" is wrong. +17 and 17 is the same integer, 192.168.0.1/24
> and 192.168.0.0/24 are not the same *value*. It's misleading to refer to the
> canonical form having the *same* *value* when we're throwing away
> information.
>

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.

> If you write 2001:db8:0:1 as 2001:db8::1 then you're compressing the text
> form without throwing away actual information. It's the *same value* buth
> *different text representation*. 2001:db8::/64 and 2001:db8::1/64 is *not
> the same value*.

With your definition of 'value' it is not the same, with my definition
of 'value' it is the same.

For me, the value space of the ipv6-prefix type is the set of all
possible ipv6-prefixes. And with this, 2001:db8::/64 and
2001:db8::1/64 are two different textual representations that resolve
to the same prefix, i.e., the same value in the value space. I would
go even further and make the following distinction between

- textual representations of values of a type
- the value space of a type
- internal representations of values of a type

I think we have this discussion because you likely map the textual
representations of a prefix into an internal representation that can
capture details that are (in my model) not relevant for the value
space itself.

(Even for the case of simple signed integers, it depends on my internal
number representation whether normalizing +7 to 7 causes a change of
the internal representation or not.)

Once we add support to YANG for binary encodings, we will get
additional complexity since we will map the value space to multiple
'external' representations and for the same type (=value space), there
may be differences how 'external' representations map to the value
space. A binary representation of an IPv6 address may have a 1:1
mapping to the value space while our textual representation already
has a n:1 relationship. Or we go into the direction to require that
all 'external' representations must only have 1:1 relationships, i.e.,
only textual representations in canonical format will be legal. We
will see...

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-05-01 Thread Rob Wilton (rwilton)

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:
> 
> > 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 and 192.168.0.0/24 are different
> > prefixes since bits that are irrelevant do differ.
> 
> No, I am saying this is underspecified or actually wrongly specified in the 
> current
> documents + proposed text regarding what canonical format is and isn't, and
> how the server and clients handle this.
> 
> I am fine with the current proposed text to specify this for ipv6-prefix, but 
> I am
> also pointing out that I think when YANG 1.2 is specced, the definition for
> "canonical format" needs more/changed text.

I think that it is quite likely that this will get fixed in YANG 1.2.

It is being tracked as a potential issue for YANG 1.2 here, 
https://github.com/netmod-wg/yang-next/issues/83, which means that this issue 
should at least be discussed/considered for the next version of YANG.

If there are particular points of clarification that you think are 
important/required then adding them as comments to that github issue would be 
helpful.

Thanks,
Rob

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-05-01 Thread Mikael Abrahamsson


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 and 192.168.0.0/24 are different
prefixes since bits that are irrelevant do differ.


No, I am saying this is underspecified or actually wrongly specified in 
the current documents + proposed text regarding what canonical format is 
and isn't, and how the server and clients handle this.


I am fine with the current proposed text to specify this for ipv6-prefix, 
but I am also pointing out that I think when YANG 1.2 is specced, the 
definition for "canonical format" needs more/changed text.



Apparently there are different views that people have concerning
prefixes. I think I have seen the following three alternatives:

a) non-prefix bits that are set to one are illegal in a prefix
b) non-prefix bits are irrelevant but they need to be preserved
c) non-prefix bits are irrelevant, ignore them and the canonical
  representation has non-prefix bits set to zero

The RFC 6991 definitions do c). If there is consensus that c) is
wrong, we need to deprecate the definitions and create new ones after
finding consensus on either b) or a).


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 
properly (at least I haven't seen text that makes me clearly understand 
the expected behaviour). I think the text specifying what "canonical 
format is" referring to "same *value*" is wrong. +17 and 17 is the same 
integer, 192.168.0.1/24 and 192.168.0.0/24 are not the same *value*. It's 
misleading to refer to the canonical form having the *same* *value* when 
we're throwing away information.


If you write 2001:db8:0:1 as 2001:db8::1 then you're compressing the text 
form without throwing away actual information. It's the *same value* buth 
*different text representation*. 2001:db8::/64 and 2001:db8::1/64 is *not 
the same value*.


I am fine with us continuing with c) above, I have long stopped arguing 
for anything else. What I am though saying is that I want 
https://tools.ietf.org/html/rfc7950#section-9.1 (or elsewhere) to have 
better text on this matter when the documents are revved next time.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-05-01 Thread Juergen Schoenwaelder

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#section-9.1
> 
> This talks about *values*. If you drop bits in IPv6-prefix, then it's not
> the same *value* anymore.

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 and 192.168.0.0/24 are different
prefixes since bits that are irrelevant do differ.

Apparently there are different views that people have concerning
prefixes. I think I have seen the following three alternatives:

a) non-prefix bits that are set to one are illegal in a prefix
b) non-prefix bits are irrelevant but they need to be preserved
c) non-prefix bits are irrelevant, ignore them and the canonical
   representation has non-prefix bits set to zero

The RFC 6991 definitions do c). If there is consensus that c) is
wrong, we need to deprecate the definitions and create new ones after
finding consensus on either b) or a).

System/kernel interfaces seem to show different behaviours. My Linux
box seems to do a), my MacOS box seems to do c). The system/kernel
interfaces likely all do the same if all non-prefix bits are zero,
i.e., when the system receives data in the canonical format.

Option b) seems to be the most expensive to implement (your server may
have to clear non-prefix bits before pushing the prefix into the
kernel and it needs to map data received from the kernel back to a
prefix that has unused bits preserved in the datastore). Hence, for me
the choice is between a) and c) and given that we have c) already
defined for years, my first preference is to just keep things as they
are.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-05-01 Thread Mikael Abrahamsson


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
to represent that value may be different.  Some information sent


No. 2001:db8::/64 and 2001:db8::1/64 isn't the same *value*. These are not 
the same bits set.



by the client may be extraneous to the *value*.  Consider the case
of currency values entered into some application.  A robust application
won't care whether I enter $1,234,567.89 or 1234567.89 and if it
subsequently chooses to display it as "1.234.567,89 USD" I can't
complain that the value is different, even though several bytes of
my input have clearly been discarded.


That's a completely different example. In your example the value is the 
same, in mine (ipv6-prefix) it isn't.


This situation is hardly unique to netconf. I recall coding for such 
situations forty years ago.  It has been a fact of life throughout the 
history of ASN.1 and especially BER. It will continue to be a 
consideration at least as long as folks feel the need to support "human 
readable" representations on input.  Frankly, I was surprised that 
anyone was surprised by this.


I have no problem understanding the canonicalization of IPv6 address, 
because the underlying value doesn't change by canonicalizating it. This 
is not the case with canonicalizating IPv6-prefix, where the resulting 128 
bit field *changes* when you canonicalize it.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-05-01 Thread Mikael Abrahamsson


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 revision
and if anything remains unclear, people can send concrete edit
proposals.


You don't have to explain it. Let me try in a different way.

https://tools.ietf.org/html/rfc7950#section-9.1

"For most types, there is a single canonical representation of the
   type's values."

Is it generally ok that the canonical value potentially represents a
different bit field/value than what the client sent?


Yes. I explained that the canonicalization of IPv6 addresses is much
more involved than clearing some unused bits in an IPv6 prefix.


The canonicalization of IPv6 addresses doesn't change the resulting 128 
bit pattern. Canonicalization of IPv6-prefix *does* change the bit 
pattern. Also, it doesn't say in 
https://tools.ietf.org/html/rfc7950#section-9.1 whether the server should 
accept bit-fields that do not adhere to the canonical representation or 
not.


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#section-9.1

This talks about *values*. If you drop bits in IPv6-prefix, then it's not 
the same *value* anymore.


So https://tools.ietf.org/html/rfc7950#section-9.1 should be changed 
in future revisions to avoid confusion.



We are not 'fixing' anything. The canonical format is nothing new. The
text aims at explaining things better. Yes, there are many more types
that have a canonical representation. Read the other email messages in
this thread or simply search for 'canonical' in the type definitions.

I think the descriptions are actually all quite clear (but then I am
biased of course).


There are lots of implications that are *not* clear in 
https://tools.ietf.org/html/rfc7950#section-9.1.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-04-30 Thread Randy Presuhn


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.  Some information sent
by the client may be extraneous to the *value*.  Consider the case
of currency values entered into some application.  A robust application
won't care whether I enter $1,234,567.89 or 1234567.89 and if it
subsequently chooses to display it as "1.234.567,89 USD" I can't
complain that the value is different, even though several bytes of
my input have clearly been discarded.

This situation is hardly unique to netconf. I recall coding
for such situations forty years ago.  It has been a fact of life
throughout the history of ASN.1 and especially BER. It will continue
to be a consideration at least as long as folks feel the need to
support "human readable" representations on input.  Frankly,
I was surprised that anyone was surprised by this.

Randy

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-04-30 Thread Juergen Schoenwaelder

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 unclear, people can send concrete edit
> > proposals.
> 
> You don't have to explain it. Let me try in a different way.
> 
> https://tools.ietf.org/html/rfc7950#section-9.1
> 
> "For most types, there is a single canonical representation of the
>type's values."
> 
> Is it generally ok that the canonical value potentially represents a
> different bit field/value than what the client sent?

Yes. I explained that the canonicalization of IPv6 addresses is much
more involved than clearing some unused bits in an IPv6 prefix.

> If it is (and that's fine by me), I think this should be made more clear in
> the next rev of the YANG specification. I feel the whole "canonical/lexical
> format" concept is underspecified, for instance in the case of ipv6-prefix.

There is text defining the canonical format since day one. I proposed
an addition that hopefully makes this even clearer.

> In the text you suggested before that fixes ipv6-prefix. Do we have more
> types where this needs to be fixed?

We are not 'fixing' anything. The canonical format is nothing new. The
text aims at explaining things better. Yes, there are many more types
that have a canonical representation. Read the other email messages in
this thread or simply search for 'canonical' in the type definitions.

I think the descriptions are actually all quite clear (but then I am
biased of course).

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-04-30 Thread Mikael Abrahamsson


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 try in a different way.

https://tools.ietf.org/html/rfc7950#section-9.1

"For most types, there is a single canonical representation of the
   type's values."

Is it generally ok that the canonical value potentially represents a 
different bit field/value than what the client sent?


If it is (and that's fine by me), I think this should be made more clear 
in the next rev of the YANG specification. I feel the whole 
"canonical/lexical format" concept is underspecified, for instance in the 
case of ipv6-prefix. In the text you suggested before that fixes 
ipv6-prefix. Do we have more types where this needs to be fixed?


--
Mikael Abrahamssonemail: swm...@swm.pp.se

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-04-29 Thread Juergen Schoenwaelder

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 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; it might be convenient for me to be
> > allowed to push 2001:0DB8:0:0:0:0:0:0/64 and not having to worry about
> > how to produce the RFC 5952 representation in my glue code that ties
> > into my database backend. Why would we say clients should not send
> > values in non-canonical format? Why would we say clients have to take
> > the pain to ensure everything is turned into 2001:db8::/64 (to continue
> > the example) before sending values to the server?
> > 
> > Note that the ipv6-address definition has the same canonicalization
> > properties (if we consider the address portion of ipv6-prefix) and
> > there is no text saying you should send 2001:db8::1 instead of
> > 2001:0DB8::1.
> 
> 2001:0DB8::1 and 2001:db8::1 represent the same thing in the end.
> 2001:db8::/64 and 2001:db8::1/64 is not the same thing in the end.
> 
> The fact that the server accepts 2001:db8::1/64 and turns it into
> 2001:db8::/64 is something I believe should be explicitly stated. It's not
> obvious from neither the description of what a "canonical format" is in the
> YANG spec whether this also applies to dropping actual representation.
> 
> A contrived example is if I specify a canonical format for a string that is
> [a-f] and I sent it "abcdefghij" then the server just accepts this and turns
> it into "abcdef"? That's basically what's happening above. A lot of people
> would be astonished by this behaviour, and I think this should be more
> explicit when this is happening. From what we're seeing now from different
> implementations doing differently, this is not obvious.
> 
> > I think our mission instead is to make it clear what the canonical
> > format is and that servers will turn lexical representations they accept
> > into canonical lexical representation. This way people can take informed
> > decisions about what is appropriate for their specific clients.
> 
> The ipv6-prefix type doesn't have a lexical definition. An integer has
> lexical definition. Does this mean everything should have both just to make
> sure everything is clear? And should a server disallow input that doesn't
> adhere to the lexical format?
> 
> I just want it to be 100% clear from reading about what lexical and
> canonical format is what the server should and shouldn't do in each case.
> 
> I still think there is a difference between representation of the underlying
> information being changed or not. For instance, DNS domain names are case
> insensitive. Turning input into lower case (canonical format) is fine, this
> changes nothing operationally. Accepting client edit-config and just
> removing ASCII characters can cause unexpected and baffling behavior.
> 
> I still believe that if a client does edit-config on a DNS domain and
> include for instance a "%" in the name then the server should throw an
> error. So same thing with the ipv6-prefix, it needs to be defined whether
> the server should accept (and zero) host bits or not.
> 
> Do we have other types with this kind of ambiguity?
> 
> -- 
> Mikael Abrahamssonemail: swm...@swm.pp.se

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-04-29 Thread Mikael Abrahamsson


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; it might be convenient for me to be 
allowed to push 2001:0DB8:0:0:0:0:0:0/64 and not having to worry about 
how to produce the RFC 5952 representation in my glue code that ties 
into my database backend. Why would we say clients should not send 
values in non-canonical format? Why would we say clients have to take 
the pain to ensure everything is turned into 2001:db8::/64 (to continue 
the example) before sending values to the server?


Note that the ipv6-address definition has the same canonicalization
properties (if we consider the address portion of ipv6-prefix) and
there is no text saying you should send 2001:db8::1 instead of
2001:0DB8::1.


2001:0DB8::1 and 2001:db8::1 represent the same thing in the end. 
2001:db8::/64 and 2001:db8::1/64 is not the same thing in the end.


The fact that the server accepts 2001:db8::1/64 and turns it into 
2001:db8::/64 is something I believe should be explicitly stated. It's not 
obvious from neither the description of what a "canonical format" is in 
the YANG spec whether this also applies to dropping actual representation.


A contrived example is if I specify a canonical format for a string that 
is [a-f] and I sent it "abcdefghij" then the server just accepts this and 
turns it into "abcdef"? That's basically what's happening above. A lot of 
people would be astonished by this behaviour, and I think this should be 
more explicit when this is happening. From what we're seeing now from 
different implementations doing differently, this is not obvious.


I think our mission instead is to make it clear what the canonical 
format is and that servers will turn lexical representations they accept 
into canonical lexical representation. This way people can take informed 
decisions about what is appropriate for their specific clients.


The ipv6-prefix type doesn't have a lexical definition. An integer has 
lexical definition. Does this mean everything should have both just to 
make sure everything is clear? And should a server disallow input that 
doesn't adhere to the lexical format?


I just want it to be 100% clear from reading about what lexical and 
canonical format is what the server should and shouldn't do in each case.


I still think there is a difference between representation of the 
underlying information being changed or not. For instance, DNS domain 
names are case insensitive. Turning input into lower case (canonical 
format) is fine, this changes nothing operationally. Accepting client 
edit-config and just removing ASCII characters can cause unexpected and 
baffling behavior.


I still believe that if a client does edit-config on a DNS domain and 
include for instance a "%" in the name then the server should throw an 
error. So same thing with the ipv6-prefix, it needs to be defined whether 
the server should accept (and zero) host bits or not.


Do we have other types with this kind of ambiguity?

--
Mikael Abrahamssonemail: swm...@swm.pp.se

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-04-29 Thread Juergen Schoenwaelder

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 read/understand the description associated with a
> leaf/typedef in case they have to add specific canonicalization code
> to implement the leaf/typedef.

Description statements in general are expected to be read and
understood and implemented where necessary. But I now see that the
fact that this section 9.1 is under section 9 which is titled built-in
types is causing the confusion. This is, indeed, unfortunate.

> I'm not sure that we have really got a simple solution for either clients or 
> servers:
>  1) Clients may use non canonical format on configuration input
>  2) But clients must still use canonical format for xpath expressions
>  3) Clients must also handle canonical format being returned on any get 
> requests.
>  4) Servers must perform normalization of any type to a canonical format, as 
> defined in the type/typedef/leaf description.

Exactly. Note that clients only send xpath for filtering (if they want
to filter via xpath). What is more important is that module authors
can predict the format of values when they write when or must
expressions. And as Lada points out, having predictable key values
also is kind of desirable.

The reality is that there are many different ways to write an IPv6
address and the idea was to accept them on input but to subsequently
work with the normalized canonical representation. And this is in
ietf-yang-types and ietf-inet-types since day one. But yes, the
text in section 9.1 seems to be misplaced.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-04-29 Thread Ladislav Lhotka

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
> > 
> > On Mon, 2019-04-29 at 15:32 +, Rob Wilton (rwilton) wrote:
> > > BTW, did you mean to drop the alias?
> > 
> > No, my frequent mistake. :-( Putting it back, please see below.
> > 
> > > > -Original Message-
> > > > From: Ladislav Lhotka 
> > > > Sent: 29 April 2019 16:15
> > > > 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 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 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)
> > > > > > > > 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 definition?
> > > > > > > > > Or is a significant part of your proposal/reasoning to
> > > > > > > > > ensure backwards
> > > > > > > > compatibility with what we have today?
> > > > > > > > 
> > > > > > > > I am trying to clarify what the existing definition says
> > > > > > > > since there apparently have been different interpretations.
> > > > > > > 
> > > > > > > Given the definition of ipv6-prefix already contains:
> > > > > > > 
> > > > > > >   " The IPv6 address should have all bits that do not belong
> > > > > > >to the prefix set to zero."
> > > > > > > 
> > > > > > > I think that a better solution might be to add the equivalent
> > > > > > > text to the ipv4-prefix definition:
> > > > > > > 
> > > > > > >   " The IPv4 address should have all bits that do not belong
> > > > > > >to the prefix set to zero."
> > > > > > 
> > > > > > But this still essentially permits the client to send a value
> > > > > > with those bits set, and the server has to be prepared to handle it.
> > > > > 
> > > > > My aim with this text is to:
> > > > >  - encourage clients to use canonical format, since that seems to
> > > > > cause the least problems.
> > > > 
> > > > It would be good to clarify the implications of sending
> > > > non-canonical values, and perhaps give recommendations, but not in
> > > > the description of a particular derived type. I guess it also
> > > > depends on the character of the client - a curl script cannot be
> > > > expected to perform extensive normalization.
> > > 
> > > I think, for ipv4-prefix, that an existing server could reasonably do
> > > any of the following:
> > >  - accept non canonical values and convert them to the canonical
> > > format internally, or just reject non canonical values
> > >  - return the canonical value o

Re: [netmod] 6021 ipv4-prefix

2019-04-29 Thread Rob Wilton (rwilton)

> -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:
> >
> >
> > 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
> >
> >The canonical form is the same as the lexical representation.  No
> >Unicode normalization of string values is performed.
> >
> > Section "9.1.  Canonical Representation" does not state that the canonical
> format of a type may be overridden by a description statement.
> >
> 
> Section 9.1 talks about 'types' - the text does not indicate that this is 
> restricted
> to built-in types.

The whole of section 9 is for "Built-In-Types" and doesn't cover the typedef 
statement.  In fact, it states "When a server sends XML-encoded data, it MUST 
use the canonical form defined in this section."

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 read/understand 
the description associated with a leaf/typedef in case they have to add 
specific canonicalization code to implement the leaf/typedef.

> 
> We are defining canonical formats of typedefs since RFC 6021, which was
> published together with the first version of YANG (RFC 6020). Are you telling 
> us
> that we got this all wrong?

I'm not sure that we have really got a simple solution for either clients or 
servers:
 1) Clients may use non canonical format on configuration input
 2) But clients must still use canonical format for xpath expressions
 3) Clients must also handle canonical format being returned on any get 
requests.
 4) Servers must perform normalization of any type to a canonical format, as 
defined in the type/typedef/leaf description.

Possibly having a keyword in YANG to mark leaves/typedefs where the canonical 
definition refines the canonical type associated with the base type might have 
been helpful.

Thanks,
Rob

> 
> /js
> 
> --
> 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
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-04-29 Thread Juergen Schoenwaelder

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
> 
>The canonical form is the same as the lexical representation.  No
>Unicode normalization of string values is performed.
> 
> Section "9.1.  Canonical Representation" does not state that the canonical 
> format of a type may be overridden by a description statement.
>

Section 9.1 talks about 'types' - the text does not indicate that this
is restricted to built-in types.

We are defining canonical formats of typedefs since RFC 6021, which
was published together with the first version of YANG (RFC 6020). Are
you telling us that we got this all wrong? How do you test for say an
IPv6 address in an xpath expression if you cannot predict how it is
lexically represented?

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-04-29 Thread Rob Wilton (rwilton)




> -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 drop the alias?
> 
> No, my frequent mistake. :-( Putting it back, please see below.
> 
> >
> > > -Original Message-
> > > From: Ladislav Lhotka 
> > > Sent: 29 April 2019 16:15
> > > 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 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 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)
> > > > > > > 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 definition?
> > > > > > > > Or is a significant part of your proposal/reasoning to
> > > > > > > > ensure backwards
> > > > > > > compatibility with what we have today?
> > > > > > >
> > > > > > > I am trying to clarify what the existing definition says
> > > > > > > since there apparently have been different interpretations.
> > > > > >
> > > > > > Given the definition of ipv6-prefix already contains:
> > > > > >
> > > > > >   " The IPv6 address should have all bits that do not belong
> > > > > >to the prefix set to zero."
> > > > > >
> > > > > > I think that a better solution might be to add the equivalent
> > > > > > text to the ipv4-prefix definition:
> > > > > >
> > > > > >   " The IPv4 address should have all bits that do not belong
> > > > > >to the prefix set to zero."
> > > > >
> > > > > But this still essentially permits the client to send a value
> > > > > with those bits set, and the server has to be prepared to handle it.
> > > >
> > > > My aim with this text is to:
> > > >  - encourage clients to use canonical format, since that seems to
> > > > cause the least problems.
> > >
> > > It would be good to clarify the implications of sending
> > > non-canonical values, and perhaps give recommendations, but not in
> > > the description of a particular derived type. I guess it also
> > > depends on the character of the client - a curl script cannot be
> > > expected to perform extensive normalization.
> >
> > I think, for ipv4-prefix, that an existing server could reasonably do
> > any of the following:
> >  - accept non canonical values and convert them to the canonical
> > format internally, or just reject non canonical values
> >  - return the canonical value or return the exact value that was
> > configured by the client.
> >
> > RFC 7950 states that the canonical value is returned for native YANG
> > types.  It doesn't say anything about returning canonical values
> > defined in a
> 
> Hmm, my understanding so far has been that the rules for lexical/canonical
> values work the same for both built-in an derived types. It is true that these
> concepts are defined inside Section 9

Re: [netmod] 6021 ipv4-prefix

2019-04-29 Thread Ladislav Lhotka

On Mon, 2019-04-29 at 15:32 +, Rob Wilton (rwilton) wrote:
> BTW, did you mean to drop the alias?

No, my frequent mistake. :-( Putting it back, please see below.

> 
> > -Original Message-
> > From: Ladislav Lhotka 
> > Sent: 29 April 2019 16:15
> > 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 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 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)
> > > > > > 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 definition?
> > > > > > > Or is a significant part of your proposal/reasoning to ensure
> > > > > > > backwards
> > > > > > compatibility with what we have today?
> > > > > > 
> > > > > > I am trying to clarify what the existing definition says since
> > > > > > there apparently have been different interpretations.
> > > > > 
> > > > > Given the definition of ipv6-prefix already contains:
> > > > > 
> > > > >   " The IPv6 address should have all bits that do not belong
> > > > >to the prefix set to zero."
> > > > > 
> > > > > I think that a better solution might be to add the equivalent text
> > > > > to the ipv4-prefix definition:
> > > > > 
> > > > >   " The IPv4 address should have all bits that do not belong
> > > > >to the prefix set to zero."
> > > > 
> > > > But this still essentially permits the client to send a value with
> > > > those bits set, and the server has to be prepared to handle it.
> > > 
> > > My aim with this text is to:
> > >  - encourage clients to use canonical format, since that seems to
> > > cause the least problems.
> > 
> > It would be good to clarify the implications of sending non-canonical
> > values, and
> > perhaps give recommendations, but not in the description of a particular
> > derived
> > type. I guess it also depends on the character of the client - a curl script
> > cannot
> > be expected to perform extensive normalization.
> 
> I think, for ipv4-prefix, that an existing server could reasonably do any of
> the following:
>  - accept non canonical values and convert them to the canonical format
> internally, or just reject non canonical values
>  - return the canonical value or return the exact value that was configured by
> the client.
>  
> RFC 7950 states that the canonical value is returned for native YANG
> types.  It doesn't say anything about returning canonical values defined in a 

Hmm, my understanding so far has been that the rules for lexical/canonical
values work the same for both built-in an derived types. It is true that these
concepts are defined inside Section 9 (Built-In Types) but I am not sure if this
was really intended to be limited to built-in types. For one, using IP addresses
as list keys would then be impossible.

Lada

> typedef description statements.
> 
> > >  - align the v4 and v6 definitions.
> > 
> > Agreed.
> > 
> > >  - retain the existing flexibility for servers to choose what they
> > > support, noting that any change in behaviour here will be non-backwards
> > compatible.
> > 
> > I am not sure that I understand what you mean. Are you saying that a server
> > can
> > choose to reject a uint8 value like "+

Re: [netmod] 6021 ipv4-prefix

2019-04-29 Thread Juergen Schoenwaelder

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 what they support, 
> noting that any change in behaviour here will be non-backwards compatible.
>

The 'should' text is of limited value since the 'should' text does not
change what is allowed. I hope the newly proposed text spells out more
clearly that a server turns values into canonical format that are not
in canonical format and implementors can then conclude that using
canonical format in the first place is perhaps a good idea - or it is
convenient to have the conversion done by the server.

Note that the canonical format for IPv6 prefixes has much more to it
than setting the non-prefix bits to zero, see RFC 5952 for all the
details that affect the text representation of the address part.

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; it might be convenient for me to
be allowed to push 2001:0DB8:0:0:0:0:0:0/64 and not having to worry
about how to produce the RFC 5952 representation in my glue code that
ties into my database backend. Why would we say clients should not
send values in non-canonical format? Why would we say clients have to
take the pain to ensure everything is turned into 2001:db8::/64 (to
continue the example) before sending values to the server?

Note that the ipv6-address definition has the same canonicalization
properties (if we consider the address portion of ipv6-prefix) and
there is no text saying you should send 2001:db8::1 instead of
2001:0DB8::1.

I think our mission instead is to make it clear what the canonical
format is and that servers will turn lexical representations they
accept into canonical lexical representation. This way people can take
informed decisions about what is appropriate for their specific
clients.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-04-29 Thread Rob Wilton (rwilton)

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 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) 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 definition?
> > > >
> > > > Or is a significant part of your proposal/reasoning to ensure
> > > > backwards
> > > compatibility with what we have today?
> > >
> > > I am trying to clarify what the existing definition says since there
> > > apparently have been different interpretations.
> >
> > Given the definition of ipv6-prefix already contains:
> >
> >   " The IPv6 address should have all bits that do not belong
> >to the prefix set to zero."
> >
> > I think that a better solution might be to add the equivalent text to
> > the ipv4-prefix definition:
> >
> >   " The IPv4 address should have all bits that do not belong
> >to the prefix set to zero."
> 
> But this still essentially permits the client to send a value with those bits 
> set, and
> the server has to be prepared to handle it.

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 what they support, 
noting that any change in behaviour here will be non-backwards compatible.

Thanks,
Rob


> 
> If the goal is to get rid of the difference between ipv4- and ipv6-prefix, 
> which
> makes sense, then I prefer to remove this sentence from ipv6-prefix.

> 
> Lada
> 
> >
> > Thanks,
> > Rob
> >
> >
> > > /js
> > >
> > > --
> > > 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
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-04-29 Thread Ladislav Lhotka

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 ipv4-prefix
> > 
> > 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 definition?
> > > 
> > > Or is a significant part of your proposal/reasoning to ensure backwards
> > compatibility with what we have today?
> > 
> > I am trying to clarify what the existing definition says since there
> > apparently
> > have been different interpretations.
> 
> Given the definition of ipv6-prefix already contains:
> 
>   " The IPv6 address should have all bits that do not belong
>to the prefix set to zero."
> 
> I think that a better solution might be to add the equivalent text to the
> ipv4-prefix definition:
> 
>   " The IPv4 address should have all bits that do not belong
>to the prefix set to zero."

But this still essentially permits the client to send a value with those bits
set, and the server has to be prepared to handle it.

If the goal is to get rid of the difference between ipv4- and ipv6-prefix, which
makes sense, then I prefer to remove this sentence from ipv6-prefix.

Lada

> 
> Thanks,
> Rob
> 
> 
> > /js
> > 
> > --
> > 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
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-04-29 Thread Rob Wilton (rwilton)




> -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) 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 definition?
> >
> >
> > Or is a significant part of your proposal/reasoning to ensure backwards
> compatibility with what we have today?
> >
> 
> I am trying to clarify what the existing definition says since there 
> apparently
> have been different interpretations.

Given the definition of ipv6-prefix already contains:

  " The IPv6 address should have all bits that do not belong
   to the prefix set to zero."

I think that a better solution might be to add the equivalent text to the 
ipv4-prefix definition:

  " The IPv4 address should have all bits that do not belong
   to the prefix set to zero."

Thanks,
Rob


> 
> /js
> 
> --
> 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
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-04-29 Thread Juergen Schoenwaelder

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 definition?
>
>
> Or is a significant part of your proposal/reasoning to ensure backwards 
> compatibility with what we have today?
>

I am trying to clarify what the existing definition says since there
apparently have been different interpretations.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-04-29 Thread Rob Wilton (rwilton)




> -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 (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't obvious to me that if the input configuration contains 
> > "10.0.0.1/8"
> then when the client requests that configuration back again it should get
> "10.0.0.0/8" back rather than the value that they provided in the input
> configuration.
> >
> > To me, that probably means that a sensible client should just use the 
> > canonical
> format.  Does it improve interop for the type to allow the non-canonical 
> format
> on input?  That isn't obvious to me either.
> >
> 
> We have the same with +7 and 7 - if you configure an integer to be +7 you get
> the value 7 back. The alternative would be to generally disallow any types 
> that
> accept multiple representations in YANG. This would then be a YANG next issue
> to bring up. In YANG 1 and 1.1, we do support "liberal inputs". (And yes, I 
> know
> that some of this is also encoding specific, the hidden can or worms is indeed
> bigger. But I like to have this discussion scoped to the RFC 6991bis effort.)

I think that there is a difference between a canonical representation for base 
types known to YANG, vs a defined canonical representation in a typedef's 
description that requires additional typedef specific code to behave correctly 
under various scenarios (e.g. server input, when comparing instance values).

I do agree that a clarification is better than the ambiguity that we have now.

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

Or is a significant part of your proposal/reasoning to ensure backwards 
compatibility with what we have today?

Thanks,
Rob


> 
> /js
> 
> --
> 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
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-04-29 Thread Juergen Schoenwaelder

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't obvious to me that if the input configuration contains 
> "10.0.0.1/8" then when the client requests that configuration back again it 
> should get "10.0.0.0/8" back rather than the value that they provided in the 
> input configuration.
> 
> To me, that probably means that a sensible client should just use the 
> canonical format.  Does it improve interop for the type to allow the 
> non-canonical format on input?  That isn't obvious to me either.
>

We have the same with +7 and 7 - if you configure an integer to be +7
you get the value 7 back. The alternative would be to generally
disallow any types that accept multiple representations in YANG. This
would then be a YANG next issue to bring up. In YANG 1 and 1.1, we do
support "liberal inputs". (And yes, I know that some of this is also
encoding specific, the hidden can or worms is indeed bigger. But I
like to have this discussion scoped to the RFC 6991bis effort.)

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-04-29 Thread Rob Wilton (rwilton)




> -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 (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@ietf.org
> > > Subject: Re: [netmod] 6021 ipv4-prefix
> > >
> > > 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 canonical format.
> > > >
> > >
> > > So you propose to deprecate the definitions and create new ones?
> > > Otherwise, I can't follow why a clarification can be the worst possible
> outcome.
> > >
> > > Note that we do have different lexical representations this in
> > > several other places. We accept +17 to mean 17 (Section 9.1 of RFC
> > > 7950.)
> >
> > This feels somewhat different.  I think that it well understood that these 
> > are
> just the same thing.  E.g. anything that parses these into a integer type will
> internally end up with the same value in both cases.
> >
> 
> For me, 10.0.0.0/8 and 10.0.0.1/8 both denote the same IPv4 prefix.

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't obvious to me that if the input configuration contains 
"10.0.0.1/8" then when the client requests that configuration back again it 
should get "10.0.0.0/8" back rather than the value that they provided in the 
input configuration.

To me, that probably means that a sensible client should just use the canonical 
format.  Does it improve interop for the type to allow the non-canonical format 
on input?  That isn't obvious to me either.


> 
> > I have a related question on the fraction-digits type:
> >
> >  typedef my-decimal {
> >type decimal64 {
> >  fraction-digits 2;
> >  range "1 .. 3.14 | 10 | 20..max";
> >}
> >  }
> >
> > Should a server accept a value of "3.140" for my-decimal?
> >
> > What about "3.141"?  I presume that servers would generally not accept (and
> then round) this value, and except clients to round appropriately before 
> passing
> the value in.
> 
> Please start a separate thread if you want to discuss this.

I was attempting to use it as a similar example for consistency.  I.e. one 
where extra data is provided and whether the input is validated strictly or 
loosely.

Thanks,
Rob


> 
> /js
> 
> --
> 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
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-04-29 Thread Juergen Schoenwaelder

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@ietf.org
> > Subject: Re: [netmod] 6021 ipv4-prefix
> > 
> > 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 canonical format.
> > >
> > 
> > So you propose to deprecate the definitions and create new ones?
> > Otherwise, I can't follow why a clarification can be the worst possible 
> > outcome.
> > 
> > Note that we do have different lexical representations this in several other
> > places. We accept +17 to mean 17 (Section 9.1 of RFC 7950.)
> 
> This feels somewhat different.  I think that it well understood that these 
> are just the same thing.  E.g. anything that parses these into a integer type 
> will internally end up with the same value in both cases.
>

For me, 10.0.0.0/8 and 10.0.0.1/8 both denote the same IPv4 prefix.

> I have a related question on the fraction-digits type:
> 
>  typedef my-decimal {
>type decimal64 {
>  fraction-digits 2;
>  range "1 .. 3.14 | 10 | 20..max";
>}
>  } 
> 
> Should a server accept a value of "3.140" for my-decimal?
> 
> What about "3.141"?  I presume that servers would generally not accept (and 
> then round) this value, and except clients to round appropriately before 
> passing the value in.

Please start a separate thread if you want to discuss this.

/js

-- 
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
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-04-29 Thread Juergen Schoenwaelder

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-00 back in 2008) checked in a fix:
> 
>   The confd:ipv4Prefix and confd:ipv6Prefix types now require that all
>   bits that do not belong to the prefix are set to zero. This is for
>   compatibility with the corresponding YANG types defined by the IETF
>   NETMOD working group.
> 
> You may want to see the threads:
> 
> https://mailarchive.ietf.org/arch/msg/netmod/bXL0Mec_ZVVyalmK3pNHkczm6ZI
> 
> https://mailarchive.ietf.org/arch/msg/netmod/3Wz5BPgxZajCZloAOjU-ycfr9Lg
> 
> Specifically Juergen's proposal:
> 
>   Require that all bits that are not part of the prefix are set to
>   zero (192.0.2.8/24 becomes an invalid representation of an IPv4
>   prefix)
> 
> I can't find any discussion in the archive about allowing non-zero non-prefix
> bits.  So I think that the original intention was to be strict in
> these types.  I agree that the current description text needs
> clarification in either case.

Looking at the archive again, the second message seems to indicate
that the idea was to require non-prefix bits to be zero for IPv4 but
not for IPv6, which could explain why we have the SHOULD text for
ip6-prefix but not for ipv4-prefix. In retrospect, having different
requirements for non-prefix bits in ipv4-prefix and ip6-prefix sounds
somewhat weird. The first message you refer to only indicates that we
need to think about canonical formats for the ipvX-prefix types.

Since the text does not say that non-zero non-prefix bits are
disallowed, I think the clarification I have proposed is a path
forward to resolve this.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-04-29 Thread Rob Wilton (rwilton)

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 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 canonical format.
> >
> 
> So you propose to deprecate the definitions and create new ones?
> Otherwise, I can't follow why a clarification can be the worst possible 
> outcome.
> 
> Note that we do have different lexical representations this in several other
> places. We accept +17 to mean 17 (Section 9.1 of RFC 7950.)

This feels somewhat different.  I think that it well understood that these are 
just the same thing.  E.g. anything that parses these into a integer type will 
internally end up with the same value in both cases.

I have a related question on the fraction-digits type:

 typedef my-decimal {
   type decimal64 {
 fraction-digits 2;
 range "1 .. 3.14 | 10 | 20..max";
   }
 } 

Should a server accept a value of "3.140" for my-decimal?

What about "3.141"?  I presume that servers would generally not accept (and 
then round) this value, and except clients to round appropriately before 
passing the value in.

Thanks,
Rob


> 
> /js
> 
> --
> 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
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-04-29 Thread Ladislav Lhotka

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 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 because of the +
> > > > > > > but
> > > > > > > because of the . followed by additional digits). +17 is I think a
> > > > > > > valid
> > > > > > > integer value but the + will be dropped in the canonical
> > > > > > > representation.
> > > > > > 
> > > > > > Yes, but 2001:db8::1/64 isn't valid prefix (because the host portion
> > > > > > of the
> > > > > > prefix isn't 0) so why should it be "rounded" when 17.4 shouldn't be
> > > > > > rounded
> > > > > > if an integer input is expected?
> > > > > 
> > > > > The non-prefix bits are irrelevant for the prefix and the canonical
> > > > > format has the non-prefix bits all set to zero. I understand that you
> > > > > prefer 2001:db8::1/64 to be an error but RFC 6021 and RFC 6991
> > > > > consider this as valid input that can be safely interpreted to mean
> > > > > 2001:db8::0/64.
> > > > 
> > > > Vice versa, if an implementation does treat 2001:db8::1/64 as a syntax
> > > > error, is that implementation incorrect?
> > > > 
> > > I think so. The types do not require that non-prefix bits are zero
> > > when a value is received. However, a server must report the canonical
> > > value, in this case 2001:db8::/64.
> > 
> > Cisco NSO treats 2001:db8::1/64 as a syntax error for a leaf of type
> > ip-prefix (or ip6-prefix).
> > 
> > It would be interesting to hear Martins opinion on this.
> 
> 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-00 back in 2008) checked in a fix:
> 
>   The confd:ipv4Prefix and confd:ipv6Prefix types now require that all
>   bits that do not belong to the prefix are set to zero. This is for
>   compatibility with the corresponding YANG types defined by the IETF
>   NETMOD working group.
> 
> You may want to see the threads:
> 
> https://mailarchive.ietf.org/arch/msg/netmod/bXL0Mec_ZVVyalmK3pNHkczm6ZI
> 
> https://mailarchive.ietf.org/arch/msg/netmod/3Wz5BPgxZajCZloAOjU-ycfr9Lg
> 
> Specifically Juergen's proposal:
> 
>   Require that all bits that are not part of the prefix are set to
>   zero (192.0.2.8/24 becomes an invalid representation of an IPv4
>   prefix)

Interestingly, the revisions of draft-ietf-netmod-yang-types preceding this
thread also had this sentence for ipv4-prefix:

   The IPv4 address represented in dotted quad notation
   should have all bits that do not belong to the prefix
   set to zero.

In the immediately following revision (draft-ietf-netmod-yang-types-02), this
sentence was removed, though not for ipv6-prefix.

Lada

> 
> I can't find any discussion in the archive about allowing non-zero non-prefix
> bits.  So I think that the original intention was to be strict in
> these types.  I agree that the current description text needs
> clarification in either case.
> 
> 
> 
> /martin
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-04-29 Thread Martin Bjorklund

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:
>  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 because of the + but
> > because of the . followed by additional digits). +17 is I think a
> > valid
> > integer value but the + will be dropped in the canonical
> > representation.
> 
>  Yes, but 2001:db8::1/64 isn't valid prefix (because the host portion
>  of the
>  prefix isn't 0) so why should it be "rounded" when 17.4 shouldn't be
>  rounded
>  if an integer input is expected?
> >>>
> >>> The non-prefix bits are irrelevant for the prefix and the canonical
> >>> format has the non-prefix bits all set to zero. I understand that you
> >>> prefer 2001:db8::1/64 to be an error but RFC 6021 and RFC 6991
> >>> consider this as valid input that can be safely interpreted to mean
> >>> 2001:db8::0/64.
> >>
> >> Vice versa, if an implementation does treat 2001:db8::1/64 as a syntax
> >> error, is that implementation incorrect?
> >>
> > I think so. The types do not require that non-prefix bits are zero
> > when a value is received. However, a server must report the canonical
> > value, in this case 2001:db8::/64.
> 
> Cisco NSO treats 2001:db8::1/64 as a syntax error for a leaf of type
> ip-prefix (or ip6-prefix).
> 
> It would be interesting to hear Martins opinion on this.

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-00 back in 2008) checked in a fix:

  The confd:ipv4Prefix and confd:ipv6Prefix types now require that all
  bits that do not belong to the prefix are set to zero. This is for
  compatibility with the corresponding YANG types defined by the IETF
  NETMOD working group.

You may want to see the threads:

https://mailarchive.ietf.org/arch/msg/netmod/bXL0Mec_ZVVyalmK3pNHkczm6ZI

https://mailarchive.ietf.org/arch/msg/netmod/3Wz5BPgxZajCZloAOjU-ycfr9Lg

Specifically Juergen's proposal:

  Require that all bits that are not part of the prefix are set to
  zero (192.0.2.8/24 becomes an invalid representation of an IPv4
  prefix)

I can't find any discussion in the archive about allowing non-zero non-prefix
bits.  So I think that the original intention was to be strict in
these types.  I agree that the current description text needs
clarification in either case.



/martin

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-04-29 Thread Ladislav Lhotka

"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 
> the
> > server must return data (and conceptually store) in canonical format. 
> What
> > is much less clear is the allowed input formats which then includes
> > 2001:db8::1/64. I think it could be worthwhile to explicitly state this 
> as
> > it is a bit surprising. Unlike say the uintX types, there is no "lexical
> > representation" section for ip-prefix (I presume because they are not
> > basetypes and so the lexical presentation follows the base, string in 
> this
> > case + the pattern) that explains things in any detail. Do you think we
> > could add some clarifications, perhaps to the description of the type 
> about
> > this? Or could we even add a lexical representation section with 
> examples?
> > Or just an examples section?
> >
> 
> I have added text along these lines in my sources (goes behind the
> definition of the canonical format):
> 
>   The definition of ipv6-prefix does not require that bits,
>   which are not part of the prefix, are set to zero. However,
>   implementations have to return values in canonical format,
>   which requires non-prefix bits to be set to zero. This means
>   that 2001:db8::1/64 must be accepted as a valid value but it
>   will be converted into the canonical format 2001:db8::/64.

This just says how the canonical format works, and this is already
defined in RFC 7950. I know this particular type is a hot topic right
now, but there are other places where the canonical format may come into
play. I think that YANG readers should just understand what it is about.

Perhaps it would suffice to add a reference to the corresponding RFC
7950 section:

OLD
The canonical format of an IPv[46] prefix has all bits of ...

NEW
The canonical format (see sec. 9.1 of RFC 7950) of an IPv[46] prefix
has all bits of ...

> 
> I have added similar text to the definition of ipv4-prefix. I hope
> that text like this clarifies the situation inline in the type
> definition.
>
> 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 canonical format.

But this is how the canonical format is supposed to work! There are
other types with multiple lexical formats, and the canonical format is
basically just the Postel principle applied to the server: Be liberal in
what you accept, and conservative in what you send.

The expected server behaviour in this case can be a problem only if the
ipv[46]-prefix is (mis)used as IP address & network prefix length combo.

Lada

>
> Thanks,
> Acee
>
>
> 
> /js
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-04-27 Thread Juergen Schoenwaelder

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 that the RFC does not
> (making use of the 64 zero bits of fe80::/10) then the RFC is wrong and
> should be changed.  Happily this seems to be a minority view but, like a
> hydra, the thread keeps coming back to life in another form see e.g.
>

This is NOT this topic. Lets please keep this out of here.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-04-27 Thread tom petch



- 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, 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 because of the
+ but
> > because of the . followed by additional digits). +17 is I think
a valid
> > integer value but the + will be dropped in the canonical
representation.
> 
>  Yes, but 2001:db8::1/64 isn't valid prefix (because the host
portion of the
>  prefix isn't 0) so why should it be "rounded" when 17.4 shouldn't
be rounded
>  if an integer input is expected?
> >>>
> >>> The non-prefix bits are irrelevant for the prefix and the
canonical
> >>> format has the non-prefix bits all set to zero. I understand that
you
> >>> prefer 2001:db8::1/64 to be an error but RFC 6021 and RFC 6991
> >>> consider this as valid input that can be safely interpreted to
mean
> >>> 2001:db8::0/64.
> >>
> >> Vice versa, if an implementation does treat 2001:db8::1/64 as a
syntax
> >> error, is that implementation incorrect?
> >>
> >
> > I think so. The types do not require that non-prefix bits are zero
> > when a value is received. However, a server must report the
canonical
> > value, in this case 2001:db8::/64.
>
> Cisco NSO treats 2001:db8::1/64 as a syntax error for a leaf of type
> ip-prefix (or ip6-prefix).
>
> It would be interesting to hear Martins opinion on this.

Kristian

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 that the RFC does not
(making use of the 64 zero bits of fe80::/10) then the RFC is wrong and
should be changed.  Happily this seems to be a minority view but, like a
hydra, the thread keeps coming back to life in another form see e.g.

Re: encoding link ID in link-local addrs
Re: about violation of standards
Globally Unique Link Local Addresses
mailing list activity
who should try to explain
who shouuld update

even

Re: [Technical Errata Reported] RFC7421 (5699)

In fact almost any post to 6man in the past 10 days (of which there are
many)

Tom Petch

> Kind regards,
> Kristian.
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-04-26 Thread Juergen Schoenwaelder

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

So you propose to deprecate the definitions and create new ones?
Otherwise, I can't follow why a clarification can be the worst
possible outcome.

Note that we do have different lexical representations this in several
other places. We accept +17 to mean 17 (Section 9.1 of RFC 7950.)

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-04-26 Thread Acee Lindem (acee)

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 store) in canonical format. What
> is much less clear is the allowed input formats which then includes
> 2001:db8::1/64. I think it could be worthwhile to explicitly state this as
> it is a bit surprising. Unlike say the uintX types, there is no "lexical
> representation" section for ip-prefix (I presume because they are not
> basetypes and so the lexical presentation follows the base, string in this
> case + the pattern) that explains things in any detail. Do you think we
> could add some clarifications, perhaps to the description of the type 
about
> this? Or could we even add a lexical representation section with examples?
> Or just an examples section?
>

I have added text along these lines in my sources (goes behind the
definition of the canonical format):

  The definition of ipv6-prefix does not require that bits,
  which are not part of the prefix, are set to zero. However,
  implementations have to return values in canonical format,
  which requires non-prefix bits to be set to zero. This means
  that 2001:db8::1/64 must be accepted as a valid value but it
  will be converted into the canonical format 2001:db8::/64.

I have added similar text to the definition of ipv4-prefix. I hope
that text like this clarifies the situation inline in the type
definition.

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

Thanks,
Acee

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-04-26 Thread Juergen Schoenwaelder

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
> 2001:db8::1/64. I think it could be worthwhile to explicitly state this as
> it is a bit surprising. Unlike say the uintX types, there is no "lexical
> representation" section for ip-prefix (I presume because they are not
> basetypes and so the lexical presentation follows the base, string in this
> case + the pattern) that explains things in any detail. Do you think we
> could add some clarifications, perhaps to the description of the type about
> this? Or could we even add a lexical representation section with examples?
> Or just an examples section?
>

I have added text along these lines in my sources (goes behind the
definition of the canonical format):

  The definition of ipv6-prefix does not require that bits,
  which are not part of the prefix, are set to zero. However,
  implementations have to return values in canonical format,
  which requires non-prefix bits to be set to zero. This means
  that 2001:db8::1/64 must be accepted as a valid value but it
  will be converted into the canonical format 2001:db8::/64.

I have added similar text to the definition of ipv4-prefix. I hope
that text like this clarifies the situation inline in the type
definition.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-04-26 Thread Kristian Larsson





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, if an implementation does treat 2001:db8::1/64 as a syntax
error, is that implementation incorrect?



I think so. The types do not require that non-prefix bits are zero
when a value is received. However, a server must report the canonical
value, in this case 2001:db8::/64.


Agreed. The description only says (and only for ipv6-prefix


I think it says it for ipv4-prefix too:

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


This defines the canonical format, and Juergen explained its role earlier in
this thread.


Ah yes, I see now, you're right.




error? Ambiguity of what you are referencing makes it impossible for me
to parse your sentence. Please elaborate.

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 error

If 6021+6991 says it is valid input, then NSO must accept it, no?


I am not familiar with NSO. If it uses the the types from ietf-inet-types and
refuses to accept such input values from a NETCONF/RESTCONF client, then it
looks like a bug to me.


It does use these types so filing bug report I guess.

  
it does accept it, it must then store or at least always return it in

the canonical format?


RFC 7950 says in sec. 9.1 that the server MUST return values in the canonical
form and that the values are conceptually stored in the canonical form (in a
datastore).


Thanks for the reference, it helps! :)

Kind regards,
   Kristian.

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-04-26 Thread Kristian Larsson





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 instead treats 2001:db8::1/64 as a syntax error

If 6021+6991 says it is valid input, then NSO must accept it, no?

Or does 6021+6991 say such a value MAY be treated as valid input? And if it
does accept it, it must then store or at least always return it in the
canonical format?


I do not find anything in 6021+6991 that says 2001:db8::1/64 is
illegal input. If it were illegal, we would not need the definition of
the canonical format that is in 6021+6991. Apparently text could have
been more explicit but if you connect the bits and pieces, I think the
conclusion must be that 2001:db8::1/64 is allowed input, i.e., you do
not have to clear the bits that are irrelevant but the server will do
this since it has to return the value in canonical format.


Thanks for your time in answering this Juergen, much appreciated.

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 2001:db8::1/64. I think it could be worthwhile to explicitly 
state this as it is a bit surprising. Unlike say the uintX types, there 
is no "lexical representation" section for ip-prefix (I presume because 
they are not basetypes and so the lexical presentation follows the base, 
string in this case + the pattern) that explains things in any detail. 
Do you think we could add some clarifications, perhaps to the 
description of the type about this? Or could we even add a lexical 
representation section with examples? Or just an examples section?


Kind regards,
   Kristian.

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-04-26 Thread Ladislav Lhotka

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 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 because of the +
> > > > > > > but
> > > > > > > because of the . followed by additional digits). +17 is I think a
> > > > > > > valid
> > > > > > > integer value but the + will be dropped in the canonical
> > > > > > > representation.
> > > > > > 
> > > > > > Yes, but 2001:db8::1/64 isn't valid prefix (because the host portion
> > > > > > of
> > > > > > the
> > > > > > prefix isn't 0) so why should it be "rounded" when 17.4 shouldn't be
> > > > > > rounded
> > > > > > if an integer input is expected?
> > > > > 
> > > > > The non-prefix bits are irrelevant for the prefix and the canonical
> > > > > format has the non-prefix bits all set to zero. I understand that you
> > > > > prefer 2001:db8::1/64 to be an error but RFC 6021 and RFC 6991
> > > > > consider this as valid input that can be safely interpreted to mean
> > > > > 2001:db8::0/64.
> > > > 
> > > > Vice versa, if an implementation does treat 2001:db8::1/64 as a syntax
> > > > error, is that implementation incorrect?
> > > > 
> > > 
> > > I think so. The types do not require that non-prefix bits are zero
> > > when a value is received. However, a server must report the canonical
> > > value, in this case 2001:db8::/64.
> > 
> > Agreed. The description only says (and only for ipv6-prefix
> 
> I think it says it for ipv4-prefix too:
> 
>...
>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.";

This defines the canonical format, and Juergen explained its role earlier in
this thread.

> 
> 
> > ) that the host bits
> > should be zero, i.e. no strict requirement.
> There is no strict requirement of what? Accepting the data? Throwing an

That the value of the ipv[46]-prefix type must have the host bits set to zero.
In other words, values that do not have this property are still valid.

>  
> error? Ambiguity of what you are referencing makes it impossible for me 
> to parse your sentence. Please elaborate.
> 
> 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 error
> 
> If 6021+6991 says it is valid input, then NSO must accept it, no?

I am not familiar with NSO. If it uses the the types from ietf-inet-types and
refuses to accept such input values from a NETCONF/RESTCONF client, then it
looks like a bug to me.

> 
> Or does 6021+6991 say such a value MAY be treated as valid input? And if

It IS a valid value: it matches the regex pattern and nothing in the description
says otherwise.

>  
> it does accept it, it must then store or at least always return it in 
> the canonical format?

RFC 7950 says in sec. 9.1 that the server MUST return values in the canonical
form and that the values are conceptually stored in the canonical form (in a
datastore).

Lada

> 
> kll
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-04-26 Thread 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 error
> 
> If 6021+6991 says it is valid input, then NSO must accept it, no?
>
> Or does 6021+6991 say such a value MAY be treated as valid input? And if it
> does accept it, it must then store or at least always return it in the
> canonical format?

I do not find anything in 6021+6991 that says 2001:db8::1/64 is
illegal input. If it were illegal, we would not need the definition of
the canonical format that is in 6021+6991. Apparently text could have
been more explicit but if you connect the bits and pieces, I think the
conclusion must be that 2001:db8::1/64 is allowed input, i.e., you do
not have to clear the bits that are irrelevant but the server will do
this since it has to return the value in canonical format.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-04-26 Thread Acee Lindem (acee)

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 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 
length prefixes, while other users hate it as the system shows/does something 
different than what they entered.
> 
> In the end the current definition is what it is.  If we want something 
different we can define it. I personally think an address/prefix-len would be 
useful, and would leave ip-prefix as is.  (again just an individual's opinion.)
> 
> Lou
> 
>> On 4/18/2019 6:53 AM, 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 the same if you define a prefix?
>> Because they're not. One of them is a valid prefix, the other one isn't.
>> 
>>> +17.4 is not an integer, so this is an error (not because of the + but
>>> because of the . followed by additional digits). +17 is I think a valid
>>> integer value but the + will be dropped in the canonical representation.
>> Yes, but 2001:db8::1/64 isn't valid prefix (because the host portion of
>> the prefix isn't 0) so why should it be "rounded" when 17.4 shouldn't be
>> rounded if an integer input is expected?
>> 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-04-26 Thread Kristian Larsson





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 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 because of the + but
because of the . followed by additional digits). +17 is I think a
valid
integer value but the + will be dropped in the canonical
representation.


Yes, but 2001:db8::1/64 isn't valid prefix (because the host portion of
the
prefix isn't 0) so why should it be "rounded" when 17.4 shouldn't be
rounded
if an integer input is expected?


The non-prefix bits are irrelevant for the prefix and the canonical
format has the non-prefix bits all set to zero. I understand that you
prefer 2001:db8::1/64 to be an error but RFC 6021 and RFC 6991
consider this as valid input that can be safely interpreted to mean
2001:db8::0/64.


Vice versa, if an implementation does treat 2001:db8::1/64 as a syntax
error, is that implementation incorrect?



I think so. The types do not require that non-prefix bits are zero
when a value is received. However, a server must report the canonical
value, in this case 2001:db8::/64.


Agreed. The description only says (and only for ipv6-prefix


I think it says it for ipv4-prefix too:

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



) that the host bits
should be zero, i.e. no strict requirement.
There is no strict requirement of what? Accepting the data? Throwing an 
error? Ambiguity of what you are referencing makes it impossible for me 
to parse your sentence. Please elaborate.


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 error

If 6021+6991 says it is valid input, then NSO must accept it, no?

Or does 6021+6991 say such a value MAY be treated as valid input? And if 
it does accept it, it must then store or at least always return it in 
the canonical format?


   kll

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-04-26 Thread Ladislav Lhotka

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, 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 because of the +
> > > > > > but
> > > > > > because of the . followed by additional digits). +17 is I think a
> > > > > > valid
> > > > > > integer value but the + will be dropped in the canonical
> > > > > > representation.
> > > > > 
> > > > > Yes, but 2001:db8::1/64 isn't valid prefix (because the host portion
> > > > > of the
> > > > > prefix isn't 0) so why should it be "rounded" when 17.4 shouldn't be
> > > > > rounded
> > > > > if an integer input is expected?
> > > > 
> > > > The non-prefix bits are irrelevant for the prefix and the canonical
> > > > format has the non-prefix bits all set to zero. I understand that you
> > > > prefer 2001:db8::1/64 to be an error but RFC 6021 and RFC 6991
> > > > consider this as valid input that can be safely interpreted to mean
> > > > 2001:db8::0/64.
> > > 
> > > Vice versa, if an implementation does treat 2001:db8::1/64 as a syntax
> > > error, is that implementation incorrect?
> > > 
> > 
> > I think so. The types do not require that non-prefix bits are zero
> > when a value is received. However, a server must report the canonical
> > value, in this case 2001:db8::/64.
> 
> Cisco NSO treats 2001:db8::1/64 as a syntax error for a leaf of type 
> ip-prefix (or ip6-prefix).

It is a server backend job to take care about this, the YANG type can stay more
liberal. Similar differences in implementations are rather typical.

Lada

> 
> It would be interesting to hear Martins opinion on this.
> 
> Kind regards,
> Kristian.
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-04-26 Thread Ladislav Lhotka

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, 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 because of the + but
> > > > > because of the . followed by additional digits). +17 is I think a
> > > > > valid
> > > > > integer value but the + will be dropped in the canonical
> > > > > representation.
> > > > 
> > > > Yes, but 2001:db8::1/64 isn't valid prefix (because the host portion of
> > > > the
> > > > prefix isn't 0) so why should it be "rounded" when 17.4 shouldn't be
> > > > rounded
> > > > if an integer input is expected?
> > > 
> > > The non-prefix bits are irrelevant for the prefix and the canonical
> > > format has the non-prefix bits all set to zero. I understand that you
> > > prefer 2001:db8::1/64 to be an error but RFC 6021 and RFC 6991
> > > consider this as valid input that can be safely interpreted to mean
> > > 2001:db8::0/64.
> > 
> > Vice versa, if an implementation does treat 2001:db8::1/64 as a syntax
> > error, is that implementation incorrect?
> > 
> 
> I think so. The types do not require that non-prefix bits are zero
> when a value is received. However, a server must report the canonical
> value, in this case 2001:db8::/64.

Agreed. The description only says (and only for ipv6-prefix) that the host bits
should be zero, i.e. no strict requirement.

Lada

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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-04-25 Thread Jeff Tantsura

+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't have to do the transformation from address to network, notably for odd 
> length prefixes, while other users hate it as the system shows/does something 
> different than what they entered.
> 
> In the end the current definition is what it is.  If we want something 
> different we can define it. I personally think an address/prefix-len would be 
> useful, and would leave ip-prefix as is.  (again just an individual's 
> opinion.)
> 
> Lou
> 
>> On 4/18/2019 6:53 AM, 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 the same if you define a prefix?
>> Because they're not. One of them is a valid prefix, the other one isn't.
>> 
>>> +17.4 is not an integer, so this is an error (not because of the + but
>>> because of the . followed by additional digits). +17 is I think a valid
>>> integer value but the + will be dropped in the canonical representation.
>> Yes, but 2001:db8::1/64 isn't valid prefix (because the host portion of
>> the prefix isn't 0) so why should it be "rounded" when 17.4 shouldn't be
>> rounded if an integer input is expected?
>> 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-04-25 Thread Kristian Larsson





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 Thu, Apr 18, 2019 at 11:43:05AM +0200, Mikael Abrahamsson wrote:
+17.4 is not an integer, so this is an error (not because of the + but
because of the . followed by additional digits). +17 is I think a valid
integer value but the + will be dropped in the canonical representation.


Yes, but 2001:db8::1/64 isn't valid prefix (because the host portion of the
prefix isn't 0) so why should it be "rounded" when 17.4 shouldn't be rounded
if an integer input is expected?


The non-prefix bits are irrelevant for the prefix and the canonical
format has the non-prefix bits all set to zero. I understand that you
prefer 2001:db8::1/64 to be an error but RFC 6021 and RFC 6991
consider this as valid input that can be safely interpreted to mean
2001:db8::0/64.


Vice versa, if an implementation does treat 2001:db8::1/64 as a syntax
error, is that implementation incorrect?



I think so. The types do not require that non-prefix bits are zero
when a value is received. However, a server must report the canonical
value, in this case 2001:db8::/64.


Cisco NSO treats 2001:db8::1/64 as a syntax error for a leaf of type 
ip-prefix (or ip6-prefix).


It would be interesting to hear Martins opinion on this.

Kind regards,
   Kristian.

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-04-25 Thread Juergen Schoenwaelder

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 +0200, Mikael Abrahamsson wrote:
> > > > +17.4 is not an integer, so this is an error (not because of the + but
> > > > because of the . followed by additional digits). +17 is I think a valid
> > > > integer value but the + will be dropped in the canonical representation.
> > > 
> > > Yes, but 2001:db8::1/64 isn't valid prefix (because the host portion of 
> > > the
> > > prefix isn't 0) so why should it be "rounded" when 17.4 shouldn't be 
> > > rounded
> > > if an integer input is expected?
> > 
> > The non-prefix bits are irrelevant for the prefix and the canonical
> > format has the non-prefix bits all set to zero. I understand that you
> > prefer 2001:db8::1/64 to be an error but RFC 6021 and RFC 6991
> > consider this as valid input that can be safely interpreted to mean
> > 2001:db8::0/64.
> 
> Vice versa, if an implementation does treat 2001:db8::1/64 as a syntax
> error, is that implementation incorrect?
>

I think so. The types do not require that non-prefix bits are zero
when a value is received. However, a server must report the canonical
value, in this case 2001:db8::/64.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-04-25 Thread Kristian Larsson





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 because of the + but
because of the . followed by additional digits). +17 is I think a valid
integer value but the + will be dropped in the canonical representation.


Yes, but 2001:db8::1/64 isn't valid prefix (because the host portion of the
prefix isn't 0) so why should it be "rounded" when 17.4 shouldn't be rounded
if an integer input is expected?


The non-prefix bits are irrelevant for the prefix and the canonical
format has the non-prefix bits all set to zero. I understand that you
prefer 2001:db8::1/64 to be an error but RFC 6021 and RFC 6991
consider this as valid input that can be safely interpreted to mean
2001:db8::0/64.


Vice versa, if an implementation does treat 2001:db8::1/64 as a syntax 
error, is that implementation incorrect?


   kll

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-04-18 Thread Acee Lindem (acee)

+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, 9:26 AM, "netmod on behalf of 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't have to do the transformation from address to network, 
notably for odd length prefixes, while other users hate it as the system 
shows/does something different than what they entered.

In the end the current definition is what it is.  If we want something 
different we can define it. I personally think an address/prefix-len 
would be useful, and would leave ip-prefix as is.  (again just an 
individual's opinion.)

Lou

On 4/18/2019 6:53 AM, 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 the same if you define a prefix?
> Because they're not. One of them is a valid prefix, the other one isn't.
>
>> +17.4 is not an integer, so this is an error (not because of the + but
>> because of the . followed by additional digits). +17 is I think a valid
>> integer value but the + will be dropped in the canonical representation.
> Yes, but 2001:db8::1/64 isn't valid prefix (because the host portion of
> the prefix isn't 0) so why should it be "rounded" when 17.4 shouldn't be
> rounded if an integer input is expected?
>

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-04-18 Thread William Lupton

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 description any less normative than a requirement
expressed directly using YANG syntax?
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-04-18 Thread Lou Berger

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 length prefixes, while other users hate it as the system 
shows/does something different than what they entered.


In the end the current definition is what it is.  If we want something 
different we can define it. I personally think an address/prefix-len 
would be useful, and would leave ip-prefix as is.  (again just an 
individual's opinion.)


Lou

On 4/18/2019 6:53 AM, 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 the same if you define a prefix?

Because they're not. One of them is a valid prefix, the other one isn't.


+17.4 is not an integer, so this is an error (not because of the + but
because of the . followed by additional digits). +17 is I think a valid
integer value but the + will be dropped in the canonical representation.

Yes, but 2001:db8::1/64 isn't valid prefix (because the host portion of
the prefix isn't 0) so why should it be "rounded" when 17.4 shouldn't be
rounded if an integer input is expected?



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-04-18 Thread Juergen Schoenwaelder

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 the same if you define a prefix?
> 
> Because they're not. One of them is a valid prefix, the other one isn't.

Well, this has gone twice through WG last call and twice through IESG
review plus several directorate reviews. In the canonical format, the
non-prefix bits are all zero. I fail to see why this is now a problem.

> > +17.4 is not an integer, so this is an error (not because of the + but
> > because of the . followed by additional digits). +17 is I think a valid
> > integer value but the + will be dropped in the canonical representation.
> 
> Yes, but 2001:db8::1/64 isn't valid prefix (because the host portion of the
> prefix isn't 0) so why should it be "rounded" when 17.4 shouldn't be rounded
> if an integer input is expected?

The non-prefix bits are irrelevant for the prefix and the canonical
format has the non-prefix bits all set to zero. I understand that you
prefer 2001:db8::1/64 to be an error but RFC 6021 and RFC 6991
consider this as valid input that can be safely interpreted to mean
2001:db8::0/64.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-04-18 Thread Mikael Abrahamsson


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 other one isn't.

+17.4 is not an integer, so this is an error (not because of the + but 
because of the . followed by additional digits). +17 is I think a valid 
integer value but the + will be dropped in the canonical representation.


Yes, but 2001:db8::1/64 isn't valid prefix (because the host portion of 
the prefix isn't 0) so why should it be "rounded" when 17.4 shouldn't be 
rounded if an integer input is expected?


--
Mikael Abrahamssonemail: swm...@swm.pp.se

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-04-18 Thread Juergen Schoenwaelder

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 representation of the
>type's values.  Some types allow multiple lexical representations of
>the same value, for example, the positive integer "17" can be
>represented as "+17" or "17".  Implementations MUST support all
>lexical representations specified in this document."
> 
> I don't know what the word "lexical" representation means here. Let's take
> another example.
> 
> If I commit "+17.4" into an integer, should I expect the netconf server to
> round this down to 17 and commit that? This is effectively the same thing as
> the above example. When I tried this just now, I got that 17.4 is not a
> valid integer from the software I am using. Is this software doing the wrong
> thing?

+17.4 is not an integer, so this is an error (not because of the + but
because of the . followed by additional digits). +17 is I think a
valid integer value but the + will be dropped in the canonical
representation.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-04-18 Thread Mikael Abrahamsson


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 canonical representation is
2001:db8::/64. Hence, if you configure 2001:db8::1/64, then the server
will accept that input report the value back as 2001:db8::/64. The
main reason for having canonical formats is to make comparisons easy
and predictable. Think about xpath expressions - without a predictable
canonical representations, they would become rather complex since they
would have to deal with several different representations.


Yes, I perfectly understand the IPv6 compression canonical format, since 
it results in two bit fields expressed in ASCII can be string compared.


However, from a networking point of view 2001:db8::/64 and 2001:db8::1/64 
are NOT the same, and I believe all systems I have interacted with would 
throw an error if I tried to commect 2001:db8::1/64 when the system 
expected the last 64 bits to be zeroed.


2001:db8::/64 2001:db8:0::/64 is the same thing when you use ut fir 
configuration, after the configuration has been applied in the system. 
They're two different (correct) representations of the same configuration 
item. I fully understand why the canonical format is needed here and how 
it's supposed to be used.


2001:db8::/64 and 2001:db8::1/64 are NOT the same if you use them.

https://tools.ietf.org/html/rfc6020#section-9.1

"   For most types, there is a single canonical representation of the
   type's values.  Some types allow multiple lexical representations of
   the same value, for example, the positive integer "17" can be
   represented as "+17" or "17".  Implementations MUST support all
   lexical representations specified in this document."

I don't know what the word "lexical" representation means here. Let's take 
another example.


If I commit "+17.4" into an integer, should I expect the netconf server to 
round this down to 17 and commit that? This is effectively the same thing 
as the above example. When I tried this just now, I got that 17.4 is not a 
valid integer from the software I am using. Is this software doing the 
wrong thing?


--
Mikael Abrahamssonemail: swm...@swm.pp.se

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-04-18 Thread Acee Lindem (acee)

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

What is the netconf server supposed to do if a client tries to store 
192.168.1.1/24 in ipv4-prefix ? Or 2001:db8::1/64 in ipv6-prefix?

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.

Thanks,
Acee


Reading the canonical format description in 6021 one might intepret that 
the netconf server should just truncate the host bits and store these as 
192.168.1.0/24 and 2001:db8::/64 ? This means the netconf server actually 
stored something else than the client tried to commit (the resulting 
uint32 and uint128 will have different information than was commited by 
the netconf client).

Or should the netconf server throw an error if the client tries to commit 
data that is not according to the bit pattern described in the canonical 
format?

I guess I am getting confused by the "canonical format" term being used in 
IPv6 for describing the ascii representation of the value, but both in 
IPv4 and IPv6 it's also used to describe how the bits should be set (and 
not be set) depending on prefix/mask.

Also, the IPv4 canoncical format representation doesn't describe at all 
the ascii representation, so for instance 192.168.001.001 would be valid 
according to 6021. I haven't seen this to be a problem in reality though, 
because IPv4 addresses are typically "compressed" the same way, all the 
time. If we're revving 6021, then perhaps some text about ascii 
representation format should be to use the format used by the posix 
function inet_ntoa() ?

-- 
Mikael Abrahamssonemail: swm...@swm.pp.se

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-04-18 Thread Juergen Schoenwaelder

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 netconf server supposed to do if a client tries to store
> 192.168.1.1/24 in ipv4-prefix ? Or 2001:db8::1/64 in ipv6-prefix?
> 
> Reading the canonical format description in 6021 one might intepret that the
> netconf server should just truncate the host bits and store these as
> 192.168.1.0/24 and 2001:db8::/64 ? This means the netconf server actually
> stored something else than the client tried to commit (the resulting uint32
> and uint128 will have different information than was commited by the netconf
> client).

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 canonical representation is
2001:db8::/64. Hence, if you configure 2001:db8::1/64, then the server
will accept that input report the value back as 2001:db8::/64. The
main reason for having canonical formats is to make comparisons easy
and predictable. Think about xpath expressions - without a predictable
canonical representations, they would become rather complex since they
would have to deal with several different representations.

> Or should the netconf server throw an error if the client tries to commit
> data that is not according to the bit pattern described in the canonical
> format?

No, as explained above, the server should accept the input and convert
it into canonical format.

> I guess I am getting confused by the "canonical format" term being used in
> IPv6 for describing the ascii representation of the value, but both in IPv4
> and IPv6 it's also used to describe how the bits should be set (and not be
> set) depending on prefix/mask.

I am not sure what the problem is here. If your implementation stores
the address in binary format, then the canonical representation would
clear the unused bits - or you leave them in and you ignore them when
the server produces the canonical textual representation. This is
implementation detail (I would implement this by clearing the bits
also in the binary format but others may choose to do differently).

> Also, the IPv4 canoncical format representation doesn't describe at all the
> ascii representation, so for instance 192.168.001.001 would be valid
> according to 6021. I haven't seen this to be a problem in reality though,
> because IPv4 addresses are typically "compressed" the same way, all the
> time. If we're revving 6021, then perhaps some text about ascii
> representation format should be to use the format used by the posix function
> inet_ntoa() ?

In both RFCs (6021 and 6991), I think that the pattern takes care of
leading zeros, i.e., 192.168.001.001 will be rejected. I do not know
the POSIX specification of inet_ntoa(), the man pages I have (usually
close to the POSIX specification) do not detail the exact format. The
version agnostic functions are actually inet_ntop() and inet_pton()
and they may not even be a POSIX standard. And inet_ntop() and
inet_pton() likely do the right thing on most systems that also
implement RFC 5952. (The definition of inet_ntop() in the open group
specification [1] is not very tight about the textual format.)

/js

[1] http://pubs.opengroup.org/onlinepubs/9699919799/

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6021 ipv4-prefix

2019-04-18 Thread Mikael Abrahamsson


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 ? Or 2001:db8::1/64 in ipv6-prefix?


Reading the canonical format description in 6021 one might intepret that 
the netconf server should just truncate the host bits and store these as 
192.168.1.0/24 and 2001:db8::/64 ? This means the netconf server actually 
stored something else than the client tried to commit (the resulting 
uint32 and uint128 will have different information than was commited by 
the netconf client).


Or should the netconf server throw an error if the client tries to commit 
data that is not according to the bit pattern described in the canonical 
format?


I guess I am getting confused by the "canonical format" term being used in 
IPv6 for describing the ascii representation of the value, but both in 
IPv4 and IPv6 it's also used to describe how the bits should be set (and 
not be set) depending on prefix/mask.


Also, the IPv4 canoncical format representation doesn't describe at all 
the ascii representation, so for instance 192.168.001.001 would be valid 
according to 6021. I haven't seen this to be a problem in reality though, 
because IPv4 addresses are typically "compressed" the same way, all the 
time. If we're revving 6021, then perhaps some text about ascii 
representation format should be to use the format used by the posix 
function inet_ntoa() ?


--
Mikael Abrahamssonemail: swm...@swm.pp.se

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] 6021 ipv4-prefix

2019-04-16 Thread 7riw77

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 only the prefix is left, rather than converting all the prefix bits to 
1's.

We might need to clarify this with the libyang folk.

😊 /r

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

67 matches

Mail list logo