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

Martin Björklund <mbj+ietf@4668.se> Fri, 18 February 2022 16:39 UTC

Return-Path: <mbj+ietf@4668.se>
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 AB52D3A11E2 for <netmod@ietfa.amsl.com>; Fri, 18 Feb 2022 08:39:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.099
X-Spam-Level:
X-Spam-Status: No, score=-7.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, PDS_NAKED_TO_NUMERO=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=4668.se header.b=CQ/l1eHI; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=X++AUDbB
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 GJfCQE8Kwjnt for <netmod@ietfa.amsl.com>; Fri, 18 Feb 2022 08:39:20 -0800 (PST)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11A503A11E1 for <netmod@ietf.org>; Fri, 18 Feb 2022 08:39:19 -0800 (PST)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 70DB75C03D0; Fri, 18 Feb 2022 11:39:18 -0500 (EST)
Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Fri, 18 Feb 2022 11:39:18 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=4668.se; h=cc:cc :content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm1; bh=cCC97KD+uaXOz9 8Spyx8qtXzTVbEuTY2Olab0AnieBU=; b=CQ/l1eHIJX2iP9lfSZ2PacHL4PRUV7 rxIwC8345pT19ZqQj1XOT0lKZ/UeRLIdhjpyrrSuTmX4oL0HJGTU09xYg7eS/n1m jg9ggG9PZTmg6HYR6VE8odgtnwFJg+h7qycTiKnfyEWdBZA3dG2jekZUIZimfnv8 rQfCRBH/qoN97Y+SDXfo0PU/GG86HH/DsrW1ZDU3iX9RDhKwyKAxQcEpY8orO0ar X1XrSNyrA2IhpDXPPtJKRY3ZDk43LWyJ2i2icyAflg0ohcDso/Ufvn39BKRyV4OE MMpIik3VhV4KTX8/S+t8UEHfZiut/+wB4O9itw7PnFXpv/nts1JHuyNg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=cCC97KD+uaXOz98Spyx8qtXzTVbEuTY2Olab0Anie BU=; b=X++AUDbB6txPJJPAO+eto1XL9PsjaisUwgiRz20YLF61pck6u0gnmjh33 6Y8/0osCk2SBI1CDir9sKwY/nvA9mDQfHE5nHg4E8XXDTj/GrzgmmkWvisa7XvCY nlz6s5u6RwpO5r9nSvZwx5850t9tF/6Y7JXNYxcNOD2XdEcn3i1O2vfsHIzpD9Eo 0V+Xn8DwtuBKh4vW430FLcRkUI688hhhF0ujAp60jxwVQiD8EgPFuUeChQDNXShM TxDZozEMjNc5bFen7Qb5AHexvHGIhsIFH8KXYwZcJaflYM1t3Emi+1zdPadmannw 344N/hcDjcsvZc3mOAlhAFvZHrUbA==
X-ME-Sender: <xms:tcsPYgds2PexFEY5xBqEbHl6lbquBkZ5mMfNoTzbWXDB-dNpfb6-kw> <xme:tcsPYiNlnug1SLrNF-2_138BTA9clXPer8fquiO_Op9pffdsG-RdrPlBqs8B6J-w7 IIAYwA1XcM5XngsdfA>
X-ME-Received: <xmr:tcsPYhja8ucgUUGo1SR2uWWeCUBuemAcCZaXpBACXHhiOBxKWFwhRaf7sdvYpm-Z9Z2bupT5DocaVvN9UlAP2jWMgmLQ3O4>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrkedtgdeklecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffkvffuhfgjfhfogggtgfesthgsre dtredtjeenucfhrhhomhepofgrrhhtihhnuceujhpnrhhklhhunhguuceomhgsjhdoihgv thhfseegieeikedrshgvqeenucggtffrrghtthgvrhhnpeegledukeejkeeggeevtdekke dvvdfftdehtddtjeevhfdtleetudegudekffehgeenucffohhmrghinhepjhgrtghosghs qdhunhhivhgvrhhsihhthidruggvpdhivghtfhdrohhrghenucevlhhushhtvghrufhiii gvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmsghjodhivghtfhesgeeiieekrdhs vg
X-ME-Proxy: <xmx:tcsPYl_YWxUBsQ1pupH4KUiQmAIvqIIRBg0r7QelAA_5rDBehR_IEQ> <xmx:tcsPYss-WLJpaxL5GV6RqUCJbGSgsqHygo1s7vgG2vV4znK9XdlpyA> <xmx:tcsPYsG6B6aEf3oD22_FqirZT6NGuZY_Os9ZbtRDypwxwS_MNQXK0w> <xmx:tssPYpXwSy4ItPe2IlYjBWf_30JJXZDLgPZGgbS0rIrrStxtfkeP-A>
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 18 Feb 2022 11:39:17 -0500 (EST)
Date: Fri, 18 Feb 2022 17:39:14 +0100
Message-Id: <20220218.173914.1497312943442178983.id@4668.se>
To: j.schoenwaelder@jacobs-university.de
Cc: maqiufang1=40huawei.com@dmarc.ietf.org, netmod@ietf.org
From: Martin Björklund <mbj+ietf@4668.se>
In-Reply-To: <20220218162257.6xjqkuzwmmpih6s6@anna>
References: <0100017efa66ecb8-0c62b7d8-c715-4817-9dc9-fa80d5da8951-000000@email.amazonses.com> <431304add29c4d3fb55315c2152e118c@huawei.com> <20220218162257.6xjqkuzwmmpih6s6@anna>
X-Mailer: Mew version 6.8 on Emacs 26.3
Mime-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/vY--RkIUePzMzn6DX3qdXq2Vy1I>
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 16:39:27 -0000

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.

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



/martin


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