Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18

Christian Hopps <chopps@chopps.org> Tue, 16 October 2018 18:57 UTC

Return-Path: <chopps@chopps.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 5AFD9130E30 for <netmod@ietfa.amsl.com>; Tue, 16 Oct 2018 11:57:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 S-Xd4-dA_3J9 for <netmod@ietfa.amsl.com>; Tue, 16 Oct 2018 11:57:03 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 778EC130E27 for <netmod@ietf.org>; Tue, 16 Oct 2018 11:57:03 -0700 (PDT)
Received: from tops.chopps.org (47-50-69-38.static.klmz.mi.charter.com [47.50.69.38]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 8A4E86005A; Tue, 16 Oct 2018 18:57:02 +0000 (UTC)
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>
User-agent: mu4e 1.0; emacs 26.1
From: Christian Hopps <chopps@chopps.org>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Cc: Christian Hopps <chopps@chopps.org>, joel jaeggli <joelja@bogus.com>, NETMOD Working Group <netmod@ietf.org>
In-reply-to: <20181016130829.3jnbnxyb5vjlogih@anna.jacobs.jacobs-university.de>
Date: Tue, 16 Oct 2018 14:57:01 -0400
Message-ID: <sa65zy190ua.fsf@chopps.org>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/1jMXx1yg1bvRgiTxt_5yi4RxtkE>
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:57:05 -0000

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> writes:

> 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.

I've now added an "module-tag" extension statement.

>> > - 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?

I *really* want to stay away from over-specifying (over-complicating) this by imposing a lot of structure and rules. The text uses ":"s suggestively, but I'd rather remove that than start down the path of standardizing additional structure.

It probably would be useful to restrict the actual characters used in the string to avoid odd whitespace (e.g., tabs, newlines/carriage returns). Is there a standard type that just leaves these specific whitespace characters out? I was hesitant to just use something like yang identifier b/c I figured it might be useful for people to include non-ascii-like characters (umlats etc..)

Thanks,
Chris.

>> > - 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