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

Martin Björklund <mbj+ietf@4668.se> Mon, 27 June 2022 12:04 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 425A8C14F74E for <netmod@ietfa.amsl.com>; Mon, 27 Jun 2022 05:04:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.11
X-Spam-Level:
X-Spam-Status: No, score=-2.11 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, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-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=4668.se header.b=VKZ0KoKR; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=TqyD07gB
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5_OJhWAN19wI for <netmod@ietfa.amsl.com>; Mon, 27 Jun 2022 05:04:37 -0700 (PDT)
Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 655F5C14CF00 for <netmod@ietf.org>; Mon, 27 Jun 2022 05:04:35 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 49FAC320070D; Mon, 27 Jun 2022 08:04:34 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Mon, 27 Jun 2022 08:04:34 -0400
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=fm3; t=1656331473; x= 1656417873; bh=pDdmoT+PfldMIs4104AnWbKhI6UY+rBtz9pQ1RLzgz0=; b=V KZ0KoKR6p35/UHdccRmnR/ZJfTA5wcBVpqxlblDev9PdKvXq3Qyz5Pn0MtbrufNC m7bQ3dDB79Nb8GKRDc5jleFqgrs+mQKVe8QAcNFGnfbV+5Mu2zXYJWoCmPLgv9yt rzKolYIoXkXdeE+MtM38VbOq6WwCX0kKD/4p4O+eJD16tv2gRO6DIzzZjqUIIYoh 1BI8zlZ3rCVA8/6mprjkP3rx1ZlZ6SnC0W+P0mDK10Pu77SHJe3YAN2mXp4BLac+ G+vK09Zqzc5VfO5+kitSOcd+oPJlI9ZWey6kYmd/LlsBzoC8RYvrinMvaeb5tjXZ OtIJcWMgUDLCLY8hCXqOw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id: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; t=1656331473; x= 1656417873; bh=pDdmoT+PfldMIs4104AnWbKhI6UY+rBtz9pQ1RLzgz0=; b=T qyD07gBQQowj9sQZjuu6Zv1ZdVx7lcri/smUEq9qkkp65YuYAsv0r6P6eSAryDS9 WY3fGbdnX8mCQfN6oQbft3lTjfib2HAjbUkZtCzMUbL7jXvTWWgunlpH7Bd2pC1U /tcNv0O+VGz9BsXeJb0enOgEhwA53b8PBUR9z3VrWJoDxjTqSDp43N3O9+H/lAkt l+u1h+IBYK6xJ2Di+25Ae4Z0fpXK7Qb2+Oi33x0B/FaAgIrZHFZ7ZdECbZ8IT7dI sSVrKdZqwpiaUg1+A/qwDo2iraloArWPcmlDCQBtBrLc2fMzZZHczDef4Z5vaPTp /Z+5W81dAg3xheFyMO7DA==
X-ME-Sender: <xms:0Zy5YrdixscZDXDrc32CVHHoFOfRBWACXalhfhHmrOmatJ2dReT-9Q> <xme:0Zy5YhOO0kbp0HkdBd3WHMRyT0gdTlV0giUAlL-i6ySMzSY8QVbQcraiWoOEL4WD8 TR1Mf--XghGG2vpZz8>
X-ME-Received: <xmr:0Zy5YkjoL77gNp9VHNY1LfsDMsMqJlSIv8VJvx4K5-lxwMV5DJ8AopShBlVJWo6ZNxpRRq4TEWzM0E9ySKQb_5MgeeMzKRrNjA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrudeghedggeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffkffvvefuhfgjfhfogggtgfesth hqredtredtudenucfhrhhomhepofgrrhhtihhnuceujhpnrhhklhhunhguuceomhgsjhdo ihgvthhfseegieeikedrshgvqeenucggtffrrghtthgvrhhnpeevueduleehjeehtdfhfe dugffhudeuvdejgeelgffhieehuddvtdevveegteelfeenucffohhmrghinhepihgvthhf rdhorhhgpdhjrggtohgsshdquhhnihhvvghrshhithihrdguvgenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmsghjodhivghtfhesgeeiieek rdhsvg
X-ME-Proxy: <xmx:0Zy5Ys8CWtx2TLoW_m1LQh7czT08OWqNghYXZ_O6QpVplzH2Tf6-KQ> <xmx:0Zy5Ynvw8AWKoLwgkB2Jtmn6HP17M3d5-5EDKfzsTfr_S0zNZVAP-w> <xmx:0Zy5YrGC79u6CTTXEKG3pLEb-PW3YKD6ib7yF6J1PqJYTb4P1TYTgQ> <xmx:0Zy5Yg5y_UyPIKHsTmz90xLjVxZmHW6KUuyXeUkMvllcjs5URsWpCg>
Feedback-ID: icc614784:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 27 Jun 2022 08:04:32 -0400 (EDT)
Date: Mon, 27 Jun 2022 14:04:29 +0200 (CEST)
Message-Id: <20220627.140429.1881096023009409910.id@4668.se>
To: ietfc@btconnect.com
Cc: andy@yumaworks.com, j.schoenwaelder@jacobs-university.de, netmod@ietf.org
From: Martin =?iso-8859-1?Q?Bj=F6rklund?= <mbj+ietf@4668.se>
In-Reply-To: <AM7PR07MB624812A38620EC13A8600900A0B49@AM7PR07MB6248.eurprd07.prod.outlook.com>
References: <20220322071133.e6oq6neuolzcgvna@anna> <AM7PR07MB624856F66323CC2E01AE485EA0199@AM7PR07MB6248.eurprd07.prod.outlook.com> <AM7PR07MB624812A38620EC13A8600900A0B49@AM7PR07MB6248.eurprd07.prod.outlook.com>
X-Mailer: Mew version 6.8 on Emacs 26.3
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/9c1zxyCXCSDDWydUs7UdJwFj8Tc>
Subject: Re: [netmod] WGLC on draft-ietf-netmod-rfc6991-bis-11
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.39
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, 27 Jun 2022 12:04:42 -0000

Hi,

Regardless of pattern, the usage of this 'leaf language' seems
completely meaningless, and arbitrary.  For example, there is one leaf
'language' per entry in 'list i2nsf-cfi-policy', which is supposed to
cover all 'leaf description' in that list entry.  So I, as an operator
(i) must configure this language tag for each list entry and (ii)
ensure that all descriptions are written in the specified language.
What happens if the tag is incorrect?  How does this help the operator?


/martin




tom petch <ietfc@btconnect.com> wrote:
> A fresh belated thought.
> 
> The I2NSF I-D drew a DISCUSS from Francesca because the strings did
> not have language tags as per RFC2277.  This was added along with a
> 25-line pattern for the language tag, much simplified.  The string was
> wrong which led to a revised pattern.  Meanwhile other I2NSF I-D drew
> the same DISCUSS and were similarly revised so we have multiple
> 25-line patterns (which may now be right).
> 
> With Francesca on the IESG, I can see many YANG I-D attracting the
> same comment so rather than having dozens of copies of the pattern, an
> importable type, suitably checked by an expert (Martin Durst comes to
> mind) would seem prudent.
> 
> RFC6991-bis would seem the place to put it but it really needs to be
> now, not next year.
> 
> Tom Petch 
> 
> ________________________________________
> From: netmod <netmod-bounces@ietf.org> on behalf of tom petch
> <ietfc@btconnect.com>
> Sent: 24 March 2022 17:17
> To: Andy Bierman; Jürgen Schönwälder
> Cc: netmod@ietf.org
> Subject: Re: [netmod] WGLC on draft-ietf-netmod-rfc6991-bis-11
> 
> From: netmod <netmod-bounces@ietf.org> on behalf of Jürgen Schönwälder
> <j.schoenwaelder@jacobs-university.de>
> Sent: 22 March 2022 07:11
> 
> So we have the following options:
> 
> a) Leave revision-date to be defined in ietf-yang-revisions.
> 
> b) Define revision-date in ietf-yang-types.
> 
> c) Define a date-no-zone type (derived from the date type) which does
>    not have the optional time zone offset.
> 
> <tp>
> 
> Yes, I like c) for its simplicity and its adequacy
> 
> Tom Petch
> 
> 
> I am leaning towards option c), having a generic type for a date
> without a time zone is the most general type we can provide. If
> additional specific revision date semantics are necessary, they can be
> provided in ietf-yang-revisions. (Looking at the definition of the
> type revision-identifier in RFC 8525, this is really date-no-zone.)
> 
> /js
> 
> On Tue, Mar 15, 2022 at 08:42:31AM -0700, Andy Bierman wrote:
> > On Tue, Mar 15, 2022 at 6:01 AM Jürgen Schönwälder <
> > j.schoenwaelder@jacobs-university.de> wrote:
> >
> > > On Mon, Mar 14, 2022 at 05:21:01PM -0700, Andy Bierman wrote:
> > > > On Mon, Mar 14, 2022 at 4:34 PM Kent Watsen <kent+ietf@watsen.net>
> > > wrote:
> > > >
> > > > > All,
> > > > >
> > > > > 1) If you provided WGLC comments on this draft, please review the -12
> > > diff
> > > > > <
> > > https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6991-bis-12.txt>
> > > to
> > > > > ensure that the updates made are good.
> > > > >
> > > > > 2) Juergen notes below that he also removed the "revision-identifier"
> > > > > typedef, as it is better
> > > > > defined in the YANG versioning module.  Any objections?
> > > > >
> > > > >
> > > > Sorry for the late comment.
> > > > I think Juergen listed one option as "rename to revision-date and
> > > > leave
> > > it
> > > > in this module".
> > > > I support this option.
> > > >
> > > > There is no chance that the revision date format will be changing any
> > > time
> > > > soon.
> > > > This is useful for general applications because revision date is
> > > > widely
> > > > used.
> > > >
> > >
> > > The ietf-yang-library module (RFC 8525) currently uses its own
> > > definition of revision-identifier. While this module could adopt a
> > > common definition, the value of such a change is minor.
> > >
> > > The question where we place the definition of revision-date is likely
> > > a matter of which role we expect the versioning work to play in the
> > > future. I am relatively neutral on the placement.
> > >
> > >
> > Not that important I guess.
> > One would think the "date" typedef already in the draft would be
> > useful,
> > but it isn't, and therefore not used.
> > There is no typedef for the pattern YYYY-MM-DD.
> >
> > /js
> > >
> >
> > Andy
> >
> >
> > >
> > > --
> > > 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/>
> > >
> 
> --
> 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
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod