Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18
Andy Bierman <andy@yumaworks.com> Tue, 16 October 2018 18:45 UTC
Return-Path: <andy@yumaworks.com>
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 E45C3130E2F for <netmod@ietfa.amsl.com>; Tue, 16 Oct 2018 11:45:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 ymac7TRAwxXu for <netmod@ietfa.amsl.com>; Tue, 16 Oct 2018 11:45:14 -0700 (PDT)
Received: from mail-lj1-x242.google.com (mail-lj1-x242.google.com [IPv6:2a00:1450:4864:20::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 706CE130E25 for <netmod@ietf.org>; Tue, 16 Oct 2018 11:45:10 -0700 (PDT)
Received: by mail-lj1-x242.google.com with SMTP id v7-v6so21914232ljg.5 for <netmod@ietf.org>; Tue, 16 Oct 2018 11:45:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=P/yVxqBjTZtfzAsg2RFFkUrYdoifVnHCVuXgxwwkRTQ=; b=bW6Iac82SAN5iASpptr2CeOiRg5diQdiY1RGYRG4Dw/Hp5Z6bndRdsOdEqVkMR7EHR CD4Ef27SjqFF1s20uPxmatCUaPMAiQDJpVGdKqX0OXsVmg2+cSDkR6IQ+kQRMaw7ziYv cPYWcRvhHu3M7+Mr68WKSLgOh/thcGBXTdaVgDbIc3WpGLVF5rJyUOMheAioxEojkGRg KVrJvpbN9sRVsy2dmc5w72pnyO4yfQeWk3da/rF8ZRPd3JENzdHCT1OtO2uhjYFfEGFE eWFwQk4Iop5WxZiLqOWy1TfdowQJQvZDZdP7NEskxdWf5U+gbHsQycaiQvhL7PXlOk1Y QyoA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=P/yVxqBjTZtfzAsg2RFFkUrYdoifVnHCVuXgxwwkRTQ=; b=mR4xj3LjSjT2NPOg6hpla/hDS4mEkb2ni1l7WkVa6MPgZ9grqTqLYFZN61pX43oH7S CO1ji/3Q/WbY4OZ/0jmgStRJMGYpVI44qasROQN7Yc559hHc05QLRmyZTMcc+AFssMIL U5hyfATx4tm4R6qCZNg4pnygc10nunoOaaxPKt3EN+4gJ+rpFTDtIng695Dzm7ulpBFs MUtagC3AW1SCO7Cmkg9M2QdNJSvVDsS4hXKcdy9UbWJmcZPA2V14K9UT9bvSb/QE60rT yaov1BcqK48j01idsObrpf32SL/RTBhTxuTgVbol7kLaRnNsR4DN68fqdmzzgNNwgBrc bDbA==
X-Gm-Message-State: ABuFfogbTEjFQoLWjbEj1DWQfQh1bX27uFfpFC6Sn0EoBcO8ZHVVIEfx 6W0THsYDaRt8CZQVEt3/vnWIopTwmxeXi5ATe8ie1w==
X-Google-Smtp-Source: ACcGV63so2e/GNZSoCtQcfORg3Dw2XlNRhNdR9w+oNiPucct86zmaYNAuZhuMY/gSNuv5D5TB8ZAaLSvcYG6QCX0bzc=
X-Received: by 2002:a2e:9796:: with SMTP id y22-v6mr2492522lji.20.1539715508382; Tue, 16 Oct 2018 11:45:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:f811:0:0:0:0:0 with HTTP; Tue, 16 Oct 2018 11:45:07 -0700 (PDT)
In-Reply-To: <20181016130829.3jnbnxyb5vjlogih@anna.jacobs.jacobs-university.de>
References: <b45d1c39-c2f0-bcaf-61a4-9822ac04725a@bogus.com> <20181002203031.pcdclhq7vb5tohrj@anna.jacobs.jacobs-university.de> <57BCB4D8-D82F-43C9-8D05-2F52A174F37C@chopps.org> <20181016130829.3jnbnxyb5vjlogih@anna.jacobs.jacobs-university.de>
From: Andy Bierman <andy@yumaworks.com>
Date: Tue, 16 Oct 2018 11:45:07 -0700
Message-ID: <CABCOCHTZ6Vj+5WxmAXQLVCEQ3AP95RbYtvCqh0PtsuUdaANM8A@mail.gmail.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Christian Hopps <chopps@chopps.org>, joel jaeggli <joelja@bogus.com>, NETMOD Working Group <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000eec73405785cf3f5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/8SxOztATGsoMwDFTiG0eT69AMxs>
Subject: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18
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: Tue, 16 Oct 2018 18:45:18 -0000
On Tue, Oct 16, 2018 at 6:08 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Tue, Oct 16, 2018 at 08:31:43AM -0400, Christian Hopps wrote: > > > > On Oct 2, 2018, at 4:30 PM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > > - Standard tags defined in description statements > > > > > > I do not like this. YANG has extension statements and having to > > > parse stuff out of free text description statements seems to be a > > > movement backwards. > > > > This is used by the human implementer of the module (i.e., they need to > write code to implement the module). As such it was not intended for > machine parsing. > > > > I am personally not convinced. The whole reason why we have YANG is > automation and I believe people will go and write tools to extract > tags and having to extract them out of free form text looks like a > step backwards. > It is more than a step backwards. There is an unexplained procedure for declaring the module-tag conformance, in addition to the module-tag mappings. All YANG designers are supposed to learn the exact text to write (not free-form at all) and this draft updates 6087bis with procedures for declaring the module-tags in the description-stmt. Also, tool developers are supposed to parse the description-stmt looking for the module-tag definitions. But instead, tool developers are going to say "Use our proprietary YANG extension because we are never going to parse description statements" > > > - System management > > > > > > What is 'system management' and a 'system management protocol'? > > > > These were derived from the work the RtgYangDT originally did where we > were organizing everything under a single device tree. This tree concept > was (rightly) abandoned to be replaced with use of tags. Examples of > protocols would be Syslog, TACAC+, SNMP, Netconf, ... I've added that to > the description. > > > > I am generally not a fan of definition by example. Is SSH a 'system > management protocol'? > An example is not a definition. The IETF is supposed to know the difference. > > > > - Tag format > > > > > > Apparently, the colon has a special meaning in a tag string and > > > otherwise there do not seem to be any restrictions. (Which is good, > > > I can finally put various smileys on my gear.) > > > > > > Should we state explicitly somewhere that a colon has a special > > > meaning and that tag strings are structured into a sequence of > > > 'taggies' separated by colons? Or is definition by example good > > > enough? > > > > I think it's good enough. :) > > I am not convinced this will work well. My understanding is that other > 'hashtags' also have restrictions - whitespace and punctuation > characters are often excluded, it seems. Apparently ':' already means > something special here. Should you later need more special meanings, > you will love to have characters available that you can use. What > about tags that include whitespace or control characters? Do we really > want such tags? > Section 3 defines prefixes for different types of module tags There is no actual definition of a module tag. Is it UTF-8 encoding? US-ASCII? Is it structured such that a pattern could be defined? Is every protocol draft that uses module-tags somehow going to define their own version? I don't see how this draft provides enough interoperability to be useful. > > > - Meaning of tag masks > > > > > > Do masks mean a complete string match or can I mask along the prefix > > > hierarchy, i.e., 'vendor:acme:' masks everything starting with > > > 'vendor:acme:'? > > > > Exact match, I've added text to clarify this. > > OK. One obvious extension is then to have at some point in time tag > match expressions, such as 'vendor:acme:*' (assuming that * is not > a valid character for a tag, see above). > > /js > > Andy > -- > 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/> > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >
- [netmod] WG LC draft-ietf-netmod-module-tags-02 -… joel jaeggli
- Re: [netmod] WG LC draft-ietf-netmod-module-tags-… Juergen Schoenwaelder
- Re: [netmod] WG LC draft-ietf-netmod-module-tags-… Alex Campbell
- Re: [netmod] WG LC draft-ietf-netmod-module-tags-… Christian Hopps
- Re: [netmod] WG LC draft-ietf-netmod-module-tags-… Christian Hopps
- Re: [netmod] WG LC draft-ietf-netmod-module-tags-… Juergen Schoenwaelder
- Re: [netmod] WG LC draft-ietf-netmod-module-tags-… Andy Bierman
- Re: [netmod] WG LC draft-ietf-netmod-module-tags-… Christian Hopps
- Re: [netmod] WG LC draft-ietf-netmod-module-tags-… Christian Hopps
- Re: [netmod] WG LC draft-ietf-netmod-module-tags-… Andy Bierman
- Re: [netmod] WG LC draft-ietf-netmod-module-tags-… Christian Hopps
- Re: [netmod] WG LC draft-ietf-netmod-module-tags-… Alex Campbell
- Re: [netmod] WG LC draft-ietf-netmod-module-tags-… Andy Bierman
- Re: [netmod] WG LC draft-ietf-netmod-module-tags-… Martin Bjorklund
- Re: [netmod] WG LC draft-ietf-netmod-module-tags-… Martin Bjorklund
- Re: [netmod] WG LC draft-ietf-netmod-module-tags-… Christian Hopps
- Re: [netmod] WG LC draft-ietf-netmod-module-tags-… Christian Hopps
- Re: [netmod] WG LC draft-ietf-netmod-module-tags-… Christian Hopps
- Re: [netmod] WG LC draft-ietf-netmod-module-tags-… Martin Bjorklund
- Re: [netmod] WG LC draft-ietf-netmod-module-tags-… Alex Campbell
- Re: [netmod] WG LC draft-ietf-netmod-module-tags-… Christian Hopps
- Re: [netmod] EXTERNAL: Re: WG LC draft-ietf-netmo… Alex Campbell
- Re: [netmod] WG LC draft-ietf-netmod-module-tags-… Joel Jaeggli
- Re: [netmod] WG LC draft-ietf-netmod-module-tags-… Christian Hopps
- Re: [netmod] WG LC draft-ietf-netmod-module-tags-… Joel Jaeggli
- Re: [netmod] EXTERNAL: Re: WG LC draft-ietf-netmo… Christian Hopps