Subject: [netmod] Add "node-instance-identifier" to rfc6991-bis?

From: Kent Watsen <[email-masked]>
Date: Fri, 10 Apr 2020 19:59:25 +0000

draft-ietf-netconf-notification-capabilities imports "ietf-netconf-acm” solely to access "nacm:node-instance-identifier”.  This typedef seems generally useful, would it make sense to move to rrc6991-bis?

PS: the "token” type add discussion from before never completed (again, modeled after xsd:token)

Kent // contributor

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 10 Apr 2020 22:04:34 +0200

The definition is already in draft-ietf-netmod-rfc6991-bis-02.txt but
also see the DISCUSS items related to it.

/js

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

---

From: Kent Watsen <[email-masked]>
Date: Fri, 10 Apr 2020 20:49:34 +0000

Hi Juergen,

> The definition is already in draft-ietf-netmod-rfc6991-bis-02.txt

My bad (good to see it’s in there already)

> but also see the DISCUSS items related to it.

True, but there is a related DISCUSS under "typedef xpath1.0”...

>> PS: the "token” type add discussion from before never completed (again, modeled after xsd:token)

What about this?

Kent // contributor

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 11 Apr 2020 08:49:39 +0200

> True, but there is a related DISCUSS under "typedef xpath1.0”...

I know.
 
> >> PS: the "token” type add discussion from before never completed (again, modeled after xsd:token)

What would this type be good for? Any models already using something
like this?

/js

---

From: Kent Watsen <[email-masked]>
Date: Fri, 17 Apr 2020 01:13:54 +0000

> What would this type be good for? Any models already using something

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.

Kent // contributor

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 17 Apr 2020 10:16:25 +0200

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

This type does not eliminate whitespace, it only reduces multiple
consecutive whitespaces to one.

/js

---

From: Kent Watsen <[email-masked]>
Date: Fri, 17 Apr 2020 15:16:58 +0000

[changing subject line]

> On Apr 17, 2020, at 4:16 AM, Juergen Schoenwaelder <[email-masked]> wrote:
> 

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…”;
    }

Kent // contributor

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 17 Apr 2020 17:43:20 +0200

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

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

---

From: Andy Bierman <[email-masked]>
Date: Fri, 17 Apr 2020 08:59:39 -0700

On Fri, Apr 17, 2020 at 8:43 AM Juergen Schoenwaelder <
[email-masked]> wrote:

> > > On Apr 17, 2020, at 4:16 AM, Juergen Schoenwaelder <
> [email-masked]> wrote:
> > >
> > >> 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.
> > >>
> > >
> > 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;

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.

> likely not be the answer.

Andy

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>