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