Re: [netmod] New Version Notification for draft-ietf-netmod-acl-model-10.txt

Mahesh Jethanandani <> Fri, 21 April 2017 01:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3DFA9128D69 for <>; Thu, 20 Apr 2017 18:16:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Status: No, score=-2.698 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4Af6mC5n0ZmP for <>; Thu, 20 Apr 2017 18:16:29 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4B07B12EAB1 for <>; Thu, 20 Apr 2017 18:16:29 -0700 (PDT)
Received: by with SMTP id o22so105075330iod.3 for <>; Thu, 20 Apr 2017 18:16:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=gKDSD4QiE84DW1etjmFtjyMGeXPEaTf8vx2iSu0qI2Q=; b=TElpUSNkdW8P794FgF5QP5mwTJDcBAwxDbC9MDpGiN/PkOjyVc+rY2QdPwyNTKF2nb gUkLMcPCPPIRDH7vl+AHhkXcnjQzZh8EEgEsQR+mrvCzN/fMaf1YQgZkGWGd+79buUeM ZycsWvoXBqnfzuTRbHd1r9YqfacNpG1WTpPj52VPfG07plXSWUpYEkHiIgUQm9a+7ox9 UJqFTTqOES1RkU3LLzq4y23iY4DezOXuPAu0ReYZk4R/lRWHs6Wt1MYA56Oa0pDU79+T 65/XVVlfa1V8bsCMuPXzm2phVIIRsRqqdTZ95ixdBmCTYSAPnznKw/PnLUYCp4ks1Mzs Se7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=gKDSD4QiE84DW1etjmFtjyMGeXPEaTf8vx2iSu0qI2Q=; b=PgN9NaEH+c9wD4D8hLO36XEka73M5iZoQ0dS7T3RNWPkzkhm3O47mf2jdw4PECIdZk JfolP3ovPi+bGI5vqkVNFn9NEwZgIRsCg3M/64/l8wQJnBvZwliAtM1AdNYpmb7k6Vz3 VFk/AprQle6ZzHuBWelBS7KWmW8+uCy6fSnleiv45WMqJhPAo/klLpHZZatGKRZsf3qD C5ioOzDvQBWoc2y0veGuHgalPKJu3+9CzuytoREQPGLh+xOgNs1T/4AcVTE6VennfUhs emcDSqaETKpaPCisRDgxs9P07kn8uxPF52jiMhQ/rYNBs7jDqSKG4tUeoZDgjJxZbWfs u0rw==
X-Gm-Message-State: AN3rC/5zoShtSsr/qq8mWGv5e2is4c5m3aMtFOFk/6ffEhmocoEdLRux 6k3c8uPXXPpS7w==
X-Received: by with SMTP id 8mr9977198pgd.208.1492737388512; Thu, 20 Apr 2017 18:16:28 -0700 (PDT)
Received: from ?IPv6:2001:420:30d:1254:8538:d76a:a2a9:9201? ([2001:420:30d:1254:8538:d76a:a2a9:9201]) by with ESMTPSA id t3sm12465064pfi.127.2017. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 20 Apr 2017 18:16:27 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_101A0416-0840-4A34-8B72-B5DBE0A990DA"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mahesh Jethanandani <>
In-Reply-To: <>
Date: Thu, 20 Apr 2017 18:16:25 -0700
Cc: "" <>, Glenn Parsons <>, Norman Finn <>, Marc Holness <mholness@CIENA.COM>, Dan Romascanu <>, Brian Weis <>
Message-Id: <>
References: <> <> <> <> <> <> <>
To: Kent Watsen <>, David Bannister <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Subject: Re: [netmod] New Version Notification for draft-ietf-netmod-acl-model-10.txt
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, 21 Apr 2017 01:16:31 -0000

> On Apr 7, 2017, at 4:33 PM, Kent Watsen <> wrote:
> On 3/28/17, 2:59 PM, "David Bannister" < <>> wrote:
> I would agree that the mix of L2 and L3 in the same operational ACL is a bit out of the ordinary.  I could see where a combined approach may be appealing to some.  As a network operator I do not see this as a negative.  It would be nice to give the vendor the option to defer the L2/3 combination but it does not look attainable in the current model.

I would agree with this assertion. A proposal in the works uses feature statements to let vendors decide which part of the model they want to support.

> "augmented by each vendor"  There are many things missing in IETF models and some things which are not under the IETF umbrella.  In this discussion the first that comes to mind is an 802.x model.  It is good to see there is currently an IEEE effort to develop one.  However, it does not exist today.  The various ether types are covered in some of the vendor models I have seen.  We take the Newco example in the draft which typedefs an enum of 'known-ether-type.'  Meanwhile Oldco is using a typedef of 'ethertype.'  Both New and Old co both augment this draft. In this scenario the network operator is stuck sorting out the logic in which vendor model to use and having to deal with two data structures for the same entity (ether-type).   Using models this way does nothing to simplify network coding and management.  I am against augmentation from vendor models for common items but it is ok for vendor unique items.  Ether-type is not vendor unique.  Augmentation has its place but it appears to be overused even within the context of IETF only models.

I would agree. Ideally, IEEE should take up definition of ether-types that are registered with them and define a ieee-ether-types.yang file. Adding a few folks from IEEE that I know who could look at this.

> Not sure if pointing out ietf-routing was a good idea. Five years in the making and 42 augmenting models. :-)
> If we can get the well known IETF standardized missing bits from L3, L4 for v4 and v6 into this it would work for me but I think the IETF may have missed the boat on this one.

Mahesh Jethanandani