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

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Thu, 08 March 2018 11:32 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
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 EEAB61242F7; Thu, 8 Mar 2018 03:32:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
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 y9BwCxqLjTu5; Thu, 8 Mar 2018 03:32:26 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F664124239; Thu, 8 Mar 2018 03:32:26 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 0FF7A40; Thu, 8 Mar 2018 12:32:25 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id K9N5hoHT2ygZ; Thu, 8 Mar 2018 12:32:23 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 8 Mar 2018 12:32:24 +0100 (CET)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id DC0B62015B; Thu, 8 Mar 2018 12:32:24 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id xGhJymcn6AAM; Thu, 8 Mar 2018 12:32:24 +0100 (CET)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6C3A220160; Thu, 8 Mar 2018 12:32:24 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 378F34267C9E; Thu, 8 Mar 2018 12:32:24 +0100 (CET)
Date: Thu, 8 Mar 2018 12:32:24 +0100
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Adam Roach <adam@nostrum.com>
Cc: The IESG <iesg@ietf.org>, netmod-chairs@ietf.org, netmod@ietf.org, draft-ietf-netmod-rfc6087bis@ietf.org
Message-ID: <20180308113224.rzeops77x6a7wary@elstar.local>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: Adam Roach <adam@nostrum.com>, The IESG <iesg@ietf.org>, netmod-chairs@ietf.org, netmod@ietf.org, draft-ietf-netmod-rfc6087bis@ietf.org
References: <152050158005.21412.3389388204390015375.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: <152050158005.21412.3389388204390015375.idtracker@ietfa.amsl.com>
User-Agent: NeoMutt/20171215
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/jeF2cHrzmnAYVwkDnCgYDcvnniw>
Subject: Re: [netmod] Adam Roach's No Objection on draft-ietf-netmod-rfc6087bis-18: (with COMMENT)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 08 Mar 2018 11:32:29 -0000

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: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>