Re: [netmod] WGLC on draft-ietf-netmod-rfc6991-bis-11

Andy Bierman <andy@yumaworks.com> Fri, 18 February 2022 17:11 UTC

Return-Path: <andy@yumaworks.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 C9C0B3A1205 for <netmod@ietfa.amsl.com>; Fri, 18 Feb 2022 09:11:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.887
X-Spam-Level:
X-Spam-Status: No, score=-6.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20210112.gappssmtp.com
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 cz_t8tNu8-GS for <netmod@ietfa.amsl.com>; Fri, 18 Feb 2022 09:11:22 -0800 (PST)
Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BD7A3A0AF4 for <netmod@ietf.org>; Fri, 18 Feb 2022 09:11:21 -0800 (PST)
Received: by mail-lj1-x233.google.com with SMTP id o9so5270697ljq.4 for <netmod@ietf.org>; Fri, 18 Feb 2022 09:11:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lYnHQ0OMVRiVufCzw33xIGqWsdz/ZLchU4XUVGXHSvE=; b=YWiQrM9WDJZAgZn0t9jF/pODhqYelbu69tBAkj1GcB0O3XZ4xEmTYEk1NIHyzOsSA6 V0/TBQT3t3WVGNazxwpHSmh20jKfpWm2/R8afwnXGKCSBkcDxDIyJlNnK6YtaPzVbERz wOrTTDU5NoYhbemmxYgjyFya8AWG+e/AXYMBbSAhboTuYjzHwLm3SKQLo/FQRqJZNxp2 4Oc7igUYR2lEaJLhN4ZCkT9d8GlhDkaXdZM7NND1vQsTPvGgCF0L3gZbMh7cvkooY7zs Jsf90MhRBa2oZx8Bukv6V/EL6DXekn9ZowQD9w9GBUPyIsrjvEvCt6D/qEtu7HXfkFz/ 7Lfw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lYnHQ0OMVRiVufCzw33xIGqWsdz/ZLchU4XUVGXHSvE=; b=ZJ9Dz9rdt6k08AG5gilOVGtekzf0QPNnG+Kmzo+ZAXFbAFqnfMNvScR9xkOF/e5V0O TyoBZkUuoqTWFIHmLKf8UJ5ZdNjPd/LZkYxsBiFCiXKTXWRaezwolZ1dzUqGsHVZJJvP EIBHigxIkGqUCWuL7q0tZXdbGpf6I6rv7iZQIDj7b1ALOe4daTrQPqbdQv+/2XB5+WrM DdfTx0E1wsP74dEeR/8ioPWz819TROawqQm3gApsEy1odyk/E4d3mOXvng+yu24/gKiV f/AfLhTBJqH4LaP0YXZwChuqvCl6pMrwmrjvE3jWBnQRKfFim+cPIwptgXZJdG2hp+zJ pfNQ==
X-Gm-Message-State: AOAM531nVLHmWo6lk4HugLKOI264dL2HfBkVuyhqJ/EoyKlK+b6BhwHo 33DGipyIpfDgE8TFmEFS1UrxCCphlGtsvXDhZ2PcYDg/rew=
X-Google-Smtp-Source: ABdhPJy919p3zZl+YYbd/V6dSGBFQzWrrgHC7s6zjIeGR0ZN57n8px7Swi1v2gYDditedTBbt79QrRwKOkxnd+zStLg=
X-Received: by 2002:a05:651c:1604:b0:246:210:65cf with SMTP id f4-20020a05651c160400b00246021065cfmr6192712ljq.1.1645204279260; Fri, 18 Feb 2022 09:11:19 -0800 (PST)
MIME-Version: 1.0
References: <0100017efa66ecb8-0c62b7d8-c715-4817-9dc9-fa80d5da8951-000000@email.amazonses.com> <431304add29c4d3fb55315c2152e118c@huawei.com> <20220218162257.6xjqkuzwmmpih6s6@anna> <20220218.173914.1497312943442178983.id@4668.se>
In-Reply-To: <20220218.173914.1497312943442178983.id@4668.se>
From: Andy Bierman <andy@yumaworks.com>
Date: Fri, 18 Feb 2022 09:11:08 -0800
Message-ID: <CABCOCHRH-g+ViPc5_pOiJKHBq-jpkM_3ts_nmyjj_uRwxYcGtg@mail.gmail.com>
To: Martin Björklund <mbj+ietf@4668.se>
Cc: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, "maqiufang (A)" <maqiufang1=40huawei.com@dmarc.ietf.org>, NetMod WG <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a6105d05d84df828"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/H1kKvbbxBXBfR6zhBO0sPjAmADg>
Subject: Re: [netmod] WGLC on draft-ietf-netmod-rfc6991-bis-11
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: Fri, 18 Feb 2022 17:11:27 -0000

On Fri, Feb 18, 2022 at 8:39 AM Martin Björklund <mbj+ietf@4668.se> wrote:

> Hi,
>
> I didn't find any discussion about the new percent types in the list
> archives.  Do we really need three types for percent?  We can now
> express 4294967295 percent, but not 10.5 percent.
>
>

IMO it is a mistake to have too many ways to do the same thing.
We already have the "units" statement to add details like "percent" and
"centiseconds".
(And there are RFCs already that define types this way.)

uint8 and int32 and uint32 for percent? Plus the units approach?
I suppose the use-case for uint32 is "measurement of percentage over 2
billion percent".
IMO the units-stmt is sufficient, but there should be a documented
consistent approach
(maybe updating RFC 8407).



> The new tables look good.  s/6020/6021/g though.
>
>
>
> /martin
>

Andy


>
>
> Jürgen Schönwälder <j.schoenwaelder@jacobs-university.de> wrote:
> > On Tue, Feb 15, 2022 at 12:12:04PM +0000, maqiufang (A) wrote:
> >
> > > I have only one comment: It seems that Table 2 doesn’t list all the
> > > types defined in “ietf-inet-types” YANG module, e.g.,
> > > protocol-number, ip-address-link-local, ip-address-and-prefix…
> > > Should this be fixed?
> >
> > Yes, this should be fixed. When the initial version was produced,
> > there was quite some concern about consistency with SMIv2 definitions
> > and this lead to the tables. Meanwhile, I assume the purpose of the
> > tables is more to provide a quick overview. Hence I propose to split
> > the tables into (i) tables that provide an overview of all types
> > defined in the YANG modules and (ii) tables that detail equivalent
> > SMIv2 types where they exist (short tables). For the overview tables,
> > I suggest to add some more information. I am thinking of overview
> > tables like these (keep scrolling, there is more text below):
> >
> > * ietf-yang-types
> >
> >   | Typedef               | Type              | Introduced |
> >   |-----------------------+-------------------+------------|
> >   | counter32             | uint32            | RFC 6021   |
> >   | zero-based-counter32  | uint32            | RFC 6021   |
> >   | counter64             | uint64            | RFC 6021   |
> >   | zero-based-counter64  | uint64            | RFC 6021   |
> >   | gauge32               | uint32            | RFC 6021   |
> >   | gauge64               | uint64            | RFC 6021   |
> >   |-----------------------+-------------------+------------|
> >   | object-identifier     | string            | RFC 6021   |
> >   | object-identifier-128 | object-identifier | RFC 6021   |
> >   |-----------------------+-------------------+------------|
> >   | date-and-time         | string            | RFC 6021   |
> >   | date                  | string            | RFC XXXX   |
> >   | time                  | string            | RFC XXXX   |
> >   |-----------------------+-------------------+------------|
> >   | hours32               | int32             | RFC XXX    |
> >   | minutes32             | int32             | RFC XXX    |
> >   | seconds32             | int32             | RFC XXX    |
> >   | centiseconds32        | int32             | RFC XXX    |
> >   | milliseconds32        | int32             | RFC XXX    |
> >   | microseconds32        | int32             | RFC XXX    |
> >   | microseconds64        | int64             | RFC XXX    |
> >   | nanoseconds32         | int32             | RFC XXX    |
> >   | nanoseconds64         | int64             | RFC XXX    |
> >   | timeticks             | int32             | RFC 6020   |
> >   | timestamp             | timeticks         | RFC 6020   |
> >   |-----------------------+-------------------+------------|
> >   | phys-address          | string            | RFC 6020   |
> >   | mac-address           | string            | RFC 6020   |
> >   |-----------------------+-------------------+------------|
> >   | xpath1.0              | string            | RFC 6020   |
> >   | hex-string            | string            | RFC 6991   |
> >   | uuid                  | string            | RFC 6991   |
> >   | dotted-quad           | string            | RFC 6991   |
> >   | yang-identifier       | string            | RFC 6991   |
> >   | revision-identifier   | date              | RFC XXXX   |
> >   |-----------------------+-------------------+------------|
> >   | percent-i32           | int32             | RFC XXXX   |
> >   | percent-u32           | uint32            | RFC XXXX   |
> >   | percent               | uint8             | RFC XXXX   |
> >   |-----------------------+-------------------+------------|
> >
> > * ietf-inet-types
> >
> >   | Typedef                 | Type         | Introduced |
> >   |-------------------------+--------------+------------|
> >   | ip-version              | enum         | RFC 6021   |
> >   | dscp                    | uint8        | RFC 6021   |
> >   | ipv6-flow-label         | uint32       | RFC 6021   |
> >   | port-number             | uint16       | RFC 6021   |
> >   | protocol-number         | uint8        | RFC XXXX   |
> >   | as-number               | uint32       | RFC 6021   |
> >   |-------------------------+--------------+------------|
> >   | ip-address              | union        | RFC 6021   |
> >   | ipv4-address            | string       | RFC 6021   |
> >   | ipv6-address            | string       | RFC 6021   |
> >   | ip-address-no-zone      | union        | RFC 6991   |
> >   | ipv4-address-no-zone    | ipv4-address | RFC 6991   |
> >   | ipv6-address-no-zone    | ipv6-address | RFC 6991   |
> >   | ip-address-link-local   | union        | RFC XXXX   |
> >   | ipv4-address-link-local | ipv4-address | RFC XXXX   |
> >   | ipv6-address-link-local | ipv6-address | RFC XXXX   |
> >   | ip-prefix               | union        | RFC 6021   |
> >   | ipv4-prefix             | string       | RFC 6021   |
> >   | ipv6-prefix             | string       | RFC 6021   |
> >   | ip-address-and-prefix   | union        | RFC XXXX   |
> >   | ipv4-address-and-prefix | string       | RFC XXXX   |
> >   | ipv6-address-and-prefix | string       | RFC XXXX   |
> >   |-------------------------+--------------+------------|
> >   | domain-name             | string       | RFC 6021   |
> >   | host-name               | domain-name  | RFC XXXX   |
> >   | host                    | union        | RFC 6021   |
> >   |-------------------------+--------------+------------|
> >   | uri                     | string       | RFC 6021   |
> >   | email-address           | string       | RFC XXXX   |
> >   |-------------------------+--------------+------------|
> >
> > In future versions we may add a column indicating the status, but
> > right now all definitions are current, so I rather not add noise.
> > (Instead of the column 'Introduced' one could have a column 'Revision'
> > listing the revision date but somehow pointing to the RFC feels more
> > valuable for modules that we publish in RFCs. And even better would be
> > to produce such tables from annotations, perhaps the versioning people
> > solve that problem.)
> >
> > While putting these tables together, I noticed that we are not
> > consistent with the naming. We have percent-i32 and percent-u32 and I
> > think this is pretty neat since the name indicates that these are
> > signed and unsigned (int32 and uint32) types. We also have hours32,
> > minutes32, seconds32, etc. but here the name provides no clue whether
> > the number is signed. Hence, I suggest to use the naming scheme that
> > is used for the percent types:
> >
> >   hours32               -> hours-i32
> >   minutes32             -> minutes-i32
> >   seconds32             -> seconds-i32
> >   centiseconds32        -> centiseconds-i32
> >   milliseconds32        -> milliseconds-i32
> >   microseconds32        -> microseconds-i32
> >   microseconds64        -> microseconds-i64
> >   nanoseconds32         -> nanoseconds-i32
> >   nanoseconds64         -> nanoseconds-i64
> >
> > /js
> >
> > --
> > Jürgen Schönwälder              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
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>