Re: [netmod] 6021 ipv4-prefix

Martin Bjorklund <mbj@tail-f.com> Mon, 29 April 2019 08:48 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26E9C1200E6 for <netmod@ietfa.amsl.com>; Mon, 29 Apr 2019 01:48:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cp5d8IQCc6pF for <netmod@ietfa.amsl.com>; Mon, 29 Apr 2019 01:48:25 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 28FA012008A for <netmod@ietf.org>; Mon, 29 Apr 2019 01:48:25 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 9657A1AE0451; Mon, 29 Apr 2019 10:48:22 +0200 (CEST)
Date: Mon, 29 Apr 2019 10:48:25 +0200 (CEST)
Message-Id: <20190429.104825.851380569838026345.mbj@tail-f.com>
To: kristian@spritelink.net
Cc: netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <01894841-bbf5-ce19-1a60-4737bc717311@spritelink.net>
References: <227a2452-69f9-6786-2643-822e70dc636d@spritelink.net> <20190425215134.pabdl3bbbjoivbaj@anna.jacobs.jacobs-university.de> <01894841-bbf5-ce19-1a60-4737bc717311@spritelink.net>
X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/iG5qpjYBuX_UIgVR8ZceQ1Kblk0>
Subject: Re: [netmod] 6021 ipv4-prefix
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Apr 2019 08:48:27 -0000

Kristian Larsson <kristian@spritelink.net> 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)

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