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

Kristian Larsson <> Wed, 08 November 2017 16:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BA997128B37 for <>; Wed, 8 Nov 2017 08:43:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KQc3E6AazIl3 for <>; Wed, 8 Nov 2017 08:43:31 -0800 (PST)
Received: from Mail2.SpriteLink.NET (Mail2.SpriteLink.NET []) by (Postfix) with ESMTP id 753A6128A32 for <>; Wed, 8 Nov 2017 08:43:17 -0800 (PST)
Received: from localhost (localhost []) by Mail2.SpriteLink.NET (Postfix) with ESMTP id 6447726184B; Wed, 8 Nov 2017 17:43:18 +0100 (CET)
X-Virus-Scanned: amavisd-new at SpriteLink.NET
Received: from Mail2.SpriteLink.NET ([]) by localhost (Mail2.SpriteLink.NET []) (amavisd-new, port 10024) with ESMTP id zLdWk-TByqgj; Wed, 8 Nov 2017 17:43:16 +0100 (CET)
Received: from localhost (Mission-Control.SpriteLink.NET []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: kristian@SpriteLink.NET) by Mail2.SpriteLink.NET (Postfix) with ESMTPSA id 41665261846; Wed, 8 Nov 2017 17:43:16 +0100 (CET)
Date: Wed, 08 Nov 2017 17:43:14 +0100
From: Kristian Larsson <>
To: Kent Watsen <>
Cc: "" <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <>
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14
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: Wed, 08 Nov 2017 16:43:34 -0000

On Mon, Nov 06, 2017 at 07:16:11PM +0000, Kent Watsen wrote:
> This closes the Last Call on this document.  There is
> clearly a lot of interest in the publication of an ACL
> model, but there also seems to be significant concern
> for how this model is structured.  It seems that we need
> to spend some more time to ensure the current structure
> is okay.  Based on the result of this discussion, we
> will then judge if this Last Call was successful of not.

I've probably ignited the most recent debate on this model. I'm
sorry for prolonging the process and preventing moving into RFC
but I really am not comfortable with the current structure.

Besides the structure, which is perhaps more subjective, I think
the model contains actual errors. For example, it appears that
there should be stats entries at the interface attachment points
but that data is config true and not config false and the leafref
doesn't match on the acl-type&acl-name so it could point to any
acl-rule!? It's possible to match on conflicting data, like IPv4
and IPv6 or TCP and UDP in the same ACE, which just doesn't make
any sense at all. There is a match on interface but it is not
clear if this is ingress or egress interface. any-acl is empty!?

I am working on a couple of concrete suggestions for making a
more elegant model.


Kristian Larsson                                        KLL-RIPE
+46 72 5479985