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
