Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15

Eliot Lear <> Fri, 02 February 2018 07:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A74F3127601 for <>; Thu, 1 Feb 2018 23:48:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id M_6-SZxOwh2P for <>; Thu, 1 Feb 2018 23:48:23 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 187D512EC18 for <>; Thu, 1 Feb 2018 23:48:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=5163; q=dns/txt; s=iport; t=1517557703; x=1518767303; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=FYtGXHhNNGDJaKneN0GVqiK/geYZ0u0QGOxYeJ4pWlc=; b=NCn6Rpnr8Ww8565UAQKuDCclm8Fo4oyPR52g2lcoGIuio5hLXQfoIsjW ALs22Uu5bsm3sEZ86L7139SltVV4Rb7HILGBAhEJRKVeWJU/FZisplBbd SAjdmtOm1z4FdubeJRf/xhvdPJjh4eq3WqVDoMV54RxLYVaAZxHNnlVrG A=;
X-Files: signature.asc : 488
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="5.46,447,1511827200"; d="asc'?scan'208"; a="1755725"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Feb 2018 07:48:19 +0000
Received: from [] ( []) by (8.14.5/8.14.5) with ESMTP id w127mItf011671; Fri, 2 Feb 2018 07:48:19 GMT
To: Kristian Larsson <>,
References: <> <20180117224916.4xtwnxgsw3snzwvf@elstar.local> <> <> <> <> <> <> <>
From: Eliot Lear <>
Message-ID: <>
Date: Fri, 02 Feb 2018 08:48:16 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="lMce1jcIR3bgKI0BPCassgkC5UUCVX1PO"
Archived-At: <>
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 02 Feb 2018 07:48:26 -0000

Hi Kristian,

On 02.02.18 08:44, Kristian Larsson wrote:
> Mahesh,
> I've reviewed this model, I think I largely caused the last couple of
> updates to it late last year. Overall I think it is a good model.
> Placement of feature-statements could be debated - no clear answers.
> object groupings is something I would like to see in the model but it
> was always deferred.
> On 2018-01-22 16:50, Kent Watsen wrote:
>> Hi Mahesh,
>> Thanks, it doesn't get much more concrete then a pull request  ;)
>> Okay, so from a chair/shepherd perspective, can folks please consider
>> this update to -15 as the LC solution to removing the open issue
>> Juergen found in the draft?
>> As a contributor, I don't think the name of the groupings or their
>> description statements should allude to something that doesn't exist
>> yet.  Rather than e.g. "source-or-group", could it be instead
>> something like "source-type"?
> +1
>> Also, the update seems to be for both when specifying networks as
>> well as when specifying port-ranges, but the original issue (see
>> below) only mentioned addresses - is the pull-request actually what's
>> needed and the description of the issue in Section 8 is incomplete?
>>      8.  Open Issues
>>         o  The current model does not support the concept of
>> "containers"
>>              used to contain multiple addresses per rule entry.
> Object groupings are useful whenever there are many of something.
> There are usually more address entries than ports, so perhaps more
> useful for addresses, but it can still be useful to say "NFS-PORTS"
> and mean all the ports that NFS use (god knows what they are).
> Other have mentioned scale ACL and that it can be solved in other
> ways. To me, this sort of object-groupings is not about optimising
> things for the hardware but rather making it easy for me to write
> rules. I think it is paramount for security that ACLs can be easily
> read and understood. If we do not understand them, then we cannot say
> they are effective and secure. Object groupings greatly improves the
> readability of ACLs and thus makes it easier to write secure ACLs.
> I understand the authors wishes to get the first version out the door
> but I can't help but wonder if it isn't just easier to add in object
> groupings now. It's not that damn complicated (they are just lists).
> If not, I'm happy to work with them on the next version which could
> include object groupings.

Please let's aim for the next version.  This document just completed
what I think is its FIFTH last call, which to me is nothing short of insane.


> As for the PR to add choices, there seems to be an extra container
> inserted. I also made a comment on GitHub.
> At the very least, I think it would be best if this PR is fixed and
> merged before we proceed.

>    kll
> _______________________________________________
> netmod mailing list