Re: [netmod] regular expression flavours (again)

Carsten Bormann <cabo@tzi.org> Fri, 14 June 2019 09:12 UTC

Return-Path: <cabo@tzi.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 A1C7C1200CE for <netmod@ietfa.amsl.com>; Fri, 14 Jun 2019 02:12:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level:
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 lnV21Aw6Qs0h for <netmod@ietfa.amsl.com>; Fri, 14 Jun 2019 02:12:26 -0700 (PDT)
Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F057612002F for <netmod@ietf.org>; Fri, 14 Jun 2019 02:12:25 -0700 (PDT)
Received: from [192.168.217.113] (p54A6CA4C.dip0.t-ipconnect.de [84.166.202.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 45QFHW3wCpzyP1; Fri, 14 Jun 2019 11:12:23 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <ff9a92fb3e5ae65d0466cc81cb5ce42ce5549ce9.camel@nic.cz>
Date: Fri, 14 Jun 2019 11:12:25 +0200
Cc: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, NETMOD WG <netmod@ietf.org>
X-Mao-Original-Outgoing-Id: 582196344.147365-758f582eb5a9ce194593ff3f8b62569f
Content-Transfer-Encoding: quoted-printable
Message-Id: <996EFBB4-E24C-4A3D-A3C3-F0425E0C74AF@tzi.org>
References: <291106e34498ebd68f26bf9ff9b679dd5bd8f0cd.camel@nic.cz> <20190612092555.xotrr4moh36xv4kl@anna.jacobs.jacobs-university.de> <ff9a92fb3e5ae65d0466cc81cb5ce42ce5549ce9.camel@nic.cz>
To: Ladislav Lhotka <lhotka@nic.cz>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/FdcsCbeHE16ThGpU8FLeksJVReg>
Subject: Re: [netmod] regular expression flavours (again)
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, 14 Jun 2019 09:12:29 -0000

On Jun 14, 2019, at 09:58, Ladislav Lhotka <lhotka@nic.cz> wrote:
> 
> I agree with all this but, apparently, OpenConfig people don't care too much.
> And since they are much more agile than the IETF, our views may soon become
> irrelevant.

If this becomes our attitude, we already are irrelevant.

I have no idea why someone would go for Posix REs of all things, but if OpenConfig wants to do that, more power to them.  However, YANG has well-defined extension points, and arbitrarily changing the semantics of the pattern statement is not one of them.  So we have to make sure they know that this is not tolerable, and probably show them the way on a good way to make use of the existing extension points.

For CDDL, we essentially have the same problem (nobody likes W3C XSD, not even their REs, but there were good reasons to choose them, not the least that YANG also chose them).  CDDL also has an extension point that is useful here, and RFC 8610 Section 3.8.3.2 was added specifically to guide CDDL users to use the right extension point once the need comes up:

https://tools.ietf.org/html/rfc8610#section-3.8.3.2

I would expect the netmod community to write a similar section, in a separate I-D of its own if need be, and obtain IETF consensus on it.  Make the OpenConfig people aware of it (now, and when it’s done).  Github issues are a good way to do the latter.

Grüße, Carsten