IETF Logo Mail Archive

Re: [netmod] [yang-doctors] Length on keys in YANG

Jeffrey Haas <jhaas@pfrc.org> Wed, 05 October 2022 14:23 UTC

Return-Path: <jhaas@pfrc.org>
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 984FBC14CF0C; Wed, 5 Oct 2022 07:23:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
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 o1b18cQJ2xXP; Wed, 5 Oct 2022 07:23:53 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 80711C14F730; Wed, 5 Oct 2022 07:23:52 -0700 (PDT)
Received: from smtpclient.apple (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 994BF1E358; Wed, 5 Oct 2022 10:23:51 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_E5C25122-BAC9-41A0-9166-62762A113178"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
From: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <8CC2BD1D-6668-49A3-96FC-067EB71FA8CF@cisco.com>
Date: Wed, 05 Oct 2022 10:23:50 -0400
Cc: Ladislav Lhotka <ladislav.lhotka@nic.cz>, tom petch <ietfc@btconnect.com>, "netmod@ietf.org" <netmod@ietf.org>, "yang-doctors@ietf.org" <yang-doctors@ietf.org>
Message-Id: <5D407A2D-DCCE-47D9-8EB4-31F4632666A3@pfrc.org>
References: <20221003194150.GA13947@pfrc.org> <AM7PR07MB6248820BBCB2B39F93CF92C2A05D9@AM7PR07MB6248.eurprd07.prod.outlook.com> <d06c394c-978a-3c92-1f4b-bda67a2fe6d5@nic.cz> <63C27188-BBDC-48F1-90B0-ADC8BFAECBCE@pfrc.org> <8CC2BD1D-6668-49A3-96FC-067EB71FA8CF@cisco.com>
To: "Acee Lindem (acee)" <acee@cisco.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/2sIQTalowx5Kzg---qnOFxwIDL4>
Subject: Re: [netmod] [yang-doctors] Length on keys in YANG
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: Wed, 05 Oct 2022 14:23:54 -0000

Acee,


> On Oct 5, 2022, at 10:18 AM, Acee Lindem (acee) <acee@cisco.com> wrote:
> 
> It may even be a matter of having a few useful typedefs:
>  
> yang-key32 (length 1..32)
> yang-key64 (length 1..64)
> yang-key128 (length 1..128)
> yang-key256 (length 1..256)
>  
> I agree in principle. Why wouldn’t these be string32, etc, since the leaves in question are of type string. We don’t need “yang-“ since they will be prefixed with “yang-types:” or some other module.

I'm supremely uninterested in the color of the bike shed. :-)  I find minor value is having the word "key" present to cover the use case, but certainly could see use cases where a leaf might also want to limit the content size to some well known sizes.

While I certainly could be the one that authors the underlying draft, there are many who are more deeply involved in daily YANG work that are probably more appropriate parties.  Mostly, I'm hoping this discussion gets someone interested enough to write the trivial draft and hopefully start socializing it in IETF YANG draft reviews.



-- Jeff

v2.23.0 | Report a Bug | By Email