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

Andy Bierman <andy@yumaworks.com> Fri, 17 April 2020 15:59 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 D70F13A0F87 for <netmod@ietfa.amsl.com>; Fri, 17 Apr 2020 08:59:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.887
X-Spam-Level:
X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=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 jVSzsx91Xsi6 for <netmod@ietfa.amsl.com>; Fri, 17 Apr 2020 08:59:51 -0700 (PDT)
Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) (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 AC2E23A0F14 for <netmod@ietf.org>; Fri, 17 Apr 2020 08:59:51 -0700 (PDT)
Received: by mail-yb1-xb2d.google.com with SMTP id h205so1280483ybg.6 for <netmod@ietf.org>; Fri, 17 Apr 2020 08:59:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=qMzZXDtY3KxUlkwX446qEwwVJfO3IED5OYuvrOg3+Ko=; b=nrw8ZVYAkGRulEhO7h+T931yifvgE0NlOLeBU20/LovZcFnfg5ygQdf77v97SkHDyd O7ik9xOcVTVYNvYtcloLc4OUV2KmTwCUrvDPLW5B6bN0FbwJfl0QqpmfEVK0d7IeS4ul t/5Sru+6r1XFTlEIGPJB5ptr7uVPm6Eb1uMJCzmQKRegSllYlRk/eoIVhRoLCNNPJIIc KUnQ15kQR+zSOfJsP2E6JGcubHe39K+epYVFjcY8nzF5Hi7X79GAC7fgWqBRptc12zL1 hNPuisenLAiuCAW29sC58Uq5sxRPIXxrLDpH9ESVrOb0OAsKYKxYLZ+yyyf2DLeQYNwR ZyWA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=qMzZXDtY3KxUlkwX446qEwwVJfO3IED5OYuvrOg3+Ko=; b=bA6uN65AjbvyVY8oEbVZXCjct0buzyQFs5Op3DEChVL6evPch0jD2/PMMRet5Ea6IZ NBJWoQfKhsxg0J+Xih9AL5bEBAbCd1YEprlrciB1k8zdRkuwbZ4pSiitr2ruHenh6/Us +IqMo0AJmZ/0xyMLr0B14PJILLPAMvkfdvpcT6F9JZQdgz++iWvKUHQD75FRGm94kPOL bGJwUbrac1u2AvIyiFW+GEBbiXblPJssbeJXCR9PyYP7r5fHDU83+7u17YjgSS0M/Qlh nTUNoWuYhE0Vrfb/F4xbTymchGgQT2HEHRCeNRjsbilFJCJytvDOJi5DQ07zUZwFzzfl dFqQ==
X-Gm-Message-State: AGi0PuY/mSiaEm+dzlaEaywW9M+TX8jxZKuXO5vs/VkaAnb99AEoQyLx VztdV2SvatsbG7ZlKMD0slbAY6KMEFKN10EXiCFm0GPq
X-Google-Smtp-Source: APiQypKQx0G9hAeqPzKbIjB2yPaldKWE5HwMnL5yFjghZWgLPxBt+yaUq+WH3agW8GNTqacb9B5GOk0QGdlmlZegXCQ=
X-Received: by 2002:a25:3252:: with SMTP id y79mr3042020yby.274.1587139189840; Fri, 17 Apr 2020 08:59:49 -0700 (PDT)
MIME-Version: 1.0
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> <20200417154320.mmri3arrl2su733i@anna.jacobs.jacobs-university.de>
In-Reply-To: <20200417154320.mmri3arrl2su733i@anna.jacobs.jacobs-university.de>
From: Andy Bierman <andy@yumaworks.com>
Date: Fri, 17 Apr 2020 08:59:39 -0700
Message-ID: <CABCOCHTiHMke+_Baw9M-Hjb3Un5HGS4n=0qCfkC1fbkUMCEogg@mail.gmail.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Kent Watsen <kent+ietf@watsen.net>, "netmod@ietf.org" <netmod@ietf.org>, draft-ietf-netmod-rfc6991-bis@ietf.org
Content-Type: multipart/alternative; boundary="000000000000a0d7ba05a37ea346"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/tXFTra8-sEBp_wgrAXBYihiTZL8>
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:59:54 -0000

On Fri, Apr 17, 2020 at 8:43 AM Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

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


The issue (for me) is not whether it is easy or difficult to implement this
restriction.
There are security issues to consider when the YANG value is extracted from
a
protocol message and used in other contexts. Special characters such as
whitespace can
be exploited for data injection attacks, etc.

We already have the "yang-identifier" type which is safe to use.



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

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
>