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 01:33:00AM -0800, Adam Roach wrote:
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 
> §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.
>

RFC 6021 does not define ipv4-address-no-zone, you seem to compare
apples vs. oranges here. The pattern used in the definition of
ipv4-address is pretty much the same in both versions. The reason why
the ipv4-address-no-zone typedef has a rather short pattern is that
the long pattern of inet:ipv4-address still applies (since
ipv4-address-no-zone is derived from ipv4-address).

How detailed should a pattern be? There is as, far as I can tell, no
simply answer or guideline or even consensus on this. It is usually
good if pattern are strict but then complex pattern can get difficult
to read and understand and so there is an engineering trade-off to be
made.

The only thing I could imagine to say in section 4.11.2. is that it is
a good idea to write test cases for longer pattern to ensure they do
what was intended. (This is what I did for the pattern in RFC 6991.) I
do not think it makes sense to publish test cases but it may be useful
to share them during the development of the specification and during
the YANG doctor review.

/js

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