Re: [netmod] 6021 ipv4-prefix

On Mon, 2019-04-29 at 15:58 +0000, Rob Wilton (rwilton) wrote:
> > -----Original Message-----
> > From: Ladislav Lhotka <lhotka@nic.cz>
> > Sent: 29 April 2019 16:51
> > To: Rob Wilton (rwilton) <rwilton@cisco.com>
> > Cc: NETMOD WG <netmod@ietf.org>
> > Subject: Re: [netmod] 6021 ipv4-prefix
> > 
> > On Mon, 2019-04-29 at 15:32 +0000, 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 <lhotka@nic.cz>
> > > > Sent: 29 April 2019 16:15
> > > > To: Rob Wilton (rwilton) <rwilton@cisco.com>
> > > > Subject: Re: [netmod] 6021 ipv4-prefix
> > > > 
> > > > On Mon, 2019-04-29 at 14:53 +0000, Rob Wilton (rwilton) wrote:
> > > > > Hi Lada,
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: netmod <netmod-bounces@ietf.org> 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 +0000, Rob Wilton (rwilton) wrote:
> > > > > > > > -----Original Message-----
> > > > > > > > From: Juergen Schoenwaelder
> > > > > > > > <j.schoenwaelder@jacobs-university.de>
> > > > > > > > Sent: 29 April 2019 14:46
> > > > > > > > To: Rob Wilton (rwilton) <rwilton@cisco.com>
> > > > > > > > Cc: Acee Lindem (acee) <acee@cisco.com>; netmod@ietf.org
> > > > > > > > Subject: Re: [netmod] 6021 ipv4-prefix
> > > > > > > > 
> > > > > > > > On Mon, Apr 29, 2019 at 01:33:22PM +0000, 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.
> 
> 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.

As I wrote, accepting this would mean that different strings representing the
same IPv6 address would be different as list keys, because keys are compared
based on their canonical value. The same problem would be in XPath expressions.
I guess this is not what we want.

Lada

> 
> Section "9.1.  Canonical Representation" does not state that the canonical
> format of a type may be overridden by a description statement.
> 
> Thanks,
> Rob
> 
> 
> > 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 "+7" as invalid? Such
> > > > a server is IMO
> > > > non-
> > > > compliant.
> > > 
> > > A server should accept "+7" and return "7", as per RFC 7950.
> > > 
> > > I think that this question is about derived type definitions, and the
> > > ipv4/ipv6-prefix type definition in particular.
> > > 
> > > Thanks,
> > > Rob
> > > 
> > > 
> > > > Lada
> > > > 
> > > > > 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
> > > > --
> > > > Ladislav Lhotka
> > > > Head, CZ.NIC Labs
> > > > PGP Key ID: 0xB8F92B08A9F76C67
> > --
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67