Re: [netmod] ACL draft issues found during shepherd writeup

Mahesh Jethanandani <mjethanandani@gmail.com> Tue, 27 February 2018 17:14 UTC

Return-Path: <mjethanandani@gmail.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 1F241124F57; Tue, 27 Feb 2018 09:14:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 vSmG2nSGB6wm; Tue, 27 Feb 2018 09:14:28 -0800 (PST)
Received: from mail-pl0-x232.google.com (mail-pl0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) (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 8A437126B72; Tue, 27 Feb 2018 09:14:28 -0800 (PST)
Received: by mail-pl0-x232.google.com with SMTP id y8-v6so1293072pll.13; Tue, 27 Feb 2018 09:14:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=14qLO3dih/i1NiN4iPOCeoWUPao+qqGSb0wCzVtbS4c=; b=ZjAnNSMFvHOiSYpORcvq+BMapmmPFAr4wBaawCekv6BqJOEz2sb0+mNB/VTXNnRAQf jciSd+IOWXGk86gryRPSgWX43bY1AbbwigqjIeLn7l1HNZOr0Ivt2rjLYpe5YDDb6vPi /EN5SW6VKnq7494NrQDaPnEQT2dTwbL4umg1PawPJ2btYrpkDEfyI9fnyJoEqr6tV4t1 4Vdg7CRgmHONMYw4b3zSmd7Pl53z/jLtvUm9tF3afySln3xl5dEZiSPo9N7/peZznH0u b2KQqC88BMoge5jxNgUS9d33UhDHq5UqQNj2sJxB6jYkugn/V7K5fMJUMleHBTaF+AAx Pxvg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=14qLO3dih/i1NiN4iPOCeoWUPao+qqGSb0wCzVtbS4c=; b=n/nEdjoR978Na2KmdHMtGx22tXTn+4iv/EWYi7G0hoKoUeO95j/1aPD6AENvIbP+3y R6blVw6RHySs31NqSsEqDfP1WGkpMmiJW4xXk014P5D6VSoyRie56LuLa08XTCYgq4UC +v6OY9x2lBnspnF1Hm8RoamniT2jRzTkR2msGTcfBufeedfgWxULcm+4/3uonWY/fTCx jjiqVdJsuRlfmo5WZR6rOFvnc/mn2y5QM1sYl4sac+Ai20qW5MBPft9lFosvs45kRAAI 5St04drMk0CQ6kbodGxm7JPyZyASv6+XUws+dJZ616g3EcU515d8CcaqdBAMCMPowqQe Sqdg==
X-Gm-Message-State: APf1xPCs42LERQCdOm59jhhmNVXioDL4mzndcnZZSKWonhx06dWimeBa +fABY1o9idWk8qYDvlkBUMsIUG3c
X-Google-Smtp-Source: AH8x227wpfZWVbGU1HeergPBuDCEOkWeNwLc0lRYp/U3LK+7FGV5UFAYgaQjwLJBbS8yyMJbql7USg==
X-Received: by 2002:a17:902:5a5:: with SMTP id f34-v6mr15182937plf.134.1519751667992; Tue, 27 Feb 2018 09:14:27 -0800 (PST)
Received: from ?IPv6:2601:647:4700:1280:e12d:29bc:1dca:d2aa? ([2601:647:4700:1280:e12d:29bc:1dca:d2aa]) by smtp.gmail.com with ESMTPSA id p10sm22925389pfe.187.2018.02.27.09.14.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Feb 2018 09:14:27 -0800 (PST)
From: Mahesh Jethanandani <mjethanandani@gmail.com>
Message-Id: <8004EA4C-24D2-4969-B8EB-E678C54D254A@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_065A2B8B-5561-41ED-A347-6692B1CA5001"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Tue, 27 Feb 2018 09:20:18 -0800
In-Reply-To: <DC341012-FDF8-45D3-BCA5-F4B7E1BCC2EE@cisco.com>
Cc: Eliot Lear <lear@cisco.com>, Warren Kumari <warren@kumari.net>, "draft-ietf-netmod-acl-model@ietf.org" <draft-ietf-netmod-acl-model@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>
To: "Einar Nilsen-Nygaard (einarnn)" <einarnn@cisco.com>
References: <14BA9086-69D4-4BAF-A7C7-0EB1F3F400BB@juniper.net> <2864E0CF-D038-4FDA-B69C-FD43F486BF17@gmail.com> <8D3773A8-ECA6-406A-B28D-6DD44F951F10@juniper.net> <02D4541E-FF83-41AD-A026-A1AB857E0A62@gmail.com> <1a4a3f5d-5211-8b13-308e-3b124c836135@cisco.com> <DD6A8E90-53DE-422F-AB91-A3547298A135@gmail.com> <d7bef5fa-b790-2562-c17b-7ef5dc4f3307@cisco.com> <DC341012-FDF8-45D3-BCA5-F4B7E1BCC2EE@cisco.com>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/ssqGmpuCFTIF9a97rkQTw_DQuJg>
Subject: Re: [netmod] ACL draft issues found during shepherd writeup
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: Tue, 27 Feb 2018 17:14:31 -0000

Guys,

Before we start proposing whole set of changes, please verify that the model is not doing what it was supposed to. The only difference between the changes below and what is in the model is that instead of it being a repeat for source and destination ports, the code below exists as a grouping.

Cheers.

> On Feb 27, 2018, at 3:01 AM, Einar Nilsen-Nygaard (einarnn) <einarnn@cisco.com> wrote:
> 
> What Kristian and I discussed, what Sonal and I had discussed, and what I thought we had accepted as a proposed change was something like:
> 
>     choice source-port-range-or-operator {
>       case range {
>         leaf source-port-lower {
>           type inet:port-number;
>           must ". <= ../source-port-upper" {
>             error-message
>               "The source-port-lower must be less than or equal to
>                source-port-upper";
>           }
>           mandatory true;
>           description
>             "Lower boundary for port.";
>         }
>         leaf source-port-upper {
>           type inet:port-number;
>           mandatory true;
>           description
>             "Lower boundary for port.";
>         }
>       }
>       case operator {
>         leaf source-operator {
>           type operator;
>           mandatory true;
>         }
>         leaf source-port {
>           type inet:port-number;
>           mandatory true;
>           description
>             "Port value to match.";
>         }
>       }
>     }
> 
> …and with the same pattern for the destination. The type “operator” was defined as:
> 
>   typedef operator {
>     type enumeration {
>       enum lte {
>         description
>           "Less than or equal to.";
>       }
>       enum gte {
>         description
>           "Greater than or equal to.";
>       }
>       enum eq {
>         description
>           "Equal to.";
>       }
>       enum neq {
>         description
>           "Not equal to.";
>       }
>     }
> 
> Cheers,
> 
> Einar
> 
> 
>> On 27 Feb 2018, at 09:20, Eliot Lear <lear@cisco.com <mailto:lear@cisco.com>> wrote:
>> 
>> This edit doesn't seem correct to me because now we have a choice with a single case, with range having been removed.  Can we please revert and proceed?
>> 
>> On 26.02.18 20:24, Mahesh Jethanandani wrote:
>>> A pull request to address LC, shepherd, this and the other comments, including derived-from(), can be reviewed here:
>>> 
>>> https://github.com/netmod-wg/acl-model/pull/24 <https://github.com/netmod-wg/acl-model/pull/24>
>>> 
>>> Thanks.
>>> 
>>>> On Feb 26, 2018, at 12:15 AM, Eliot Lear <lear@cisco.com <mailto:lear@cisco.com>> wrote:
>>>> 
>>>> 
>>>> 
>>>> On 26.02.18 06:55, Mahesh Jethanandani wrote:
>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>  PS: And this is not a shepherd directive, but I found the whole 
>>>>>>>      "source-port-range-or-operator" syntax clumsy.  I'm surprised
>>>>>>>      it didn't look something like:
>>>>>>> 
>>>>>>>          OLD
>>>>>>>                <source-port-range-or-operator>
>>>>>>>                   <port-range-or-operator>
>>>>>>>                     <range>
>>>>>>>                       <lower-port>16384</lower-port>
>>>>>>>                       <upper-port>65535</upper-port>
>>>>>>>                     </range>
>>>>>>>                   </port-range-or-operator>
>>>>>>>                </source-port-range-or-operator>
>>>>>>> 
>>>>>>>                <source-port-range-or-operator>
>>>>>>>                  <port-range-or-operator>
>>>>>>>                    <operator>
>>>>>>>                      <operator>eq</operator>
>>>>>>>                      <port>21</port>
>>>>>>>                    </operator>
>>>>>>>                  </port-range-or-operator>
>>>>>>>                </source-port-range-or-operator>
>>>>>>> 
>>>>>>>          NEW
>>>>>>> 
>>>>>>>                <source-port>
>>>>>>>                  <range>
>>>>>>>                    <lower>16384</lower>
>>>>>>>                    <upper>65535</upper>
>>>>>>>                  </range>
>>>>>>>                </source-port>
>>>>>>> 
>>>>>>>                <source-port>
>>>>>>>                  <operator>
>>>>>>>                    <operator>eq</operator>
>>>>>>>                    <port>21</port>
>>>>>>>                  </operator>
>>>>>>>                </source-port>
>>>>>>> 
>>>>>>  
>>>>>> Did you try making the change in the model to see if it work? It will complain that <range> is already used within the container and that it cannot be repeated (for destination-port).
>>>>>> 
>>>>>> <KENT> No, I did not, nor do I intend to get that deep into it.  But I recall that Kristian made the same comment before, and was making pull requests before, so maybe he can suggest something?
>>>>> 
>>>>> Kristian’s suggestion requires changing the module. It is not an editorial change. And that change will have an impact on the MUD draft, which has been sent for publication. 
>>>>> 
>>>> 
>>>> As it happens, we found a bug in our augment statements, and so we will need to rev one more time.  If the change can be made quickly, I can live with it.
>>>> 
>>>> Eliot
>>> 
>>> Mahesh Jethanandani
>>> mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>
>> 
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org <mailto:netmod@ietf.org>
>> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>
> 

Mahesh Jethanandani
mjethanandani@gmail.com