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

2018-01-16 Thread Sonal Agarwal
I have reviewed the changes and they look good to me. Thanks, Sonal. On Fri, Jan 12, 2018 at 2:07 PM, Mahesh Jethanandani < mjethanand...@gmail.com> wrote: > An updated version of the draft, along with changes to remove icmp-off > from the model, and updates to examples has been posted in the

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

2018-01-12 Thread Mahesh Jethanandani
An updated version of the draft, along with changes to remove icmp-off from the model, and updates to examples has been posted in the PR here . If there are no objections to the changes by Tuesday, I will pull in the PR, and publish the draft.

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

2018-01-11 Thread Einar Nilsen-Nygaard (einarnn)
On Jan 11, 2018, at 04:16, Mahesh Jethanandani > wrote: On Jan 10, 2018, at 12:58 AM, Einar Nilsen-Nygaard (einarnn) > wrote: Mahesh, Two things: First, I see that you have still left in

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

2018-01-11 Thread Einar Nilsen-Nygaard (einarnn)
Yes, the ACL model supports ingress and egress rules that can be different. > On Jan 11, 2018, at 07:00, Juergen Schoenwaelder > wrote: > >> On Wed, Jan 10, 2018 at 08:16:13PM -0800, Mahesh Jethanandani wrote: >> >> >>> On Jan 10, 2018, at 12:58 AM,

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

2018-01-10 Thread Juergen Schoenwaelder
On Wed, Jan 10, 2018 at 08:16:13PM -0800, Mahesh Jethanandani wrote: > > > > On Jan 10, 2018, at 12:58 AM, Einar Nilsen-Nygaard (einarnn) > > wrote: > > > > Mahesh, > > > > Two things: > > > > First, I see that you have still left in the “icmp-off” action. This was > >

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

2018-01-10 Thread Mahesh Jethanandani
> On Jan 10, 2018, at 12:58 AM, Einar Nilsen-Nygaard (einarnn) > wrote: > > Mahesh, > > Two things: > > First, I see that you have still left in the “icmp-off” action. This was > something both Kristian and I recommended removing, and I also discussed this > with Sonal

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

2018-01-10 Thread Mahesh Jethanandani
Hi Einar, I can work on updating the draft as soon as we agree on the changes. Should take only a couple of days to turn around and publish the draft. > On Jan 9, 2018, at 11:35 PM, Eliot Lear wrote: > > Hi Mahesh, > > Thanks for this work. I think this is okay. In the case

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

2018-01-10 Thread Einar Nilsen-Nygaard (einarnn)
Mahesh, Two things: First, I see that you have still left in the “icmp-off” action. This was something both Kristian and I recommended removing, and I also discussed this with Sonal at the end of last year and she agreed that it should probably be removed since it seems at this point (absent

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

2018-01-09 Thread Eliot Lear
Hi Mahesh, Thanks for this work.  I think this is okay.  In the case of MUD we simply won't have the other container.  Can I please ask that you get the draft out quickly as draft-ietf-opsawg-mud has been waiting quite some time for this work to complete. Eliot On 10.01.18 04:08, Mahesh

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

2018-01-09 Thread Mahesh Jethanandani
I have pulled in the changes as they relate to: - moving “interface-acl” under the container “attachment-points” making it local to that container. - reverting “acl-type” to “type” - removed “interface-all-aggregate” feature - simplified source port and destination port definition The pull

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

2017-12-18 Thread Eliot Lear
Presuming this issue is behind us, are all WGLC comments addressed?  Can we expect to see a new draft soon? Eliot On 18.12.17 13:31, Eliot Lear wrote: > > So long as nobody expects an interface construct in a MUD file, I'm happy. > > > On 17.12.17 15:34, Einar Nilsen-Nygaard (einarnn) wrote: >>

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

2017-12-18 Thread Eliot Lear
So long as nobody expects an interface construct in a MUD file, I'm happy. On 17.12.17 15:34, Einar Nilsen-Nygaard (einarnn) wrote: > Eliot, > > Nothing can force an implementation to have to implement either > the ietf-interfaces model or the augmentation in the > ietf-access-control-list

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

2017-12-17 Thread Einar Nilsen-Nygaard (einarnn)
Eliot, Nothing can force an implementation to have to implement either the ietf-interfaces model or the augmentation in the ietf-access-control-list model. I appreciate your desire for modularity and cohesiveness, but I would resist #1, because I feel that the majority of users will be

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

2017-12-17 Thread Eliot Lear
On 17.12.17 13:00, Juergen Schoenwaelder wrote: > On Sun, Dec 17, 2017 at 12:29:50PM +0100, Eliot Lear wrote: > >> I would rather the augment to the interface not be required for >> implementations that don't actually have interfaces. > Do you have an example of such a device / implementation? >

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

2017-12-17 Thread Juergen Schoenwaelder
On Sun, Dec 17, 2017 at 12:29:50PM +0100, Eliot Lear wrote: > I would rather the augment to the interface not be required for > implementations that don't actually have interfaces. Do you have an example of such a device / implementation? /js -- Juergen Schoenwaelder Jacobs

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

2017-12-17 Thread Eliot Lear
Einar, I think this change is fine, with one exception.  I would rather the augment to the interface not be required for implementations that don't actually have interfaces.  I understand that there may be two ways to go about this: 1. Separate out the augment into a separate module (same doc

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

2017-12-16 Thread Einar Nilsen-Nygaard (einarnn)
All, After a series of discussions on- and off-list, I have a candidate PR that includes the changes in the PR Mahesh sent out plus some more edits. Please see consolidated PR here: https://github.com/netmod-wg/acl-model/pull/21 Main changes in addition to Mahesh’s PR are: * Moved

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

2017-12-14 Thread Einar Nilsen-Nygaard (einarnn)
On 14 Dec 2017, at 08:21, Sonal Agarwal > wrote: Hi Einar, You had 3 questions for me on all the several e-mail threads. 1. Global attachment point 2. icmp-off 3. acl-aggregate-interface stats. For (1), my first preference is to have the

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

2017-12-14 Thread Sonal Agarwal
Hi Einar, You had 3 questions for me on all the several e-mail threads. 1. Global attachment point 2. icmp-off 3. acl-aggregate-interface stats. For (1), my first preference is to have the model define attachment point for interfaces only. However, Kristian wants the global attachment point as

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

2017-12-13 Thread Einar Nilsen-Nygaard (einarnn)
Tom, If we were to introduce this, yes, that (or some similar term) may help clarify. But I think that at the moment we have suggested that we leave this issue out of the initial draft until it is better understood what we should specify. I think the question at this point is whether explicit

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

2017-12-13 Thread Thomas Nadeau
Maybe it would help to say “to all interfaces” instead of “globally”? —Tom > On Dec 13, 2017, at 4:15 PM, Einar Nilsen-Nygaard (einarnn) > wrote: > > I’m not sure we have a clear enough common understanding of “global” as yet > to be able to say that we

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

2017-12-13 Thread Einar Nilsen-Nygaard (einarnn)
I’m not sure we have a clear enough common understanding of “global” as yet to be able to say that we should make the provisioning of an ACL on an interface or “globally” mutually exclusive in the model. I think attaching an ACL to a specific interface in either the ingress or egress direction

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

2017-12-13 Thread Mahesh Jethanandani
You can use the same ACL definition to attach to different points in the system, provided they do not overlap. Otherwise, you are just wasting CAM entries. Global and interface attachment points will overlap with each other, because global means ‘any’ interface. > On Dec 13, 2017, at 12:40 PM,

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

2017-12-13 Thread Einar Nilsen-Nygaard (einarnn)
We need to be able to attach any one ACL to a whole range of different places. Just speaking from the Cisco platform perspective, I may attach an ACL to: * Interfaces * NAT configuration * Class maps for QoS policy * Class maps for FW policy * …etc… Not sure if we have any

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

2017-12-13 Thread Mahesh Jethanandani
My understanding is that you would attach an ACL either to an interface or globally. Not both. > On Dec 13, 2017, at 12:25 PM, Einar Nilsen-Nygaard (einarnn) > wrote: > > I’m happy to have a way to attach an ACL globally, but that’s orthogonal to > attaching to an

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

2017-12-13 Thread Einar Nilsen-Nygaard (einarnn)
I’m happy to have a way to attach an ACL globally, but that’s orthogonal to attaching to an interface, isn’t it? Attaching ACLs directly to an interface doesn’t preclude global attachment in any way as far as I can see…or have I missed something? I’m not sure I understand why choices are an

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

2017-12-13 Thread Mahesh Jethanandani
We want to support “global” attachment point down the line, and that “global” attachment point will be one of the choices (the other being the interface), what would this augment look like. Note, as far as I know, you cannot augment inside a choice node. > On Dec 13, 2017, at 6:57 AM, Einar

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

2017-12-13 Thread Eliot Lear
I like this because ACLs will be used in many different ways, and expecting that a single model be augmented for each attachment seems a bit unrealistic. Eliot On 12/13/17 3:57 PM, Einar Nilsen-Nygaard (einarnn) wrote: > Perhaps like this, as an augmentation to the interface: > >   augment

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

2017-12-13 Thread Einar Nilsen-Nygaard (einarnn)
Perhaps like this, as an augmentation to the interface: augment /if:interfaces/if:interface: +--rw ingress-acls | +--rw acl-sets | +--rw acl-set* [name] |+--rw name -> /access-lists/acl/name |+--rw type? -> /access-lists/acl/type

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

2017-12-06 Thread Eliot Lear
On 12/6/17 7:23 PM, Mahesh Jethanandani wrote: > How does one move the interface attachment point, currently an > 'interface-ref', to an augmentation of the if:interfaces/interface, > inside of the ‘acl’  container? Down the line we might need to have an > container for "attachment points" to

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

2017-12-06 Thread Mahesh Jethanandani
Moving to the next issue on the list > On Nov 3, 2017, at 1:42 AM, Kristian Larsson wrote: > >> Personally, I would put the ACL interface attachment points as an >> augmentation of if:interfaces/interface rather than having a separate top >> level list, but perhaps that

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

2017-11-08 Thread Kristian Larsson
On Mon, Nov 06, 2017 at 07:16:11PM +, 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

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

2017-11-07 Thread Kristian Larsson
On Sat, Nov 04, 2017 at 10:38:45AM -0700, Sonal Agarwal wrote: > Kristian, > > In response to one of your previous comments: > > "I'm really bothered by the compound key consisting of acl-type > and the acl-name since attachment points then need to reference > both.  It's also weird because I

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

2017-11-07 Thread Eliot Lear
Kent, Can you or the chairs please summarize what issues need to be addressed?  We are in a place where we end up in endless last calls, and that is bad. Eliot On 11/7/17 12:46 AM, Kent Watsen wrote: > This closes the Last Call on this document. There is > clearly a lot of interest in the

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

2017-11-06 Thread Kent Watsen
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

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

2017-11-04 Thread Sonal Agarwal
On Fri, Nov 3, 2017 at 3:40 AM, Robert Wilton wrote: > > > On 03/11/2017 10:12, Kristian Larsson wrote: > >> On Fri, Nov 03, 2017 at 09:30:01AM +, Robert Wilton wrote: >> >>> >>> On 03/11/2017 08:42, Kristian Larsson wrote: >>> On Thu, Nov 02, 2017 at 05:38:02PM

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

2017-11-04 Thread Sonal Agarwal
Kristian, In response to one of your previous comments: *"I'm really bothered by the compound key consisting of acl-type* *and the acl-name since attachment points then need to referenceboth. It's also weird because I don't think choosing theacl-type is really a choice of the user but

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

2017-11-03 Thread Mahesh Jethanandani
Please do, and we can discuss the changes on the mailing list. Thanks. Mahesh Jethanandani mjethanand...@gmail.com > On Nov 3, 2017, at 2:22 PM, Kristian Larsson wrote: > >> On Thu, Nov 02, 2017 at 07:10:30PM +0630, Mahesh Jethanandani wrote: >> Ok. Will update the

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

2017-11-03 Thread Robert Wilton
On 03/11/2017 10:12, Kristian Larsson wrote: On Fri, Nov 03, 2017 at 09:30:01AM +, Robert Wilton wrote: On 03/11/2017 08:42, Kristian Larsson wrote: On Thu, Nov 02, 2017 at 05:38:02PM +, Robert Wilton wrote: On 02/11/2017 16:41, Kristian Larsson wrote: Are we seeking to have a

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

2017-11-03 Thread Robert Wilton
On 03/11/2017 08:42, Kristian Larsson wrote: On Thu, Nov 02, 2017 at 05:38:02PM +, Robert Wilton wrote: On 02/11/2017 16:41, Kristian Larsson wrote: On Thu, Nov 02, 2017 at 12:53:29PM +, Robert Wilton wrote: feature mixed-ipv4-acl { if-feature "match-on-l2-eth-hdr and

Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14 - acl-type in list key?

2017-11-03 Thread Kristian Larsson
Another question somewhat related to attachment point. Why is acl-type part of the list key? I think compound keys are really quite clunky and should be avoided if possible. In this case I really don't see why acl-type needs to be part of the list key. For the list of ACLs it means that the

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

2017-11-03 Thread Kristian Larsson
On Thu, Nov 02, 2017 at 07:10:30PM +0630, Mahesh Jethanandani wrote: > Ok. Will update the model to reflect the discussion on this thread. Mahesh, would it be helpful if I prepared changes in the form of pull requests on the github repo? I can write code, we can discuss it here and merge once

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

2017-11-03 Thread Kristian Larsson
On Thu, Nov 02, 2017 at 03:20:34PM +0630, Mahesh Jethanandani wrote: > Kristian, > > I hear you. What I am providing is the rational for the current design. Ok, thank you! That is valuable to me so please don't stop :) > I would like to hear from others in the WG. We have been > reviewing

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

2017-11-03 Thread Kristian Larsson
On Thu, Nov 02, 2017 at 05:38:02PM +, Robert Wilton wrote: > > > On 02/11/2017 16:41, Kristian Larsson wrote: > >On Thu, Nov 02, 2017 at 12:53:29PM +, Robert Wilton wrote: > >> feature mixed-ipv4-acl { > >> if-feature "match-on-l2-eth-hdr and "match-on-ipv4-hdr"; > >> 

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

2017-11-02 Thread Robert Wilton
On 02/11/2017 16:41, Kristian Larsson wrote: On Thu, Nov 02, 2017 at 12:53:29PM +, Robert Wilton wrote: One further refinement might also be to make the ACL type features a bit more hierarchical as well, but I don't know if that makes it too complex? I was pondering this for a bit but

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

2017-11-02 Thread Kristian Larsson
On Thu, Nov 02, 2017 at 12:53:29PM +, Robert Wilton wrote: > One further refinement might also be to make the ACL type features a bit more > hierarchical as well, but I don't know if that makes it too complex? I was pondering this for a bit but I'm not sure it actually helps. > For example,

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

2017-11-02 Thread Robert Wilton
On 02/11/2017 12:26, Martin Bjorklund wrote: Robert Wilton wrote: Hi Mahesh, I also think that the model would be cleaner if you don't have separate containers for each "type of ACL".  In particular, I think that the model is easier for clients, and perhaps easier to

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

2017-11-02 Thread Mahesh Jethanandani
Ok. Will update the model to reflect the discussion on this thread. Mahesh Jethanandani mjethanand...@gmail.com > On Nov 2, 2017, at 6:56 PM, Martin Bjorklund wrote: > > Robert Wilton wrote: >> Hi Mahesh, >> >> I also think that the model would be cleaner

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

2017-11-02 Thread Martin Bjorklund
Robert Wilton wrote: > Hi Mahesh, > > I also think that the model would be cleaner if you don't have > separate containers for each "type of ACL".  In particular, I think > that the model is easier for clients, and perhaps easier to implement, > if a given ACE field is always

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

2017-11-02 Thread Dean Bogdanovic
I agree with points raised by Juergen and Kristian. Because of design changes I have stepped down as co-author of the draft. > On Nov 2, 2017, at 4:50 AM, Mahesh Jethanandani > wrote: > > Kristian, > > I hear you. What I am providing is the rational for the current

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

2017-11-02 Thread Mahesh Jethanandani
Kristian, I hear you. What I am providing is the rational for the current design. I would like to hear from others in the WG. We have been reviewing this draft for the last couple of years, and we are now at the tail end of the LC. I would really like to see this draft move forward,

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

2017-11-02 Thread Juergen Schoenwaelder
On Thu, Nov 02, 2017 at 06:13:04AM +0630, Mahesh Jethanandani wrote: > > Take the case where the desired selection is l2,-l3, ipv4 and ipv6. The > current tree looks like this: > [...] > whereas, if the design went with one match container with each group of leafs > in their own container

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

2017-11-02 Thread Kristian Larsson
On Thu, Nov 02, 2017 at 06:13:04AM +0630, Mahesh Jethanandani wrote: > On Nov 1, 2017, at 5:52 PM, Juergen Schoenwaelder < > j.schoenwael...@jacobs-university.de> wrote: > > Mahesh, > > I think the question is why we need to have different match containers > for each possible

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

2017-11-01 Thread Mahesh Jethanandani
Kristian, > On Nov 1, 2017, at 10:27 PM, Kristian Larsson wrote: > > I think there's a problem with the current approach for features > where it conflates the limitations of the device with the > limitations of an attachment point. Ultimately it is the > limitations of

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

2017-11-01 Thread Mahesh Jethanandani
Juergen, > On Nov 1, 2017, at 5:52 PM, Juergen Schoenwaelder > wrote: > > Mahesh, > > I think the question is why we need to have different match containers > for each possible feature set combination instead of having a single > match container with

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

2017-11-01 Thread Kristian Larsson
I think there's a problem with the current approach for features where it conflates the limitations of the device with the limitations of an attachment point. Ultimately it is the limitations of the attachment point that matter. Creating an ACL in config on a device doesn't actually mean anything

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

2017-11-01 Thread Kristian Larsson
Mahesh, On Wed, Nov 01, 2017 at 05:13:18PM +0630, Mahesh Jethanandani wrote: > I think there is confusion in how the ACL model is going to be > implemented by vendors and used by customers. > > As Eliot alluded to, the model is trying to address the issue > of the capabilities of each platform as

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

2017-11-01 Thread Juergen Schoenwaelder
Mahesh, I think the question is why we need to have different match containers for each possible feature set combination instead of having a single match container with groups of leafs in it marked as features. This would seem to cut down the size of the module and the tree diagram significantly.

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

2017-11-01 Thread Mahesh Jethanandani
Kristian, I think there is confusion in how the ACL model is going to be implemented by vendors and used by customers. As Eliot alluded to, the model is trying to address the issue of the capabilities of each platform as they exist across the industry but also within each vendor. So the first

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

2017-10-31 Thread Kristian Larsson
On Tue, Oct 31, 2017 at 11:47:54AM +0100, Eliot Lear wrote: > Hi Kristian, > > Just my view below: > > > On 10/31/17 11:25 AM, Kristian Larsson wrote: > > > This brings us to the acl-type. It seems to me that this is > > primarily for being able to do YANG validation when a device does > > NOT

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

2017-10-31 Thread Eliot Lear
Hi Kristian, Just my view below: On 10/31/17 11:25 AM, Kristian Larsson wrote: > This brings us to the acl-type. It seems to me that this is > primarily for being able to do YANG validation when a device does > NOT support a unified model. I.e. if Linux nftables was all we > wanted to model,

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

2017-10-31 Thread Kristian Larsson
On Fri, Oct 20, 2017 at 09:37:04PM +, Kent Watsen wrote: > > All, > > This starts a two-week working group last call on > draft-ietf-netmod-acl-model-14. > > The working group last call ends on November 3. > Please send your comments to the netmod mailing list. I initially read this draft

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

2017-10-26 Thread Martin Bjorklund
"Acee Lindem (acee)" wrote: > Hi Mahesh, > > On 10/25/17, 9:22 PM, "Mahesh Jethanandani" > wrote: > > >Acee, > > > >Thanks for reviewing the draft. > > > >> On Oct 25, 2017, at 6:21 AM, Acee Lindem (acee) wrote: > >> > >> Hi Kent,

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

2017-10-26 Thread Acee Lindem (acee)
Hi Mahesh, On 10/25/17, 9:22 PM, "Mahesh Jethanandani" wrote: >Acee, > >Thanks for reviewing the draft. > >> On Oct 25, 2017, at 6:21 AM, Acee Lindem (acee) wrote: >> >> Hi Kent, Mahesh, et al, >> >> I have read the draft and support publication. I

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

2017-10-25 Thread Mahesh Jethanandani
Acee, Thanks for reviewing the draft. > On Oct 25, 2017, at 6:21 AM, Acee Lindem (acee) wrote: > > Hi Kent, Mahesh, et al, > > I have read the draft and support publication. I have two comments on the > -14 version. > > 1. The tree diagrams do not fit within the draft

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

2017-10-25 Thread Acee Lindem (acee)
Hi Kent, Mahesh, et al, I have read the draft and support publication. I have two comments on the -14 version. 1. The tree diagrams do not fit within the draft pages. Note that recent versions of pyang support the —tree-line-length parameter and this may help. 2. While it is non-normative,

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

2017-10-23 Thread Sonal Agarwal
Hi Eliiot, I'd be very interested in understanding the technical issues that you see with the model. Could you please elaborate? Kind regards, Sonal. On Mon, Oct 23, 2017 at 10:21 AM, Eliot Lear wrote: > Honestly, I'd just assume got with what's there than have a lengthy >

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

2017-10-23 Thread Eliot Lear
Honestly, I'd just assume got with what's there than have a lengthy discussion about how to make it perfect in Eliot's eyes.  We must do models quicker, and I will be quite happy to enjoy this one's imperfections just to prove that point. On 10/23/17 6:35 PM, Kent Watsen wrote: > Thanks Elliot.

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

2017-10-23 Thread Eliot Lear
I've reviewed this draft.  It is NOT perfect.  It *is* good enough.  Please let's move it along. Eliot On 10/20/17 11:37 PM, Kent Watsen wrote: > All, > > This starts a two-week working group last call on > draft-ietf-netmod-acl-model-14. > > The working group last call ends on November 3. >

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

2017-10-20 Thread Mahesh Jethanandani
I am not aware of any IPRs related to the draft. Thanks. > On Oct 20, 2017, at 5:37 PM, Kent Watsen wrote: > > > All, > > This starts a two-week working group last call on > draft-ietf-netmod-acl-model-14. > > The working group last call ends on November 3. > Please

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

2017-10-20 Thread Kent Watsen
All, This starts a two-week working group last call on draft-ietf-netmod-acl-model-14. The working group last call ends on November 3. Please send your comments to the netmod mailing list. Positive comments, e.g., "I've reviewed this document and believe it is ready for publication", are