Re: [netmod] Alexey Melnikov's Discuss on draft-ietf-netmod-module-tags-07: (with DISCUSS)

Kent Watsen <kent+ietf@watsen.net> Mon, 17 February 2020 22:36 UTC

Return-Path: <01000170554bb6b1-62072f16-2ead-4c4c-b39f-99731a334722-000000@amazonses.watsen.net>
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 97B291200F5 for <netmod@ietfa.amsl.com>; Mon, 17 Feb 2020 14:36:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 55dPXHx8V4hu for <netmod@ietfa.amsl.com>; Mon, 17 Feb 2020 14:36:31 -0800 (PST)
Received: from a48-90.smtp-out.amazonses.com (a48-90.smtp-out.amazonses.com [54.240.48.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABCA7120058 for <netmod@ietf.org>; Mon, 17 Feb 2020 14:36:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1581978990; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=xYjS0BqbXt6lO+/pGMVfqKOISxJDPvviUm5zxbzsdxU=; b=kL7tTyVCOufObPvGYrJx2XK3YizpFrNW7BjNso+fdHO9ddEUGM7Fr9XY3lAVJTEx QR72agHaMbwL78aM1I5cYdzGuRCuA9tDV9vg/1lvs+5F55dOz5jB/6sYxt5I+uUFJEn RgHyLTy+wRhuoXf38blIfe0rlPEuO4hph+LWc3pM=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <01000170554bb6b1-62072f16-2ead-4c4c-b39f-99731a334722-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_8DD51628-6EF3-4DAD-AB40-C2EECC226121"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Mon, 17 Feb 2020 22:36:30 +0000
In-Reply-To: <27ccbba7-d3d0-a9ab-c19a-9da4fa1d0210@hedeland.org>
Cc: Christian Hopps <chopps@chopps.org>, Randy Presuhn <randy_presuhn@alumni.stanford.edu>, "netmod@ietf.org" <netmod@ietf.org>
To: Per Hedeland <per@hedeland.org>
References: <155499006434.22705.5858614581630974980.idtracker@ietfa.amsl.com> <7F3B9E7F-6AD8-4801-AE60-9F2D704DC69B@chopps.org> <2ee6b71c-bd2c-4676-9e14-cb240c6845c9@www.fastmail.com> <MN2PR11MB43668E4C0863B8A61857CE0CB5150@MN2PR11MB4366.namprd11.prod.outlook.com> <714842CF-A65A-40FD-A62D-6FA7E1A6801F@chopps.org> <C1446662-2320-4158-B34B-3E2D67369F48@chopps.org> <9FECF49A-65E5-436F-973A-7538CFC974E8@chopps.org> <14832a78-ff8c-b923-09ba-207c2cf01362@alumni.stanford.edu> <F22DF063-E77B-4384-AD2E-157CC1DC479C@chopps.org> <3a538bc4-b93e-2027-7870-d59e8609944b@alumni.stanford.edu> <DF98AB41-C1DD-4A43-9C22-222D018A213D@chopps.org> <d79d37eb-14ec-a5ab-6161-971a0c6fd57a@alumni.stanford.edu> <BE06C751-D2E1-4797-8E22-9D7A87C0D616@chopps.org> <27ccbba7-d3d0-a9ab-c19a-9da4fa1d0210@hedeland.org>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2020.02.17-54.240.48.90
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/cG1zzpcsGkaeGSECKXGh8w13dtw>
Subject: Re: [netmod] Alexey Melnikov's Discuss on draft-ietf-netmod-module-tags-07: (with DISCUSS)
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: Mon, 17 Feb 2020 22:36:35 -0000

FWIUW, I created a YANG-Next issue to track the needed long-term update to RFC 7950:

https://github.com/netmod-wg/yang-next/issues/102 <https://github.com/netmod-wg/yang-next/issues/102>

Kent


> On Feb 17, 2020, at 5:31 PM, Per Hedeland <per@hedeland.org> wrote:
> 
> On 2020-02-17 23:14, Christian Hopps wrote:
> >
> >
> >> On Feb 17, 2020, at 4:42 PM, Randy Presuhn <randy_presuhn@alumni.stanford.edu> wrote:
> >>
> >> Hi -
> >>
> >> On 2/17/2020 11:47 AM, Christian Hopps wrote:
> >>>> On Feb 17, 2020, at 11:51 AM, Randy Presuhn <randy_presuhn@alumni.stanford.edu> wrote: Hi - On 2/17/2020 3:15 AM, Christian Hopps wrote: ...
> >>>>> BTW, I did look at the "SHOULD be avoided" (occurs twice that I saw) once dealing with LFs and CRs which lucky for us is not part of a tags allowable characters.
> >>>> There are lots of other things that complicate life. The Yang string definition circumscribes some of them, but not all.
> >>>>> " typedef tag { type string { length "1..max"; pattern '[\S ]+'; } "
> >>>> This pattern doesn't make sense to me when I try to understand it using https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#charcter-classes It excludes "symbols", but permits, for example, paragraph separators and formatting characters and such delights as zero-width non-joiner. Also, in complementing the "all symbols" category, it seems to me it already permits space, so I don't see why it calls out space again.
> >>> The intent was to have the pattern match the description immediately below it: "A tag value is composed of a standard prefix followed by any type 'string' value that does not include carriage return, newline or tab characters." Does this pattern fail in doing that?
> >>
> >> Yes, what it accomplishes does not match the stated intent.
> >
> > I'm finding this hard to believe looking at the definition of "\S" which is "everything but space, tab, newline and carriage return" and then adding "space". Seems to match the definition unless we quibble over the prefix (which I don't think we are).
> 
> +1
> 
> >> I suspect you may have intended something like '[\Z ]+'
> >> See https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#charcter-classes
> >
> > I don't think that's a valid pattern.
> 
> +1
> 
> > If you are talking about the property categories (where I see 'Z' mentioned as "All separators") then there doesn't appear to be a "lower means include, upper means exclude" relationship. Also it appears that to refer to one of these things the syntax is actually "\P{Z}" or "\p{Z}" not just "Z". So translating maybe that's "[\P{Z} ]"? I see nothing that defines how "catEsc" (\p{}) vs "compEsc" (\P{}) are different, but maybe the upper here means exclude.
> 
> The description is right above the definitions:
> 
>  The set containing all characters that have property X, can be
>  identified with a category escape \p{X}. The complement of this set
>  is specified with the category escape \P{X}. ([\P{X}] = [^\p{X}])
> 
> So yes, \P{Z} would be the complement of "All Separators", while your
> original \S is the complement of \s ([#x20\t\n\r]). I.e. \P{Z} would
> exclude "more separators", but is hardly worth the trouble I think -
> and it is *not* the "stated intent".
> 
> > I'm more inclined to just ditch any pattern or restriction the more this gets discussed. Let the user do what they want. If they want to include crazy unicode stuff (almost certainly they dont) then I guess that's what they want.
> 
> FWIW, as I already wrote, I think your original pattern is fine (and I
> think Randy needs to have a closer look at the section he references).
> 
> --Per
> 
> > Thanks,
> > Chris.
> >
> >>
> >> Randy
> >>
> >> _______________________________________________
> >> 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