On Mon, 2019-04-29 at 10:48 +0200, Martin Bjorklund wrote:
> Kristian Larsson <[email protected]> wrote:
> >
> > On 2019-04-25 23:51, 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.
> >
> > Cisco NSO treats 2001:db8::1/64 as a syntax error for a leaf of type
> > ip-prefix (or ip6-prefix).
> >
> > It would be interesting to hear Martins opinion on this.
>
> I did some digging, and it turns out that we had this type internally
> before it was part if ietf-inet-types, where we did not require that
> all non-prefix bits were zero, but at one point (after
> draft-ietf-netmod-yang-types-00 back in 2008) checked in a fix:
>
> The confd:ipv4Prefix and confd:ipv6Prefix types now require that all
> bits that do not belong to the prefix are set to zero. This is for
> compatibility with the corresponding YANG types defined by the IETF
> NETMOD working group.
>
> You may want to see the threads:
>
> https://mailarchive.ietf.org/arch/msg/netmod/bXL0Mec_ZVVyalmK3pNHkczm6ZI
>
> https://mailarchive.ietf.org/arch/msg/netmod/3Wz5BPgxZajCZloAOjU-ycfr9Lg
>
> Specifically Juergen's proposal:
>
> Require that all bits that are not part of the prefix are set to
> zero (192.0.2.8/24 becomes an invalid representation of an IPv4
> prefix)
Interestingly, the revisions of draft-ietf-netmod-yang-types preceding this
thread also had this sentence for ipv4-prefix:
The IPv4 address represented in dotted quad notation
should have all bits that do not belong to the prefix
set to zero.
In the immediately following revision (draft-ietf-netmod-yang-types-02), this
sentence was removed, though not for ipv6-prefix.
Lada
>
> I can't find any discussion in the archive about allowing non-zero non-prefix
> bits. So I think that the original intention was to be strict in
> these types. I agree that the current description text needs
> clarification in either case.
>
>
>
> /martin
>
> _______________________________________________
> 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
