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.

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