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

"Acee Lindem (acee)" <acee@cisco.com> Fri, 09 March 2018 15:35 UTC

Return-Path: <acee@cisco.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 16393126E64; Fri, 9 Mar 2018 07:35:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.529
X-Spam-Level:
X-Spam-Status: No, score=-14.529 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 SJ4nFBIt8As2; Fri, 9 Mar 2018 07:35:46 -0800 (PST)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 276E012E856; Fri, 9 Mar 2018 07:35:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34766; q=dns/txt; s=iport; t=1520609742; x=1521819342; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=oUTTnv1D1j58jtmsccUSMI513Z2af1UEQU58QBtZLjw=; b=BUvnUVQ8AriDrk7oc91eoM4rR/eJFo7vw+tVW8g3vVGmlByILJVJHhXq Kzy+4rd/ThqTFNtImqvWoJ4nSmUvI4Dh1xj4OTsgcvUV2FF0AJYdNb+0L da0gJFw4H12OuOQi5RIKTNn6dE877CoQkq4oXetON6sgQmCEvTtpQS5MW k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DsAADUqKJa/4YNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJaSS1mbygKg0aKHo13ggR7G5Q0ghUKGAEKhDNPAhqCdyE0GAE?= =?us-ascii?q?CAQEBAQEBAmsnhSMBAQEEAQEbBksLEAIBCBEDAQIhBwMCAgIlCxQJCAIEAQ0FF?= =?us-ascii?q?IQhZA+tCYImiGOCFQWFN4Iugzwpgk82gy4BAYFKAT0JFoJTMIIyBIkBkVQJApB?= =?us-ascii?q?ojmGRIAIREwGBKwEeOIFScBU6KgGCGAmCIwUFFxZuAQhud4hBAQElB4EDgRcBA?= =?us-ascii?q?QE?=
X-IronPort-AV: E=Sophos; i="5.47,446,1515456000"; d="scan'208,217"; a="81095641"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Mar 2018 15:35:41 +0000
Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id w29FZepZ012904 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 9 Mar 2018 15:35:41 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-010.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 9 Mar 2018 10:35:40 -0500
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1320.000; Fri, 9 Mar 2018 10:35:40 -0500
From: "Acee Lindem (acee)" <acee@cisco.com>
To: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <rwilton@cisco.com>, Adam Roach <adam@nostrum.com>, Andy Bierman <andy@yumaworks.com>
CC: NetMod WG Chairs <netmod-chairs@ietf.org>, "draft-ietf-netmod-rfc6087bis@ietf.org" <draft-ietf-netmod-rfc6087bis@ietf.org>, The IESG <iesg@ietf.org>, NetMod WG <netmod@ietf.org>
Thread-Topic: [netmod] Adam Roach's No Objection on draft-ietf-netmod-rfc6087bis-18: (with COMMENT)
Thread-Index: AQHTtsB5khxujb0aa0irZaXo8AWveaPHFoWAgABBnICAAPxcgP//to+A
Date: Fri, 9 Mar 2018 15:35:40 +0000
Message-ID: <12782E03-F1DF-4D8B-BC8D-80EFE0EFE4F4@cisco.com>
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>
In-Reply-To: <72ff2814-611e-929d-0e8f-298e26a0da32@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.196]
Content-Type: multipart/alternative; boundary="_000_12782E03F1DF4D8BBC8D80EFE0EFE4F4ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/h3DHq2HDpkDJeXycdWAs-5_kfJk>
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 15:35:48 -0000


From: netmod <netmod-bounces@ietf.org>; on behalf of "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <rwilton@cisco.com>;
Date: Friday, March 9, 2018 at 9:59 AM
To: Adam Roach <adam@nostrum.com>;, Andy Bierman <andy@yumaworks.com>;
Cc: NetMod WG Chairs <netmod-chairs@ietf.org>;, "draft-ietf-netmod-rfc6087bis@ietf.org"; <draft-ietf-netmod-rfc6087bis@ietf.org>;, The IESG <iesg@ietf.org>;, NetMod WG <netmod@ietf.org>;
Subject: Re: [netmod] Adam Roach's No Objection on draft-ietf-netmod-rfc6087bis-18: (with COMMENT)


Hi Adam,

On 08/03/2018 23:55, Adam Roach wrote:
Thanks for your quick response! I have some additional comments inline.
<snip>


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.
I agree with your general sentiment.  In fact I had a long protracted discussion on this point on the Netmod WG alias.

Sometimes pattern statements can be both correct and also concise and readable.  This is the easy case.

But for other regular expressions (e.g. route-target in rfc8294) there is a clear choice whether to make the regex as precise as possible (minimizing false values), or to make it concise and hopefully readable/verifiable but allowing for more false values.

My personal preference is for a simpler, but less precise regex over a more precise, but hard to visually verify, regex.  E.g. I'm not a fan of using regular expressions to limit the range of numerical values.  I know that validating regular expression matches is computationally expensive, so I wonder if implementations will end up replacing these larger regular expressions with custom written verification code that is more performant.  But, as I recall, I was in the rough on this issue.

If the consensus is that they should be as accurate as is feasible then I think that it would be helpful if the guidelines state this as a goal.  This would seem to ensure consistency in the YANG models that are being standardized.

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).

     typedef route-target {
       type string {
         pattern
           '(0:(6553[0-5]|655[0-2][0-9]|65[0-4][0-9]{2}|'
         +     '6[0-4][0-9]{3}|'
         +     '[1-5][0-9]{4}|[1-9][0-9]{0,3}|0):(429496729[0-5]|'
         +     '42949672[0-8][0-9]|'
         +     '4294967[01][0-9]{2}|429496[0-6][0-9]{3}|'
         +     '42949[0-5][0-9]{4}|'
         +     '4294[0-8][0-9]{5}|429[0-3][0-9]{6}|'
         +     '42[0-8][0-9]{7}|4[01][0-9]{8}|'
         +     '[1-3][0-9]{9}|[1-9][0-9]{0,8}|0))|'
         + '(1:((([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|'
         +     '25[0-5])\.){3}([0-9]|[1-9][0-9]|'
         +     '1[0-9]{2}|2[0-4][0-9]|25[0-5])):(6553[0-5]|'
         +     '655[0-2][0-9]|'
         +     '65[0-4][0-9]{2}|6[0-4][0-9]{3}|'
         +     '[1-5][0-9]{4}|[1-9][0-9]{0,3}|0))|'
         + '(2:(429496729[0-5]|42949672[0-8][0-9]|'
         +     '4294967[01][0-9]{2}|'
         +     '429496[0-6][0-9]{3}|42949[0-5][0-9]{4}|'
         +     '4294[0-8][0-9]{5}|'
         +     '429[0-3][0-9]{6}|42[0-8][0-9]{7}|4[01][0-9]{8}|'
         +     '[1-3][0-9]{9}|[1-9][0-9]{0,8}|0):'
         +     '(6553[0-5]|655[0-2][0-9]|65[0-4][0-9]{2}|'
         +     '6[0-4][0-9]{3}|'
         +     '[1-5][0-9]{4}|[1-9][0-9]{0,3}|0))|'
         + '(6(:[a-fA-F0-9]{2}){6})|'
         + '(([3-57-9a-fA-F]|[1-9a-fA-F][0-9a-fA-F]{1,3}):'
         +     '[0-9a-fA-F]{1,12})';
       }

       description
         "A Route Target is an 8-octet BGP extended community
          initially identifying a set of sites in a BGP VPN
          (RFC 4364).  However, it has since taken on a more general
          role in BGP route filtering.  A Route Target consists of two
          or three fields: a 2-octet Type field, an administrator
          field, and, optionally, an assigned number field.

          According to the data formats for types 0, 1, 2, and 6 as
          defined in RFC 4360, RFC 5668, and RFC 7432, the encoding
          pattern is defined as:

          0:2-octet-asn:4-octet-number
          1:4-octet-ipv4addr:2-octet-number
          2:4-octet-asn:2-octet-number
          6:6-octet-mac-address

          Additionally, a generic pattern is defined for future
          Route Target types:

          2-octet-other-hex-number:6-octet-hex-number

          Some valid examples are 0:100:100, 1:1.1.1.1:100,
          2:1234567890:203, and 6:26:00:08:92:78:00.";
       reference
         "RFC 4360: BGP Extended Communities Attribute.
          RFC 4364: BGP/MPLS IP Virtual Private Networks (VPNs).
          RFC 5668: 4-Octet AS Specific BGP Extended Community.
          RFC 7432: BGP MPLS-Based Ethernet VPN.";
     }

I don’t know that we want to debate this again during the IESG comments for RFC6087BIS. .

Thanks,
Acee



Thanks,
Rob



/a




_______________________________________________

netmod mailing list

netmod@ietf.org<mailto:netmod@ietf.org>

https://www.ietf.org/mailman/listinfo/netmod