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

Adam Roach <adam@nostrum.com> Fri, 09 March 2018 20:17 UTC

Return-Path: <adam@nostrum.com>
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 2FEFA120047; Fri, 9 Mar 2018 12:17:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=unavailable 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 2PmRQqjUFuHp; Fri, 9 Mar 2018 12:17:26 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D177D1275F4; Fri, 9 Mar 2018 12:17:25 -0800 (PST)
Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w29KHGNO093617 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 9 Mar 2018 14:17:19 -0600 (CST) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local
To: "Acee Lindem (acee)" <acee@cisco.com>, "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <rwilton@cisco.com>, Andy Bierman <andy@yumaworks.com>
Cc: NetMod WG Chairs <netmod-chairs@ietf.org>, NetMod WG <netmod@ietf.org>, The IESG <iesg@ietf.org>, "draft-ietf-netmod-rfc6087bis@ietf.org" <draft-ietf-netmod-rfc6087bis@ietf.org>
References: <152050158005.21412.3389388204390015375.idtracker@ietfa.amsl.com> <CABCOCHSmCioJPNM5b9J-5WCsXe_J2jMzKKCD8fw02uh-D5nNdA@mail.gmail.com> <e627d122-a709-c41c-b58a-b5890b8d2103@nostrum.com> <72ff2814-611e-929d-0e8f-298e26a0da32@cisco.com> <12782E03-F1DF-4D8B-BC8D-80EFE0EFE4F4@cisco.com>
From: Adam Roach <adam@nostrum.com>
Message-ID: <c59fea46-fe0f-3995-cdb0-60c41a3a8f7e@nostrum.com>
Date: Fri, 9 Mar 2018 14:17:11 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <12782E03-F1DF-4D8B-BC8D-80EFE0EFE4F4@cisco.com>
Content-Type: multipart/alternative; boundary="------------7940F3F1AFA9CA591DE36030"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/afqWVZ2-NMYoLIBARTGNfuc58Us>
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: Fri, 09 Mar 2018 20:17:28 -0000

On 3/9/18 9:35 AM, Acee Lindem (acee) wrote:
>
> As the editor of RFC 8294, I can confirm that we did not reach 
> consensus on whether to use easily understandable regular expressions 
> versus regular expressions that precisely validate the input string. 
> During the protracted Working Group last call for this document, there 
> were strong proponents of both lines of thinking. Given that we had 
> started with the more complex precise regular expressions, that is 
> what was retained (e.g., for BGP route-targets).
>

Okay, this is helpful input.

I raised the issue because rfc6087bis appears to be designed as a style 
guide. Having reviewed several YANG modules and seeing somewhat varied 
philosophies in this regard, it seemed like a prime candidate for 
including in such a guide, and I brought it up only because it was 
conspicuous by its absence. I wasn't intending to express a preference 
for one end of the spectrum or the other; I simply thought it was 
something that belonged in the document.

I can't determine from the conversation so far whether the discussions 
on rfc6087bis explicitly included this topic and decided not to cover 
it, or whether it was simply not brought up. However, the quoted text 
above tells me that reaching a quick consensus by the community of 
interest on the topic is pretty unlikely. Consequently, including such 
guidance probably means that the working group will need to have 
additional conversations about what such guidance would say. I'll leave 
it to the responsible AD to determine whether the document should go 
back to the working group for explicit consideration of this topic, or 
whether it should move forward without any guidance on the topic of 
regex completelness-versus-simplicity trade-offs.

/a