On Fri, Apr 17, 2020 at 8:43 AM Juergen Schoenwaelder < [email protected]> 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 < > [email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
