> -----Original Message-----
> From: Ladislav Lhotka <[email protected]>
> Sent: 29 April 2019 16:51
> To: Rob Wilton (rwilton) <[email protected]>
> Cc: NETMOD WG <[email protected]>
> 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 <[email protected]>
> > > Sent: 29 April 2019 16:15
> > > To: Rob Wilton (rwilton) <[email protected]>
> > > 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 <[email protected]> On Behalf Of Ladislav
> > > > > Lhotka
> > > > > Sent: 29 April 2019 15:24
> > > > > To: [email protected]
> > > > > Subject: Re: [netmod] 6021 ipv4-prefix
> > > > >
> > > > > On Mon, 2019-04-29 at 14:02 +0000, Rob Wilton (rwilton) wrote:
> > > > > > > -----Original Message-----
> > > > > > > From: Juergen Schoenwaelder
> > > > > > > <[email protected]>
> > > > > > > Sent: 29 April 2019 14:46
> > > > > > > To: Rob Wilton (rwilton) <[email protected]>
> > > > > > > Cc: Acee Lindem (acee) <[email protected]>; [email protected]
> > > > > > > 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.
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
> > > > > > [email protected]
> > > > > > https://www.ietf.org/mailman/listinfo/netmod
> > > > > --
> > > > > Ladislav Lhotka
> > > > > Head, CZ.NIC Labs
> > > > > PGP Key ID: 0xB8F92B08A9F76C67
> > > > >
> > > > > _______________________________________________
> > > > > netmod mailing list
> > > > > [email protected]
> > > > > 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
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
