Re: [netmod] Adam Roach's No Objection on draft-ietf-netmod-rfc6087bis-18: (with COMMENT)

[Juergen Schoenwaelder <[e-mail]>]

On Thu, Mar 08, 2018 at 05:55:17PM -0600, Adam Roach wrote:
> >     §4.11.2:
> > 
> >     >  The following typedef from [RFC6991] demonstrates the proper use of
> >     >  the "pattern" statement:
> >     >
> >     >      typedef ipv4-address-no-zone {
> >     >        type inet:ipv4-address {
> >     >          pattern '[0-9\.]*';
> >     >        }
> >     >        ...
> >     >      }
> > 
> >     By contrast, RFC 6021 has a somewhat more complex production:
> > 
> >          pattern
> >              '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'
> >            +  '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])'
> >            + '(%[\p{N}\p{L}]+)?';
> > 
> >     Is there any consensus on how complex the pattern validation
> >     should be? I've
> >     seen some YANG modules with patterns that occupied more than half
> >     a page. Is
> >     that encouraged, discouraged, or neither? It seems some guidance
> >     on this
> >     specific issue would be useful, as the currently published modules
> >     appear to be
> >     all over the map on this topic.
> > 
> > 
> > Not changing any text since the pattern complexity depends on the
> > structure
> > of the text that is being modeled.
> 
> It's a little more than that; it comes down to the purpose of the regex, and
> how much validation is expected to be provided. For example, ignoring the
> interface designation, the validation of IP addresses between the two
> productions above is radically different. The second one is set up so that
> anything it matches will be a syntactically correct IP address. The first
> one, by contrast, would accept any of the following as valid:
> 
>  * 999.999.999.999
>  * 1.3.6.1.2.1.2.2.1.3
>  * 17
>  * .......

This is a misunderstanding how YANG works. ipv4-address-no-zone is
derived from ipv4-address and hence all the ipv4-address rules apply
as well. Your examples will all be rejected.
 
> This seems a bit more than academic to me: given that modules are included
> into other modules, wild inconsistencies in validation philosophies can be
> surprising to users. For example, if an operator gets used to the syntax for
> IP addresses generating warnings or errors when they are out of range, then
> they may be frustrated to discover that IP addresses in other locations are
> not.
> 
> Clearly, the items that have already been published can't be changed, but it
> seems like there is room for guidance about whether to optimize for simple
> regexes, or for more rigorous ones.

In some cases, patterns are kept simpler but more specific text is in
the description statement. A pattern is one of several mechanisms to
constrain the value space.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>