Re: [netmod] Add "token" to rfc6991-bis? (was: Re: Add "node-instance-identifier" to rfc6991-bis?)

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Fri, 17 April 2020 15:43 UTC

Return-Path: <J.Schoenwaelder@jacobs-university.de>
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 1B5C43A0E8A; Fri, 17 Apr 2020 08:43:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jacobsuniversity.onmicrosoft.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 GKCbD3rIa4HT; Fri, 17 Apr 2020 08:43:24 -0700 (PDT)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60055.outbound.protection.outlook.com [40.107.6.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0EE63A0E8F; Fri, 17 Apr 2020 08:43:23 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IzxgUcTnlmJNezNZlZJ0N4U7RzTT4vtfxXR/2LqS5pcsLBHD8u9acaIbBq5ThxUgZ4LguxzQUJij+wLQJ/08HtTWN+ShcN83NC5zITaO9Av+thFm9CTBMnPAbQLm6KXamcjdKhoOS9ooCijPP4u6HzGRAZckIGDJuifEgn4b4+R4Sdrfr7tqtqfTB3iQ2mSG9T7PPgA0ACw3AhCG5/YZ42qT8Dp1Q5aGXE3rQWxR657OL/8KR1YWf5RD3dLsCyCRpqH1ocg/pjMU+8xgukttL/GLvQdCDDxqiHzI5o/OzCnOY0RKC8DjZwcK4dap+EWlFWtq6bPMumIk+IUJnqPT+g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=c1iUtk9lr7OQmSa8eqqyIsHp5yfAOGVWsGihndRpGLY=; b=bz47vsB+52jLgDfOycnZ6w1tuLyY1bK9ZdnDdkl8dJMWA1Aqzc4M4hTGohUy5EUcFYB4Z99iYJ01P41AcCAG6tHqyBcYgPRiQbquAupWtDbO0R2I5dH2fhCOrH4/72O+py101apzGnI2eI9TEDP00Lcj93JZrQftgD0Nm8a06Oa2vilT/UMNQIGi2Sn0YC4U69VBFTIw65pgg7GhDS6djnidvYYlNCAZFSFgMOA17+drbWSJngEiNSdPR/UtdM8v0RILomC/UqXe9PKbMKv3fh8lAFpdtM6ZQFzNAD4RS3uBN5GBsXEZKhard7J0Mu8noBvSPq3WvXNTpdZn1CsiGw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=c1iUtk9lr7OQmSa8eqqyIsHp5yfAOGVWsGihndRpGLY=; b=ZvOFiVMk1x7a9cFXYnZv4tD9Ca1pzaB+Sn2AasvR/oLO2K4+m05UQkq3XfZDXU2OYzedIhIZYP0KoBWIIQTJNb6fF4iy/1BJZ/sh77m/qCIRPTZ0cZYhcesQou9VMtmPCw6vfKMr1f0ALs3IQPF26E354RNEZ+KYzSx/q3ATHwI=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=J.Schoenwaelder@jacobs-university.de;
Received: from AM0P190MB0707.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:196::24) by AM0P190MB0609.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:195::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.27; Fri, 17 Apr 2020 15:43:21 +0000
Received: from AM0P190MB0707.EURP190.PROD.OUTLOOK.COM ([fe80::dc34:2067:88d1:c483]) by AM0P190MB0707.EURP190.PROD.OUTLOOK.COM ([fe80::dc34:2067:88d1:c483%5]) with mapi id 15.20.2921.027; Fri, 17 Apr 2020 15:43:21 +0000
Date: Fri, 17 Apr 2020 17:43:20 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Kent Watsen <kent+ietf@watsen.net>
Cc: "netmod@ietf.org" <netmod@ietf.org>, draft-ietf-netmod-rfc6991-bis@ietf.org
Message-ID: <20200417154320.mmri3arrl2su733i@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: Kent Watsen <kent+ietf@watsen.net>, "netmod@ietf.org" <netmod@ietf.org>, draft-ietf-netmod-rfc6991-bis@ietf.org
References: <0100017165acf391-5e3d197d-7911-4d7f-87d4-0ee95fcee855-000000@email.amazonses.com> <20200410200434.xisbzr5cuxzhmkpi@anna.jacobs.jacobs-university.de> <0100017165dadd72-00249a2b-8ea8-4d74-88d0-bf0579e817ae-000000@email.amazonses.com> <20200411064939.3lk5yl3gvac6zxlx@anna.jacobs.jacobs-university.de> <0100017185b30504-4afa0fb9-6e48-422b-b54d-91711211de95-000000@email.amazonses.com> <20200417081625.pjeup33y5wxqwt7k@anna.jacobs.jacobs-university.de> <0100017188b6e098-3664a434-f84f-4cb0-9145-e92ed06a3bb5-000000@email.amazonses.com>
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <0100017188b6e098-3664a434-f84f-4cb0-9145-e92ed06a3bb5-000000@email.amazonses.com>
X-ClientProxiedBy: FR2P281CA0013.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:a::23) To AM0P190MB0707.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:196::24)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from localhost (2001:638:709:5::7) by FR2P281CA0013.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:a::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.25 via Frontend Transport; Fri, 17 Apr 2020 15:43:21 +0000
X-Originating-IP: [2001:638:709:5::7]
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: e5eb6874-f8cd-4ebd-6f84-08d7e2e60e95
X-MS-TrafficTypeDiagnostic: AM0P190MB0609:
X-MS-Exchange-Transport-Forked: True
X-Microsoft-Antispam-PRVS: <AM0P190MB06096485EACD35A6726C4500DED90@AM0P190MB0609.EURP190.PROD.OUTLOOK.COM>
X-MS-Oob-TLC-OOBClassifiers: OLM:9508;
X-Forefront-PRVS: 0376ECF4DD
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0707.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(39850400004)(346002)(376002)(136003)(396003)(366004)(83080400001)(5660300002)(66946007)(1076003)(186003)(16526019)(8936002)(6486002)(66476007)(8676002)(81156014)(316002)(6496006)(786003)(3450700001)(66556008)(52116002)(53546011)(2906002)(478600001)(4326008)(86362001); DIR:OUT; SFP:1101;
Received-SPF: None (protection.outlook.com: jacobs-university.de does not designate permitted sender hosts)
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: f8NjsTk2rPB8Pfl/uIk+vvRbFGkbf68BtJXsUhWcby+Y+g+vgRkUBxpZhxPtBVRTPRY/fXhg2uy0iN16iAhgw0OuZbydntizXX9G3JPmW8lNi4EnKPGE/OmPkbrVN9XjKVXkrNEivvcUrosLMAG+ktnJTkQOQrdsMEHspHel0RzAt20Fh2QLiCx9Su3GH9YhUUt4GDLi+yljxr/WBOMnnguj8YT2T8eRJMj5RAHLpo3MYLH/syoK32eHus262c390Xdy+0FULaFzeNcoydwhO9vixaLUYZZOEU5WvXmHMNmpanYqZMeYIO04UxAj3znTsHy7QIy9Q9NZe2BPrZTGIuSiaQKp/MK1m4Y4gmxvfuIaX+tYBry8jGv4w3Oh3bWkJuii7BqOgwMUgKQglD4mB+S/VL4Y37LOhRt7Qd8M7FRhKvuUhLNJpSqqm39XkM2XWvnEU7gNk5FOJVB5AAvg7t9jn9KXvfCLHOqBkyVqxXHJE2lbYZxO8z5NU2oCUdQGTztUWYBYSXDL2a0whuaqUg==
X-MS-Exchange-AntiSpam-MessageData: WyXhVdM+iHydUfpMsUdUfx2yGLVyFQTqV1q2LDsRFDVpTWV8AFLF8qrTetHfXyj9Co9vVLrh9XdCIF/459SFUqGPrwUcerRz47aBYEV0dzFu1CmKXhz4ZUVp7DyqavgF853Ew/L8IdkP6VnnLad7sPY7uo73rjUTK7QKVPa8jaQ=
X-OriginatorOrg: jacobs-university.de
X-MS-Exchange-CrossTenant-Network-Message-Id: e5eb6874-f8cd-4ebd-6f84-08d7e2e60e95
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Apr 2020 15:43:21.2737 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: cd7YpxC7YSo2wGFmSy9Yh7Ga2z+D4vc7ouQKTkd5JHU7XosyEMlp41bmWL3wkm5zrH4HncrqlJuYLNehttyYC9+xOYjnlSY7blO0ccDKjX4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0P190MB0609
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/xHmWqs2Nkbb4CunwYRuI_Nra5qo>
Subject: Re: [netmod] Add "token" to rfc6991-bis? (was: Re: Add "node-instance-identifier" to rfc6991-bis?)
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, 17 Apr 2020 15:43:26 -0000

On Fri, Apr 17, 2020 at 03:16:58PM +0000, Kent Watsen wrote:
> [changing subject line]
> 
> > On Apr 17, 2020, at 4:16 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> > 
> > On Fri, Apr 17, 2020 at 01:13:54AM +0000, Kent Watsen wrote:
> >> 
> >>>>>> PS: the "token” type add discussion from before never completed (again, modeled after xsd:token)
> >>>> 
> >>>> What about this?
> >>>> 
> >>> 
> >>> What would this type be good for? Any models already using something
> >>> like this?
> >> 
> >> 
> >> Not in a standard model, that I’m aware of but, back at Juniper, I had a typedef for this that I used as a basis for so many things, but mostly things intended to be identifiers of sorts, whereby having whitespace didn’t make sense.
> >> 
> > 
> > This type does not eliminate whitespace, it only reduces multiple
> > consecutive whitespaces to one.
> 
> Leading/trailing whitespace :sigh:  Too pedantic much?
> 
> Please, think about the gazillion models where there is this:
> 
>     leaf name {
>         type string;
>         description ”An arbitrary name for the…”;
>     }
> 
> It’s obvious the name shouldn’t contain paragraphs of text or, in general, non-printable characters of any sort, or preceding/trailing space characters.  Given this preponderance of this use case and the history of module-writers not defining the necessary pattern statements, a “token” type would be welcomed.   For instance:
> 
>     leaf name {
>         type token;
>         description ”An arbitrary name for the…”;
>     }
> 

xsd:token only collapses white space, it does not solve the problem
you are talking about. And some people have argued in the past that
sane operators will not put weird characters into their names. If I
were to define an identifier type, I would consider to disallow white
space instead of collapsing white space. Frankly, if your code can
deal with one whitespace, it likely can deal with two.

While the LMAP model was developed, I had a restricted identifier type
in the LMAP data model. I then implemented the code to enforce the
restriction. And then I figured out that the code to escape funny
characters was not much longer than the code to reject funny
characters and so I ended up removing the restriction.

This ties into the discussion whether YANG should do anything about
normalization and so far we always ended up with declaring this to be
an operational problem. If you put non-normalized strings into your
config, you need to be prepared to deal with the consequences.

Anyway, if we were to address this issue, then xsd:token will most
likely not be the answer.

/js

-- 
Juergen Schoenwaelder           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/>