Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 2016)

[Kent Watsen]

Hi All,

The extended Last Call period is now closed; no new issues can be raised now.  
I believe issues were raised by David, Mahesh, and one from Dean himself 
(hopefully I didn’t miss anyone).  The authors should now work towards 
resolving (on list, of course) all the issues raised during the Last Call 
period, and ultimately post an updated draft capturing the WG consensus.

Thanks,
Kent // as shepherd

From: netmod  on behalf of Kent Watsen 

Date: Wednesday, November 23, 2016 at 10:54 AM
To: Eliot Lear , David Bannister , "Acee 
Lindem (acee)" , Dean Bogdanovic 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until 
Oct 27, 2016)


Yes, this draft is currently past last-call, and not for the first time, and 
there being two implementations was highly encouraging.   Still, as shepherd 
and chair, I need to know we have WG consensus on next steps and therefore want 
to echo Eliot’s request for all and any remaining issues to be brought forward 
now, or let’s say within the next couple weeks, so we can discuss which changes 
to accept or not.  To be clear, I’m in effect extending the last-call period 
for this draft until December 7.

FWIW, the issue I raised regarding if there was a need to support 
system-generated ACLs resolved as a no-op to the draft.  Dean’s issue regarding 
changing a leaf to a leaf-list seemed innocuous enough, but Acee’s question 
remains unanswered.  Additionally, from a pre- Bits-N-Bites meeting I had, I’m 
aware that other concerns linger, which I hope to see discussed now in this 
extended last-call period.

Kent  // as shepherd and co-chair


From: Eliot Lear 
Date: Friday, November 18, 2016 at 9:24 AM
To: David Bannister , "Acee Lindem (acee)" , 
Dean Bogdanovic , Kent Watsen 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until 
Oct 27, 2016)


It's already useful to me.  And we've seen other people say it is useful to 
them.  If you need something specific, say so now please, but otherwise let's 
please move along.

Eliot

On 11/18/16 3:07 PM, David Bannister wrote:
This draft should not move forward, it needs more work to be useful. Will be 
working with Dean next week to fix things up.

On Fri, Nov 18, 2016 at 11:02 PM Eliot Lear 
mailto:l...@cisco.com>> wrote:

Dean and friends,

I'd just like to add one additional point.  This draft has been in numerous 
forms of WGLC for a while now.   Can we please agree that as a proposed 
standard we have passed the point where perfect is the enemy of good?  Some of 
us need this work finished.

Thanks,

Eliot







On 11/18/16 1:55 PM, Acee Lindem (acee) wrote:
Hi Dean,
If you make this a list of heterogeneous IPv4 header fields, how will you 
constrain specification to only one field of each type? For example, one source 
address? Existing implementations do not support multiples and generate all 
permutations (given multiple specifications of each field) could be complex.
Thanks,
Acee


From: netmod mailto:netmod-boun...@ietf.org>> on 
behalf of Dean Bogdanovic mailto:ivand...@gmail.com>>
Date: Tuesday, November 15, 2016 at 10:06 AM
To: Kent Watsen mailto:kwat...@juniper.net>>
Cc: "netmod@ietf.org<mailto:netmod@ietf.org>" 
mailto:netmod@ietf.org>>
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until 
Oct 27, 2016)

I have something that might delay WGLC, but found out an optimization which 
would help in the future

In ietf-packet-fields.yang, example below

grouping acl-ipv4-header-fields {
   description
 "Fields in IPv4 header.";
   leaf destination-ipv4-network {
 type inet:ipv4-prefix;
 description
   "Destination IPv4 address prefix.";
   }
   leaf source-ipv4-network {
 type inet:ipv4-prefix;
 description
   "Source IPv4 address prefix.";
   }
 }

Instead of using "leaf" for "destination-ipv4-network" and 
"source-ipv4-network", "leaf-list" reduces the number of terms/ace needed.

If we would agree with this change, then would propose one more

for mac-addresses, having the mask under the address itself look better in the 
data itself:

  
01:01:01:00:00:00
ff:ff:ff:00:00:00
  

  Or create a new type 'mac-address-prefix'.

  This allows having matching multiple destinations to 1 source, or multiple 
sources to 1 destination, if they cannot be easily combined into 1 entry.

  
01:01:01:00:00:00
ff:ff:ff:00:00:00
  
  
01:04:01:00:00:00
ff:ff:ff:00:00:00
  
  

  
On Nov 14, 2016, at 7:35 AM, Dean Bogdanovic 
mailto:ivand...@gmail.com>> wrote:

Kent,

Thank you for the answer
On Nov 13, 2016, at 1:20 PM, Kent Watsen 
mailto:kwat...@juniper.net>> wrote:

Hi Dean,

> Don’t understand your question. What is the difference between system and 
&g

Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 2016)

[wangzitao]

+1
I am not co-author of this model, but I had read this draft.
I believe this model can be easily augmented and flexible reused:
The “choice/case” structure can help to insert new “condition” or “action” 
attributes into the ACL model;
And the “ietf-packet-fields” module which contains several reusable groupings 
also provide a convenient way to derive specific models.

Best Regards!
-Michael

发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Dean Bogdanovic
发送时间: 2016年11月24日 7:18
收件人: Andy Bierman
抄送: netmod@ietf.org
主题: Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 
2016)

As draft author, the model was designed to be easily augmented for matches and 
actions, so that each vendor and user can adapt it to their needs.

Dean

On Nov 23, 2016, at 6:05 PM, Andy Bierman 
mailto:a...@yumaworks.com>> wrote:

Hi,

I have a general comment, related to Benoit's request to get YANG modules done.

Augment is your friend.  Use it.
YANG 1.1 even allows conditionally mandatory nodes to be added, so there are
no excuses for not publishing base modules that can be augmented later.

IMO, adding new features in WGLC should not even be considered.


Andy


On Wed, Nov 23, 2016 at 2:55 PM, Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
If you could just point out the general features you are using in your configs 
that are not present in the base model. I know you mentioned TCP options 
matching. With respect to the augmentations, they don’t have to be vendor 
specific. Some advanced ACL functions such as conditional ACLs could be 
provided in standard model augmentations in future modules.

Thanks,
Acee

From: David Bannister mailto:d...@netflix.com>>
Date: Wednesday, November 23, 2016 at 1:54 PM
To: Acee Lindem mailto:a...@cisco.com>>
Cc: Kent Watsen mailto:kwat...@juniper.net>>, Eliot Lear 
mailto:l...@cisco.com>>, Dean Bogdanovic 
mailto:ivand...@gmail.com>>, 
"netmod@ietf.org<mailto:netmod@ietf.org>" 
mailto:netmod@ietf.org>>
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until 
Oct 27, 2016)

I'm open to the idea given ample time.

On Wed, Nov 23, 2016 at 12:53 PM, Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Hi David,

From: David Bannister mailto:d...@netflix.com>>
Date: Wednesday, November 23, 2016 at 12:28 PM
To: Kent Watsen mailto:kwat...@juniper.net>>
Cc: Eliot Lear mailto:l...@cisco.com>>, Acee Lindem 
mailto:a...@cisco.com>>, Dean Bogdanovic 
mailto:ivand...@gmail.com>>, 
"netmod@ietf.org<mailto:netmod@ietf.org>" 
mailto:netmod@ietf.org>>
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until 
Oct 27, 2016)

Here are my issues with the ACL draft as it stands today from a high level, vs. 
calling out every missing field.

Although I’m not an author of this YANG model, I’m the author of others and I 
can say from experience that it would be infinitely more productive for you to 
list the specific fields and corresponding use cases as opposed to a subjective 
high-level critique. That way, these can be incorporated or, at least, we can 
have the discussion as whether or not they belong in the base model.

Thanks,
Acee


___
netmod mailing list
netmod@ietf.org<mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org<mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 2016)

[Dean Bogdanovic]

As draft author, the model was designed to be easily augmented for matches and 
actions, so that each vendor and user can adapt it to their needs.

Dean

> On Nov 23, 2016, at 6:05 PM, Andy Bierman  wrote:
> 
> Hi,
> 
> I have a general comment, related to Benoit's request to get YANG modules 
> done.
> 
> Augment is your friend.  Use it.
> YANG 1.1 even allows conditionally mandatory nodes to be added, so there are
> no excuses for not publishing base modules that can be augmented later.
> 
> IMO, adding new features in WGLC should not even be considered.
> 
> 
> Andy
> 
> 
> On Wed, Nov 23, 2016 at 2:55 PM, Acee Lindem (acee)  <mailto:a...@cisco.com>> wrote:
> If you could just point out the general features you are using in your 
> configs that are not present in the base model. I know you mentioned TCP 
> options matching. With respect to the augmentations, they don’t have to be 
> vendor specific. Some advanced ACL functions such as conditional ACLs could 
> be provided in standard model augmentations in future modules. 
> 
> Thanks,
> Acee 
> 
> From: David Bannister mailto:d...@netflix.com>>
> Date: Wednesday, November 23, 2016 at 1:54 PM
> To: Acee Lindem mailto:a...@cisco.com>>
> Cc: Kent Watsen mailto:kwat...@juniper.net>>, Eliot 
> Lear mailto:l...@cisco.com>>, Dean Bogdanovic 
> mailto:ivand...@gmail.com>>, "netmod@ietf.org 
> <mailto:netmod@ietf.org>" mailto:netmod@ietf.org>>
> Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until 
> Oct 27, 2016)
> 
> I'm open to the idea given ample time.
> 
> On Wed, Nov 23, 2016 at 12:53 PM, Acee Lindem (acee)  <mailto:a...@cisco.com>> wrote:
> Hi David, 
> 
> From: David Bannister mailto:d...@netflix.com>>
> Date: Wednesday, November 23, 2016 at 12:28 PM
> To: Kent Watsen mailto:kwat...@juniper.net>>
> Cc: Eliot Lear mailto:l...@cisco.com>>, Acee Lindem 
> mailto:a...@cisco.com>>, Dean Bogdanovic  <mailto:ivand...@gmail.com>>, "netmod@ietf.org <mailto:netmod@ietf.org>" 
> mailto:netmod@ietf.org>>
> Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until 
> Oct 27, 2016)
> 
> Here are my issues with the ACL draft as it stands today from a high level, 
> vs. calling out every missing field. 
> 
> Although I’m not an author of this YANG model, I’m the author of others and I 
> can say from experience that it would be infinitely more productive for you 
> to list the specific fields and corresponding use cases as opposed to a 
> subjective high-level critique. That way, these can be incorporated or, at 
> least, we can have the discussion as whether or not they belong in the base 
> model. 
> 
> Thanks,
> Acee 
> 
> 
> ___
> netmod mailing list
> netmod@ietf.org <mailto:netmod@ietf.org>
> https://www.ietf.org/mailman/listinfo/netmod 
> <https://www.ietf.org/mailman/listinfo/netmod>
> 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 2016)

[Andy Bierman]

Hi,

I have a general comment, related to Benoit's request to get YANG modules
done.

Augment is your friend.  Use it.
YANG 1.1 even allows conditionally mandatory nodes to be added, so there are
no excuses for not publishing base modules that can be augmented later.

IMO, adding new features in WGLC should not even be considered.


Andy


On Wed, Nov 23, 2016 at 2:55 PM, Acee Lindem (acee)  wrote:

> If you could just point out the general features you are using in your
> configs that are not present in the base model. I know you mentioned TCP
> options matching. With respect to the augmentations, they don’t have to be
> vendor specific. Some advanced ACL functions such as conditional ACLs could
> be provided in standard model augmentations in future modules.
>
> Thanks,
> Acee
>
> From: David Bannister 
> Date: Wednesday, November 23, 2016 at 1:54 PM
> To: Acee Lindem 
> Cc: Kent Watsen , Eliot Lear , Dean
> Bogdanovic , "netmod@ietf.org" 
> Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09
> (until Oct 27, 2016)
>
> I'm open to the idea given ample time.
>
> On Wed, Nov 23, 2016 at 12:53 PM, Acee Lindem (acee) 
> wrote:
>
>> Hi David,
>>
>> From: David Bannister 
>> Date: Wednesday, November 23, 2016 at 12:28 PM
>> To: Kent Watsen 
>> Cc: Eliot Lear , Acee Lindem , Dean
>> Bogdanovic , "netmod@ietf.org" 
>> Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09
>> (until Oct 27, 2016)
>>
>> Here are my issues with the ACL draft as it stands today from a high
>> level, vs. calling out every missing field.
>>
>>
>> Although I’m not an author of this YANG model, I’m the author of others
>> and I can say from experience that it would be infinitely more productive
>> for you to list the specific fields and corresponding use cases as opposed
>> to a subjective high-level critique. That way, these can be incorporated
>> or, at least, we can have the discussion as whether or not they belong in
>> the base model.
>>
>> Thanks,
>> Acee
>>
>
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 2016)

[Acee Lindem (acee)]

If you could just point out the general features you are using in your configs 
that are not present in the base model. I know you mentioned TCP options 
matching. With respect to the augmentations, they don't have to be vendor 
specific. Some advanced ACL functions such as conditional ACLs could be 
provided in standard model augmentations in future modules.

Thanks,
Acee

From: David Bannister mailto:d...@netflix.com>>
Date: Wednesday, November 23, 2016 at 1:54 PM
To: Acee Lindem mailto:a...@cisco.com>>
Cc: Kent Watsen mailto:kwat...@juniper.net>>, Eliot Lear 
mailto:l...@cisco.com>>, Dean Bogdanovic 
mailto:ivand...@gmail.com>>, 
"netmod@ietf.org<mailto:netmod@ietf.org>" 
mailto:netmod@ietf.org>>
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until 
Oct 27, 2016)

I'm open to the idea given ample time.

On Wed, Nov 23, 2016 at 12:53 PM, Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Hi David,

From: David Bannister mailto:d...@netflix.com>>
Date: Wednesday, November 23, 2016 at 12:28 PM
To: Kent Watsen mailto:kwat...@juniper.net>>
Cc: Eliot Lear mailto:l...@cisco.com>>, Acee Lindem 
mailto:a...@cisco.com>>, Dean Bogdanovic 
mailto:ivand...@gmail.com>>, 
"netmod@ietf.org<mailto:netmod@ietf.org>" 
mailto:netmod@ietf.org>>
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until 
Oct 27, 2016)

Here are my issues with the ACL draft as it stands today from a high level, vs. 
calling out every missing field.

Although I'm not an author of this YANG model, I'm the author of others and I 
can say from experience that it would be infinitely more productive for you to 
list the specific fields and corresponding use cases as opposed to a subjective 
high-level critique. That way, these can be incorporated or, at least, we can 
have the discussion as whether or not they belong in the base model.

Thanks,
Acee

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 2016)

[Mahesh Jethanandani]

Kent,

I want to echo the issue that Adrian Pan brought up earlier on acl-type. The 
model currently allows for definition of acl-type which it describes as:

"Type of access control list. Indicates the primary intended
 type of match criteria (e.g. ethernet, IPv4, IPv6, mixed, etc)
 used in the list instance."

First of all, it is not clear what is meant by "primary intended type of match 
criteria”. Does it mean that if acl-type is defined as ipv6 and a ipv4 ace 
entry is added to that acl, that the ipv4 address will be treated as a ipv6 
address? Or does it mean that if there is a mix of ipv4 and ipv6 addresses 
within an acl, that ipv6 address would be selected over ipv4? If the intention 
is truly to allow mixing of different acl-types, which I am not sure any system 
supports (Cisco certainly does not), then one can use acl-type of ‘mixed’.

A more intuitive use of acl-type, in my mind, would be to use it to check 
whether the ace entry matches the acl-type. 

> On Nov 23, 2016, at 7:54 AM, Kent Watsen  wrote:
> 
>  
> Yes, this draft is currently past last-call, and not for the first time, and 
> there being two implementations was highly encouraging.   Still, as shepherd 
> and chair, I need to know we have WG consensus on next steps and therefore 
> want to echo Eliot’s request for all and any remaining issues to be brought 
> forward now, or let’s say within the next couple weeks, so we can discuss 
> which changes to accept or not.  To be clear, I’m in effect extending the 
> last-call period for this draft until December 7.
>  
> FWIW, the issue I raised regarding if there was a need to support 
> system-generated ACLs resolved as a no-op to the draft.  Dean’s issue 
> regarding changing a leaf to a leaf-list seemed innocuous enough, but Acee’s 
> question remains unanswered.  Additionally, from a pre- Bits-N-Bites meeting 
> I had, I’m aware that other concerns linger, which I hope to see discussed 
> now in this extended last-call period.
>  
> Kent  // as shepherd and co-chair
>  
>  
> From: Eliot Lear mailto:l...@cisco.com>>
> Date: Friday, November 18, 2016 at 9:24 AM
> To: David Bannister mailto:d...@netflix.com>>, "Acee 
> Lindem (acee)" mailto:a...@cisco.com>>, Dean Bogdanovic 
> mailto:ivand...@gmail.com>>, Kent Watsen 
> mailto:kwat...@juniper.net>>
> Cc: "netmod@ietf.org <mailto:netmod@ietf.org>"  <mailto:netmod@ietf.org>>
> Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until 
> Oct 27, 2016)
>  
> It's already useful to me.  And we've seen other people say it is useful to 
> them.  If you need something specific, say so now please, but otherwise let's 
> please move along.
> 
> Eliot
> 
>  
> On 11/18/16 3:07 PM, David Bannister wrote:
>> This draft should not move forward, it needs more work to be useful. Will be 
>> working with Dean next week to fix things up.
>>  
>> On Fri, Nov 18, 2016 at 11:02 PM Eliot Lear > <mailto:l...@cisco.com>> wrote:
>>> Dean and friends,
>>> 
>>> I'd just like to add one additional point.  This draft has been in numerous 
>>> forms of WGLC for a while now.   Can we please agree that as a proposed 
>>> standard we have passed the point where perfect is the enemy of good?  Some 
>>> of us need this work finished.
>>> 
>>> Thanks,
>>> 
>>> Eliot
>>> 
>>>  
>>> 
>>>  
>>> 
>>>  
>>> 
>>>  
>>> On 11/18/16 1:55 PM, Acee Lindem (acee) wrote:
>>>> Hi Dean, 
>>>> If you make this a list of heterogeneous IPv4 header fields, how will you 
>>>> constrain specification to only one field of each type? For example, one 
>>>> source address? Existing implementations do not support multiples and 
>>>> generate all permutations (given multiple specifications of each field) 
>>>> could be complex. 
>>>> Thanks,
>>>> Acee 
>>>>  
>>>>  
>>>> From: netmod mailto:netmod-boun...@ietf.org>> on 
>>>> behalf of Dean Bogdanovic mailto:ivand...@gmail.com>>
>>>> Date: Tuesday, November 15, 2016 at 10:06 AM
>>>> To: Kent Watsen mailto:kwat...@juniper.net>>
>>>> Cc: "netmod@ietf.org <mailto:netmod@ietf.org>" >>> <mailto:netmod@ietf.org>>
>>>> Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 
>>>> (until Oct 27, 2016)
>>>>  
>>>>> I have something that might delay WGLC, but found out an optimization 
>>>>> 

Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 2016)

[Acee Lindem (acee)]

Hi David,

From: David Bannister mailto:d...@netflix.com>>
Date: Wednesday, November 23, 2016 at 12:28 PM
To: Kent Watsen mailto:kwat...@juniper.net>>
Cc: Eliot Lear mailto:l...@cisco.com>>, Acee Lindem 
mailto:a...@cisco.com>>, Dean Bogdanovic 
mailto:ivand...@gmail.com>>, 
"netmod@ietf.org<mailto:netmod@ietf.org>" 
mailto:netmod@ietf.org>>
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until 
Oct 27, 2016)

Here are my issues with the ACL draft as it stands today from a high level, vs. 
calling out every missing field.

Although I'm not an author of this YANG model, I'm the author of others and I 
can say from experience that it would be infinitely more productive for you to 
list the specific fields and corresponding use cases as opposed to a subjective 
high-level critique. That way, these can be incorporated or, at least, we can 
have the discussion as whether or not they belong in the base model.

Thanks,
Acee
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 2016)

[Kent Watsen]

Yes, this draft is currently past last-call, and not for the first time, and 
there being two implementations was highly encouraging.   Still, as shepherd 
and chair, I need to know we have WG consensus on next steps and therefore want 
to echo Eliot’s request for all and any remaining issues to be brought forward 
now, or let’s say within the next couple weeks, so we can discuss which changes 
to accept or not.  To be clear, I’m in effect extending the last-call period 
for this draft until December 7.

FWIW, the issue I raised regarding if there was a need to support 
system-generated ACLs resolved as a no-op to the draft.  Dean’s issue regarding 
changing a leaf to a leaf-list seemed innocuous enough, but Acee’s question 
remains unanswered.  Additionally, from a pre- Bits-N-Bites meeting I had, I’m 
aware that other concerns linger, which I hope to see discussed now in this 
extended last-call period.

Kent  // as shepherd and co-chair


From: Eliot Lear 
Date: Friday, November 18, 2016 at 9:24 AM
To: David Bannister , "Acee Lindem (acee)" , 
Dean Bogdanovic , Kent Watsen 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until 
Oct 27, 2016)


It's already useful to me.  And we've seen other people say it is useful to 
them.  If you need something specific, say so now please, but otherwise let's 
please move along.

Eliot

On 11/18/16 3:07 PM, David Bannister wrote:
This draft should not move forward, it needs more work to be useful. Will be 
working with Dean next week to fix things up.

On Fri, Nov 18, 2016 at 11:02 PM Eliot Lear 
mailto:l...@cisco.com>> wrote:

Dean and friends,

I'd just like to add one additional point.  This draft has been in numerous 
forms of WGLC for a while now.   Can we please agree that as a proposed 
standard we have passed the point where perfect is the enemy of good?  Some of 
us need this work finished.

Thanks,

Eliot







On 11/18/16 1:55 PM, Acee Lindem (acee) wrote:
Hi Dean,
If you make this a list of heterogeneous IPv4 header fields, how will you 
constrain specification to only one field of each type? For example, one source 
address? Existing implementations do not support multiples and generate all 
permutations (given multiple specifications of each field) could be complex.
Thanks,
Acee


From: netmod mailto:netmod-boun...@ietf.org>> on 
behalf of Dean Bogdanovic mailto:ivand...@gmail.com>>
Date: Tuesday, November 15, 2016 at 10:06 AM
To: Kent Watsen mailto:kwat...@juniper.net>>
Cc: "netmod@ietf.org<mailto:netmod@ietf.org>" 
mailto:netmod@ietf.org>>
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until 
Oct 27, 2016)

I have something that might delay WGLC, but found out an optimization which 
would help in the future

In ietf-packet-fields.yang, example below

grouping acl-ipv4-header-fields {
   description
 "Fields in IPv4 header.";
   leaf destination-ipv4-network {
 type inet:ipv4-prefix;
 description
   "Destination IPv4 address prefix.";
   }
   leaf source-ipv4-network {
 type inet:ipv4-prefix;
 description
   "Source IPv4 address prefix.";
   }
 }

Instead of using "leaf" for "destination-ipv4-network" and 
"source-ipv4-network", "leaf-list" reduces the number of terms/ace needed.

If we would agree with this change, then would propose one more

for mac-addresses, having the mask under the address itself look better in the 
data itself:

  
01:01:01:00:00:00
ff:ff:ff:00:00:00
  

  Or create a new type 'mac-address-prefix'.

  This allows having matching multiple destinations to 1 source, or multiple 
sources to 1 destination, if they cannot be easily combined into 1 entry.

  
01:01:01:00:00:00
ff:ff:ff:00:00:00
  
  
01:04:01:00:00:00
ff:ff:ff:00:00:00
  
  

  
On Nov 14, 2016, at 7:35 AM, Dean Bogdanovic 
mailto:ivand...@gmail.com>> wrote:

Kent,

Thank you for the answer
On Nov 13, 2016, at 1:20 PM, Kent Watsen 
mailto:kwat...@juniper.net>> wrote:

Hi Dean,

> Don’t understand your question. What is the difference between system and 
> user generated acls?

User-generated would be, for instance, configured via NETCONF or RESTCONF, 
whereas system-generated would be ACLs that get created by default.  For 
example, RFC 7223 has the top-level /interfaces-state to support 
system-generated interfaces (e.g., lo) so, when running `shows interfaces`, the 
result includes both configured and system-generated interfaces.   Makes sense?

I understand now what you meant. Where I can see for the interfaces the use 
case you describe (for loopback and physical interfaces), for ACLs have much 
harder time to find an example use case where a system would generate an ACL. 
Maybe for a highly secure system would generate an ACL to deny all traffic t

Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 2016)

[Eliot Lear]

Hurry?!  Please look at the history of this draft.


On 11/18/16 3:27 PM, David Bannister wrote:
> If you are in a hurry use your vendor model.
>
> On Fri, Nov 18, 2016 at 11:24 PM Eliot Lear  <mailto:l...@cisco.com>> wrote:
>
> It's already useful to me.  And we've seen other people say it is
> useful to them.  If you need something specific, say so now
> please, but otherwise let's please move along.
>
> Eliot
>
>
> On 11/18/16 3:07 PM, David Bannister wrote:
>> This draft should not move forward, it needs more work to be
>> useful. Will be working with Dean next week to fix things up.
>>
>> On Fri, Nov 18, 2016 at 11:02 PM Eliot Lear > <mailto:l...@cisco.com>> wrote:
>>
>> Dean and friends,
>>
>> I'd just like to add one additional point.  This draft has
>> been in numerous forms of WGLC for a while now.   Can we
>> please agree that as a proposed standard we have passed the
>> point where perfect is the enemy of good?  Some of us need
>> this work finished.
>>
>> Thanks,
>>
>> Eliot
>>
>>
>>
>>
>>
>> On 11/18/16 1:55 PM, Acee Lindem (acee) wrote:
>>> Hi Dean, 
>>> If you make this a list of heterogeneous IPv4 header fields,
>>> how will you constrain specification to only one field of
>>> each type? For example, one source address? Existing
>>> implementations do not support multiples and generate all
>>> permutations (given multiple specifications of each field)
>>> could be complex. 
>>> Thanks,
>>> Acee 
>>>
>>>
>>> From: netmod >> <mailto:netmod-boun...@ietf.org>> on behalf of Dean
>>>     Bogdanovic mailto:ivand...@gmail.com>>
>>> Date: Tuesday, November 15, 2016 at 10:06 AM
>>> To: Kent Watsen >> <mailto:kwat...@juniper.net>>
>>> Cc: "netmod@ietf.org <mailto:netmod@ietf.org>"
>>> mailto:netmod@ietf.org>>
>>> Subject: Re: [netmod] WG Last Call for
>>> draft-ietf-netmod-acl-model-09 (until Oct 27, 2016)
>>>
>>> I have something that might delay WGLC, but found out an
>>> optimization which would help in the future
>>>
>>> In ietf-packet-fields.yang, example below
>>>
>>> grouping acl-ipv4-header-fields {
>>>description
>>>  "Fields in IPv4 header.";
>>>leaf destination-ipv4-network {
>>>  type inet:ipv4-prefix;
>>>  description
>>>"Destination IPv4 address prefix.";
>>>}
>>>leaf source-ipv4-network {
>>>  type inet:ipv4-prefix;
>>>  description
>>>"Source IPv4 address prefix.";
>>>}
>>>  }
>>>
>>> Instead of using "leaf" for "destination-ipv4-network"
>>> and "source-ipv4-network", "leaf-list" reduces the
>>> number of terms/ace needed.
>>>
>>> If we would agree with this change, then would propose
>>> one more 
>>>
>>> for mac-addresses, having the mask under the address
>>> itself look better in the data itself:
>>>
>>>   
>>> 01:01:01:00:00:00
>>> ff:ff:ff:00:00:00
>>>   
>>>
>>>   Or create a new type 'mac-address-prefix'.
>>>
>>>   This allows having matching multiple destinations to 1
>>> source, or multiple sources to 1 destination, if they
>>> cannot be easily combined into 1 entry.
>>>
>>>   
>>> 01:01:01:00:00:00
>>> ff:ff:ff:00:00:00
>>>   
>>>   
>>> 01:04:01:00:00:00
>>> ff:ff:ff:00:00:00
>>>   
>>>   
>>> 
>>>   
>>>> On Nov 14, 2016, at 7

Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 2016)

[Eliot Lear]

It's already useful to me.  And we've seen other people say it is useful
to them.  If you need something specific, say so now please, but
otherwise let's please move along.

Eliot


On 11/18/16 3:07 PM, David Bannister wrote:
> This draft should not move forward, it needs more work to be useful.
> Will be working with Dean next week to fix things up.
>
> On Fri, Nov 18, 2016 at 11:02 PM Eliot Lear  <mailto:l...@cisco.com>> wrote:
>
> Dean and friends,
>
> I'd just like to add one additional point.  This draft has been in
> numerous forms of WGLC for a while now.   Can we please agree that
> as a proposed standard we have passed the point where perfect is
> the enemy of good?  Some of us need this work finished.
>
> Thanks,
>
> Eliot
>
>
>
>
>
> On 11/18/16 1:55 PM, Acee Lindem (acee) wrote:
>> Hi Dean, 
>> If you make this a list of heterogeneous IPv4 header fields, how
>> will you constrain specification to only one field of each type?
>> For example, one source address? Existing implementations do not
>> support multiples and generate all permutations (given multiple
>> specifications of each field) could be complex. 
>> Thanks,
>> Acee 
>>
>>
>> From: netmod > <mailto:netmod-boun...@ietf.org>> on behalf of Dean Bogdanovic
>> mailto:ivand...@gmail.com>>
>> Date: Tuesday, November 15, 2016 at 10:06 AM
>> To: Kent Watsen mailto:kwat...@juniper.net>>
>> Cc: "netmod@ietf.org <mailto:netmod@ietf.org>" > <mailto:netmod@ietf.org>>
>> Subject: Re: [netmod] WG Last Call for
>> draft-ietf-netmod-acl-model-09 (until Oct 27, 2016)
>>
>> I have something that might delay WGLC, but found out an
>> optimization which would help in the future
>>
>> In ietf-packet-fields.yang, example below
>>
>> grouping acl-ipv4-header-fields {
>>description
>>  "Fields in IPv4 header.";
>>leaf destination-ipv4-network {
>>  type inet:ipv4-prefix;
>>  description
>>"Destination IPv4 address prefix.";
>>}
>>leaf source-ipv4-network {
>>  type inet:ipv4-prefix;
>>  description
>>"Source IPv4 address prefix.";
>>}
>>  }
>>
>> Instead of using "leaf" for "destination-ipv4-network" and
>> "source-ipv4-network", "leaf-list" reduces the number of
>> terms/ace needed.
>>
>> If we would agree with this change, then would propose one more 
>>
>> for mac-addresses, having the mask under the address itself
>> look better in the data itself:
>>
>>   
>> 01:01:01:00:00:00
>> ff:ff:ff:00:00:00
>>   
>>
>>   Or create a new type 'mac-address-prefix'.
>>
>>   This allows having matching multiple destinations to 1
>> source, or multiple sources to 1 destination, if they cannot
>> be easily combined into 1 entry.
>>
>>   
>> 01:01:01:00:00:00
>> ff:ff:ff:00:00:00
>>   
>>   
>> 01:04:01:00:00:00
>> ff:ff:ff:00:00:00
>>   
>>   
>> 
>>   
>>> On Nov 14, 2016, at 7:35 AM, Dean Bogdanovic
>>> mailto:ivand...@gmail.com>> wrote:
>>>
>>> Kent,
>>>
>>> Thank you for the answer
>>>> On Nov 13, 2016, at 1:20 PM, Kent Watsen
>>>> mailto:kwat...@juniper.net>> wrote:
>>>>
>>>> Hi Dean,
>>>>  
>>>> > Don’t understand your question. What is the difference between
>>>> system and user generated acls?
>>>>  
>>>> User-generated would be, for instance, configured via
>>>> NETCONF or RESTCONF, whereas system-generated would be ACLs
>>>> that get created by default.  For example, RFC 7223 has the
>>>> top-level /interfaces-state to support system-generated
>>>> interfaces (e.g., lo) so, when running `shows interfaces`,
>>>> the result includes both 

Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 2016)

[Eliot Lear]

Dean and friends,

I'd just like to add one additional point.  This draft has been in
numerous forms of WGLC for a while now.   Can we please agree that as a
proposed standard we have passed the point where perfect is the enemy of
good?  Some of us need this work finished.

Thanks,

Eliot





On 11/18/16 1:55 PM, Acee Lindem (acee) wrote:
> Hi Dean, 
> If you make this a list of heterogeneous IPv4 header fields, how will
> you constrain specification to only one field of each type? For
> example, one source address? Existing implementations do not support
> multiples and generate all permutations (given multiple specifications
> of each field) could be complex. 
> Thanks,
> Acee 
>
>
> From: netmod  <mailto:netmod-boun...@ietf.org>> on behalf of Dean Bogdanovic
> mailto:ivand...@gmail.com>>
> Date: Tuesday, November 15, 2016 at 10:06 AM
> To: Kent Watsen mailto:kwat...@juniper.net>>
> Cc: "netmod@ietf.org <mailto:netmod@ietf.org>"  <mailto:netmod@ietf.org>>
> Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09
> (until Oct 27, 2016)
>
> I have something that might delay WGLC, but found out an
> optimization which would help in the future
>
> In ietf-packet-fields.yang, example below
>
> grouping acl-ipv4-header-fields {
>description
>  "Fields in IPv4 header.";
>leaf destination-ipv4-network {
>  type inet:ipv4-prefix;
>  description
>"Destination IPv4 address prefix.";
>}
>leaf source-ipv4-network {
>  type inet:ipv4-prefix;
>  description
>"Source IPv4 address prefix.";
>}
>  }
>
> Instead of using "leaf" for "destination-ipv4-network" and
> "source-ipv4-network", "leaf-list" reduces the number of terms/ace
> needed.
>
> If we would agree with this change, then would propose one more 
>
> for mac-addresses, having the mask under the address itself
> look better in the data itself:
>
>   
> 01:01:01:00:00:00
> ff:ff:ff:00:00:00
>   
>
>   Or create a new type 'mac-address-prefix'.
>
>   This allows having matching multiple destinations to 1 source,
> or multiple sources to 1 destination, if they cannot be easily
> combined into 1 entry.
>
>   
> 01:01:01:00:00:00
> ff:ff:ff:00:00:00
>   
>   
> 01:04:01:00:00:00
> ff:ff:ff:00:00:00
>   
>   
> 
>   
>> On Nov 14, 2016, at 7:35 AM, Dean Bogdanovic > <mailto:ivand...@gmail.com>> wrote:
>>
>> Kent,
>>
>> Thank you for the answer
>>> On Nov 13, 2016, at 1:20 PM, Kent Watsen >> <mailto:kwat...@juniper.net>> wrote:
>>>
>>> Hi Dean,
>>>  
>>> > Don’t understand your question. What is the difference between
>>> system and user generated acls?
>>>  
>>> User-generated would be, for instance, configured via NETCONF or
>>> RESTCONF, whereas system-generated would be ACLs that get
>>> created by default.  For example, RFC 7223 has the top-level
>>> /interfaces-state to support system-generated interfaces (e.g.,
>>> lo) so, when running `shows interfaces`, the result includes
>>> both configured and system-generated interfaces.   Makes sense?
>>
>> I understand now what you meant. Where I can see for the
>> interfaces the use case you describe (for loopback and physical
>> interfaces), for ACLs have much harder time to find an example
>> use case where a system would generate an ACL. Maybe for a highly
>> secure system would generate an ACL to deny all traffic to and
>> from, except to access it via console when it comes up. Can you
>>     come with some other use cases? If we can find viable use cases,
>> then yes, would say that reporting opstate for system generated
>> ACLs is useful.
>>
>> Dean
>>
>>>  
>>> Thanks,
>>> Kent
>>>  
>>> *From: *Dean Bogdanovic >> <mailto:ivand...@gmail.com>>
>>> *Date: *Friday, November 11, 2016 at 3:45 PM
>>> *To: *Kent Watsen mailto:kwat...@juniper.net>>
>>> *Cc: *"netmod@ietf.org <mailto:netmod@ietf.org>"
>>> mailto:netmod@ietf.org>>
>>> *Subject: *Re: [netmod] WG Last Call for
>>&g

Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 2016)

[Acee Lindem (acee)]

Hi Dean,
If you make this a list of heterogeneous IPv4 header fields, how will you 
constrain specification to only one field of each type? For example, one source 
address? Existing implementations do not support multiples and generate all 
permutations (given multiple specifications of each field) could be complex.
Thanks,
Acee


From: netmod mailto:netmod-boun...@ietf.org>> on 
behalf of Dean Bogdanovic mailto:ivand...@gmail.com>>
Date: Tuesday, November 15, 2016 at 10:06 AM
To: Kent Watsen mailto:kwat...@juniper.net>>
Cc: "netmod@ietf.org<mailto:netmod@ietf.org>" 
mailto:netmod@ietf.org>>
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until 
Oct 27, 2016)

I have something that might delay WGLC, but found out an optimization which 
would help in the future

In ietf-packet-fields.yang, example below

grouping acl-ipv4-header-fields {
   description
 "Fields in IPv4 header.";
   leaf destination-ipv4-network {
 type inet:ipv4-prefix;
 description
   "Destination IPv4 address prefix.";
   }
   leaf source-ipv4-network {
 type inet:ipv4-prefix;
 description
   "Source IPv4 address prefix.";
   }
 }

Instead of using "leaf" for "destination-ipv4-network" and 
"source-ipv4-network", "leaf-list" reduces the number of terms/ace needed.

If we would agree with this change, then would propose one more

for mac-addresses, having the mask under the address itself look better in the 
data itself:

  
01:01:01:00:00:00
ff:ff:ff:00:00:00
  

  Or create a new type 'mac-address-prefix'.

  This allows having matching multiple destinations to 1 source, or multiple 
sources to 1 destination, if they cannot be easily combined into 1 entry.

  
01:01:01:00:00:00
ff:ff:ff:00:00:00
  
  
01:04:01:00:00:00
ff:ff:ff:00:00:00
  
  

  
On Nov 14, 2016, at 7:35 AM, Dean Bogdanovic 
mailto:ivand...@gmail.com>> wrote:

Kent,

Thank you for the answer
On Nov 13, 2016, at 1:20 PM, Kent Watsen 
mailto:kwat...@juniper.net>> wrote:

Hi Dean,

> Don’t understand your question. What is the difference between system and 
> user generated acls?

User-generated would be, for instance, configured via NETCONF or RESTCONF, 
whereas system-generated would be ACLs that get created by default.  For 
example, RFC 7223 has the top-level /interfaces-state to support 
system-generated interfaces (e.g., lo) so, when running `shows interfaces`, the 
result includes both configured and system-generated interfaces.   Makes sense?

I understand now what you meant. Where I can see for the interfaces the use 
case you describe (for loopback and physical interfaces), for ACLs have much 
harder time to find an example use case where a system would generate an ACL. 
Maybe for a highly secure system would generate an ACL to deny all traffic to 
and from, except to access it via console when it comes up. Can you come with 
some other use cases? If we can find viable use cases, then yes, would say that 
reporting opstate for system generated ACLs is useful.

Dean


Thanks,
Kent

From: Dean Bogdanovic mailto:ivand...@gmail.com>>
Date: Friday, November 11, 2016 at 3:45 PM
To: Kent Watsen mailto:kwat...@juniper.net>>
Cc: "netmod@ietf.org<mailto:netmod@ietf.org>" 
mailto:netmod@ietf.org>>
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until 
Oct 27, 2016)


On Oct 29, 2016, at 4:01 AM, Kent Watsen 
mailto:kwat...@juniper.net>> wrote:

The last call period for this draft has ended.   Thank you to all that 
responded.  Given the responses received, my co-chair and I believe that the 
draft is ready to move forward.  I will begin the shepherd write-up shortly.
In parallel, prompted by a conversation I had this morning, I’m wondering about 
the YANG module’s use of the config false nodes ‘acl-oper-data’ and 
‘ace-oper-data’.  In particular, are the lifetimes of these nodes always the 
same as the configured nodes?

Yes, they are. When the nodes are created, they are don’t have to be attached 
to an another object, like interface or RIB, etc, but they get operational 
state. Once attached, (to continue with the example) operational status of 
counters is changing. When detached from the interface, the last know counter 
is kept, until the ace is deleted. Same is for acl-oper-data.

- is there any need to support reporting opstate for system-generated acts?

Don’t understand your question. What is the difference between system and user 
generated acls?

Dean


Thanks,
Kent (as shepherd)


From: netmod mailto:netmod-boun...@ietf.org>> on 
behalf of Kent Watsen mailto:kwat...@juniper.net>>
Date: Thursday, October 13, 2016 at 5:05 PM
To: "netmod@ietf.org<mailto:netmod@ietf.org>" 
mailto:netmod@ietf.org>>
Subject: [netmod] WG Last Call for draft-ietf-netmod-acl

Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 2016)

[Dean Bogdanovic]

I have something that might delay WGLC, but found out an optimization which 
would help in the future

In ietf-packet-fields.yang, example below

grouping acl-ipv4-header-fields {
   description
 "Fields in IPv4 header.";
   leaf destination-ipv4-network {
 type inet:ipv4-prefix;
 description
   "Destination IPv4 address prefix.";
   }
   leaf source-ipv4-network {
 type inet:ipv4-prefix;
 description
   "Source IPv4 address prefix.";
   }
 }

Instead of using "leaf" for "destination-ipv4-network" and 
"source-ipv4-network", "leaf-list" reduces the number of terms/ace needed.

If we would agree with this change, then would propose one more 

for mac-addresses, having the mask under the address itself look better in the 
data itself:

  
01:01:01:00:00:00
ff:ff:ff:00:00:00
  

  Or create a new type 'mac-address-prefix'.

  This allows having matching multiple destinations to 1 source, or multiple 
sources to 1 destination, if they cannot be easily combined into 1 entry.

  
01:01:01:00:00:00
ff:ff:ff:00:00:00
  
  
01:04:01:00:00:00
ff:ff:ff:00:00:00
  
  

  
> On Nov 14, 2016, at 7:35 AM, Dean Bogdanovic  wrote:
> 
> Kent,
> 
> Thank you for the answer
>> On Nov 13, 2016, at 1:20 PM, Kent Watsen > <mailto:kwat...@juniper.net>> wrote:
>> 
>> Hi Dean,
>>  
>> > Don’t understand your question. What is the difference between system and 
>> > user generated acls?
>>  
>> User-generated would be, for instance, configured via NETCONF or RESTCONF, 
>> whereas system-generated would be ACLs that get created by default.  For 
>> example, RFC 7223 has the top-level /interfaces-state to support 
>> system-generated interfaces (e.g., lo) so, when running `shows interfaces`, 
>> the result includes both configured and system-generated interfaces.   Makes 
>> sense?
> 
> I understand now what you meant. Where I can see for the interfaces the use 
> case you describe (for loopback and physical interfaces), for ACLs have much 
> harder time to find an example use case where a system would generate an ACL. 
> Maybe for a highly secure system would generate an ACL to deny all traffic to 
> and from, except to access it via console when it comes up. Can you come with 
> some other use cases? If we can find viable use cases, then yes, would say 
> that reporting opstate for system generated ACLs is useful.
> 
> Dean
> 
>>  
>> Thanks,
>> Kent
>>  
>> From: Dean Bogdanovic mailto:ivand...@gmail.com>>
>> Date: Friday, November 11, 2016 at 3:45 PM
>> To: Kent Watsen mailto:kwat...@juniper.net>>
>> Cc: "netmod@ietf.org <mailto:netmod@ietf.org>" > <mailto:netmod@ietf.org>>
>> Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until 
>> Oct 27, 2016)
>>  
>>  
>>> On Oct 29, 2016, at 4:01 AM, Kent Watsen >> <mailto:kwat...@juniper.net>> wrote:
>>>  
>>> The last call period for this draft has ended.   Thank you to all that 
>>> responded.  Given the responses received, my co-chair and I believe that 
>>> the draft is ready to move forward.  I will begin the shepherd write-up 
>>> shortly.
>>> In parallel, prompted by a conversation I had this morning, I’m wondering 
>>> about the YANG module’s use of the config false nodes ‘acl-oper-data’ and 
>>> ‘ace-oper-data’.  In particular, are the lifetimes of these nodes always 
>>> the same as the configured nodes? 
>>  
>> Yes, they are. When the nodes are created, they are don’t have to be 
>> attached to an another object, like interface or RIB, etc, but they get 
>> operational state. Once attached, (to continue with the example) operational 
>> status of counters is changing. When detached from the interface, the last 
>> know counter is kept, until the ace is deleted. Same is for acl-oper-data.
>>  
>>> - is there any need to support reporting opstate for system-generated acts?
>>  
>> Don’t understand your question. What is the difference between system and 
>> user generated acls?
>>  
>> Dean
>>  
>>>  
>>> Thanks,
>>> Kent (as shepherd)
>>>  
>>>  
>>> From: netmod mailto:netmod-boun...@ietf.org>> on 
>>> behalf of Kent Watsen mailto:kwat...@juniper.net>>
>>> Date: Thursday, October 13, 2016 at 5:05 PM
>>> To: "netmod@ietf.org <mailto:netmod@ietf.org>" >> <mailto:netmod@ietf.org>>
>>> Subject: [netmod] WG Last Call for draft-ietf-netmod-acl-

Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 2016)

[Dean Bogdanovic]

Kent,

Thank you for the answer
> On Nov 13, 2016, at 1:20 PM, Kent Watsen  wrote:
> 
> Hi Dean,
>  
> > Don’t understand your question. What is the difference between system and 
> > user generated acls?
>  
> User-generated would be, for instance, configured via NETCONF or RESTCONF, 
> whereas system-generated would be ACLs that get created by default.  For 
> example, RFC 7223 has the top-level /interfaces-state to support 
> system-generated interfaces (e.g., lo) so, when running `shows interfaces`, 
> the result includes both configured and system-generated interfaces.   Makes 
> sense?

I understand now what you meant. Where I can see for the interfaces the use 
case you describe (for loopback and physical interfaces), for ACLs have much 
harder time to find an example use case where a system would generate an ACL. 
Maybe for a highly secure system would generate an ACL to deny all traffic to 
and from, except to access it via console when it comes up. Can you come with 
some other use cases? If we can find viable use cases, then yes, would say that 
reporting opstate for system generated ACLs is useful.

Dean

>  
> Thanks,
> Kent
>  
> From: Dean Bogdanovic 
> Date: Friday, November 11, 2016 at 3:45 PM
> To: Kent Watsen 
> Cc: "netmod@ietf.org" 
> Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until 
> Oct 27, 2016)
>  
>  
>> On Oct 29, 2016, at 4:01 AM, Kent Watsen > <mailto:kwat...@juniper.net>> wrote:
>>  
>> The last call period for this draft has ended.   Thank you to all that 
>> responded.  Given the responses received, my co-chair and I believe that the 
>> draft is ready to move forward.  I will begin the shepherd write-up shortly.
>> In parallel, prompted by a conversation I had this morning, I’m wondering 
>> about the YANG module’s use of the config false nodes ‘acl-oper-data’ and 
>> ‘ace-oper-data’.  In particular, are the lifetimes of these nodes always the 
>> same as the configured nodes? 
>  
> Yes, they are. When the nodes are created, they are don’t have to be attached 
> to an another object, like interface or RIB, etc, but they get operational 
> state. Once attached, (to continue with the example) operational status of 
> counters is changing. When detached from the interface, the last know counter 
> is kept, until the ace is deleted. Same is for acl-oper-data.
>  
>> - is there any need to support reporting opstate for system-generated acts?
>  
> Don’t understand your question. What is the difference between system and 
> user generated acls?
>  
> Dean
>  
>>  
>> Thanks,
>> Kent (as shepherd)
>>  
>>  
>> From: netmod mailto:netmod-boun...@ietf.org>> on 
>> behalf of Kent Watsen mailto:kwat...@juniper.net>>
>> Date: Thursday, October 13, 2016 at 5:05 PM
>> To: "netmod@ietf.org <mailto:netmod@ietf.org>" > <mailto:netmod@ietf.org>>
>> Subject: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 
>> 27, 2016)
>>  
>>  
>> This is a notice to start a two-week NETMOD WG last call for the document:
>>  
>>Network Access Control List (ACL) YANG Data Model
>>https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09 
>> <https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09>
>>  
>> Please indicate your support or concerns by Thursday, October 27, 2016.
>>  
>> We are particularly interested in statements of the form:
>>   * I have reviewed draft-ietf-netmod-acl-model-09 and found no issues.
>>   * I have reviewed draft-ietf-netmod-acl-model-09 and found the following 
>> issues: ...
>>  
>> As well as:
>>  * I have implemented the data model in draft-ietf-netmod-acl-model-09.
>>   * I am implementing the data model in draft-ietf-netmod-acl-model-09.
>>   * I am considering to implement the data model in 
>> draft-ietf-netmod-acl-model-09.
>>   * I am not considering to implement the data model in 
>> draft-ietf-netmod-acl-model-09.
>>  
>> Thank you,
>> NETMOD WG Chairs
>>  
>>  
>> ___
>> netmod mailing list
>> netmod@ietf.org <mailto:netmod@ietf.org>
>> https://www.ietf.org/mailman/listinfo/netmod 
>> <https://www.ietf.org/mailman/listinfo/netmod>
> 
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 2016)

[Kent Watsen]

Hi Dean,

> Don’t understand your question. What is the difference between system and 
> user generated acls?

User-generated would be, for instance, configured via NETCONF or RESTCONF, 
whereas system-generated would be ACLs that get created by default.  For 
example, RFC 7223 has the top-level /interfaces-state to support 
system-generated interfaces (e.g., lo) so, when running `shows interfaces`, the 
result includes both configured and system-generated interfaces.   Makes sense?

Thanks,
Kent

From: Dean Bogdanovic 
Date: Friday, November 11, 2016 at 3:45 PM
To: Kent Watsen 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until 
Oct 27, 2016)


On Oct 29, 2016, at 4:01 AM, Kent Watsen 
mailto:kwat...@juniper.net>> wrote:

The last call period for this draft has ended.   Thank you to all that 
responded.  Given the responses received, my co-chair and I believe that the 
draft is ready to move forward.  I will begin the shepherd write-up shortly.
In parallel, prompted by a conversation I had this morning, I’m wondering about 
the YANG module’s use of the config false nodes ‘acl-oper-data’ and 
‘ace-oper-data’.  In particular, are the lifetimes of these nodes always the 
same as the configured nodes?

Yes, they are. When the nodes are created, they are don’t have to be attached 
to an another object, like interface or RIB, etc, but they get operational 
state. Once attached, (to continue with the example) operational status of 
counters is changing. When detached from the interface, the last know counter 
is kept, until the ace is deleted. Same is for acl-oper-data.

- is there any need to support reporting opstate for system-generated acts?

Don’t understand your question. What is the difference between system and user 
generated acls?

Dean


Thanks,
Kent (as shepherd)


From: netmod mailto:netmod-boun...@ietf.org>> on 
behalf of Kent Watsen mailto:kwat...@juniper.net>>
Date: Thursday, October 13, 2016 at 5:05 PM
To: "netmod@ietf.org<mailto:netmod@ietf.org>" 
mailto:netmod@ietf.org>>
Subject: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 
27, 2016)


This is a notice to start a two-week NETMOD WG last call for the document:

   Network Access Control List (ACL) YANG Data Model
   https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09

Please indicate your support or concerns by Thursday, October 27, 2016.

We are particularly interested in statements of the form:
  * I have reviewed draft-ietf-netmod-acl-model-09 and found no issues.
  * I have reviewed draft-ietf-netmod-acl-model-09 and found the following 
issues: ...

As well as:
 * I have implemented the data model in draft-ietf-netmod-acl-model-09.
  * I am implementing the data model in draft-ietf-netmod-acl-model-09.
  * I am considering to implement the data model in 
draft-ietf-netmod-acl-model-09.
  * I am not considering to implement the data model in 
draft-ietf-netmod-acl-model-09.

Thank you,
NETMOD WG Chairs


___
netmod mailing list
netmod@ietf.org<mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 2016)

[Dean Bogdanovic]

> On Oct 29, 2016, at 4:01 AM, Kent Watsen  wrote:
> 
> The last call period for this draft has ended.   Thank you to all that 
> responded.  Given the responses received, my co-chair and I believe that the 
> draft is ready to move forward.  I will begin the shepherd write-up shortly.
> In parallel, prompted by a conversation I had this morning, I’m wondering 
> about the YANG module’s use of the config false nodes ‘acl-oper-data’ and 
> ‘ace-oper-data’.  In particular, are the lifetimes of these nodes always the 
> same as the configured nodes? 

Yes, they are. When the nodes are created, they are don’t have to be attached 
to an another object, like interface or RIB, etc, but they get operational 
state. Once attached, (to continue with the example) operational status of 
counters is changing. When detached from the interface, the last know counter 
is kept, until the ace is deleted. Same is for acl-oper-data.

> - is there any need to support reporting opstate for system-generated acts?

Don’t understand your question. What is the difference between system and user 
generated acls?

Dean

> 
> Thanks,
> Kent (as shepherd)
>  
>  
> From: netmod mailto:netmod-boun...@ietf.org>> on 
> behalf of Kent Watsen mailto:kwat...@juniper.net>>
> Date: Thursday, October 13, 2016 at 5:05 PM
> To: "netmod@ietf.org <mailto:netmod@ietf.org>"  <mailto:netmod@ietf.org>>
> Subject: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 
> 27, 2016)
>  
>  
> This is a notice to start a two-week NETMOD WG last call for the document:
>  
>Network Access Control List (ACL) YANG Data Model
>https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09 
> <https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09>
>  
> Please indicate your support or concerns by Thursday, October 27, 2016.
>  
> We are particularly interested in statements of the form:
>   * I have reviewed draft-ietf-netmod-acl-model-09 and found no issues.
>   * I have reviewed draft-ietf-netmod-acl-model-09 and found the following 
> issues: ...
>  
> As well as:
>  * I have implemented the data model in draft-ietf-netmod-acl-model-09.
>   * I am implementing the data model in draft-ietf-netmod-acl-model-09.
>   * I am considering to implement the data model in 
> draft-ietf-netmod-acl-model-09.
>   * I am not considering to implement the data model in 
> draft-ietf-netmod-acl-model-09.
>  
> Thank you,
> NETMOD WG Chairs
>  
>  
> ___
> netmod mailing list
> netmod@ietf.org <mailto:netmod@ietf.org>
> https://www.ietf.org/mailman/listinfo/netmod 
> <https://www.ietf.org/mailman/listinfo/netmod>

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 2016)

[Kent Watsen]

Authors,

I’m hoping for a response regarding if there a need to support report opstate 
for system-generated ACLs?

Also, can you please respond to this older review: 
https://www.ietf.org/mail-archive/web/netmod/current/msg16812.html.

Thanks,
Kent (as shepherd)


From: netmod  on behalf of Kent Watsen 

Date: Friday, October 28, 2016 at 3:01 PM
To: "netmod@ietf.org" 
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until 
Oct 27, 2016)

The last call period for this draft has ended.   Thank you to all that 
responded.  Given the responses received, my co-chair and I believe that the 
draft is ready to move forward.  I will begin the shepherd write-up shortly.

In parallel, prompted by a conversation I had this morning, I’m wondering about 
the YANG module’s use of the config false nodes ‘acl-oper-data’ and 
‘ace-oper-data’.  In particular, are the lifetimes of these nodes always the 
same as the configured nodes?  - is there any need to support reporting opstate 
for system-generated acls?

Thanks,
Kent (as shepherd)


From: netmod  on behalf of Kent Watsen 

Date: Thursday, October 13, 2016 at 5:05 PM
To: "netmod@ietf.org" 
Subject: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 
27, 2016)


This is a notice to start a two-week NETMOD WG last call for the document:

   Network Access Control List (ACL) YANG Data Model
   https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09

Please indicate your support or concerns by Thursday, October 27, 2016.

We are particularly interested in statements of the form:
  * I have reviewed draft-ietf-netmod-acl-model-09 and found no issues.
  * I have reviewed draft-ietf-netmod-acl-model-09 and found the following 
issues: ...

As well as:
 * I have implemented the data model in draft-ietf-netmod-acl-model-09.
  * I am implementing the data model in draft-ietf-netmod-acl-model-09.
  * I am considering to implement the data model in 
draft-ietf-netmod-acl-model-09.
  * I am not considering to implement the data model in 
draft-ietf-netmod-acl-model-09.

Thank you,
NETMOD WG Chairs


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 2016)

[Kent Watsen]

The last call period for this draft has ended.   Thank you to all that 
responded.  Given the responses received, my co-chair and I believe that the 
draft is ready to move forward.  I will begin the shepherd write-up shortly.
In parallel, prompted by a conversation I had this morning, I’m wondering about 
the YANG module’s use of the config false nodes ‘acl-oper-data’ and 
‘ace-oper-data’.  In particular, are the lifetimes of these nodes always the 
same as the configured nodes?  - is there any need to support reporting opstate 
for system-generated acls?

Thanks,
Kent (as shepherd)


From: netmod  on behalf of Kent Watsen 

Date: Thursday, October 13, 2016 at 5:05 PM
To: "netmod@ietf.org" 
Subject: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 
27, 2016)


This is a notice to start a two-week NETMOD WG last call for the document:

   Network Access Control List (ACL) YANG Data Model
   https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09

Please indicate your support or concerns by Thursday, October 27, 2016.

We are particularly interested in statements of the form:
  * I have reviewed draft-ietf-netmod-acl-model-09 and found no issues.
  * I have reviewed draft-ietf-netmod-acl-model-09 and found the following 
issues: ...

As well as:
 * I have implemented the data model in draft-ietf-netmod-acl-model-09.
  * I am implementing the data model in draft-ietf-netmod-acl-model-09.
  * I am considering to implement the data model in 
draft-ietf-netmod-acl-model-09.
  * I am not considering to implement the data model in 
draft-ietf-netmod-acl-model-09.

Thank you,
NETMOD WG Chairs


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 2016)

[Jeff Tantsura]

Yes/support

 

 

Cheers,

Jeff

 

 

 

 

This is a notice to start a two-week NETMOD WG last call for the document:

 

   Network Access Control List (ACL) YANG Data Model

   https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09

 

Please indicate your support or concerns by Thursday, October 27, 2016.

 

We are particularly interested in statements of the form:

  * I have reviewed draft-ietf-netmod-acl-model-09 and found no issues.

  * I have reviewed draft-ietf-netmod-acl-model-09 and found the following 
issues: ...

 

As well as:

 * I have implemented the data model in draft-ietf-netmod-acl-model-09.

  * I am implementing the data model in draft-ietf-netmod-acl-model-09.

  * I am considering to implement the data model in 
draft-ietf-netmod-acl-model-09.

  * I am not considering to implement the data model in 
draft-ietf-netmod-acl-model-09.

 

Thank you,

NETMOD WG Chairs

 

 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 2016)

[Mahesh Jethanandani]

And Cisco being the other vendor to have implemented the model.

> On Oct 27, 2016, at 6:55 AM, Dean Bogdanovic  wrote:
> 
> Paul,
> 
> I apologize. Volta Networks implemented the draft.
> 
> Dean
> 
>> On Oct 27, 2016, at 9:52 AM, Doolan, Paul (Coriant - US/Irving) 
>> mailto:paul.doo...@coriant.com>> wrote:
>> 
>> Not sure if there's explicit IETF rules on this and I know we're all 
>> individual contributors but, as a courtesy, will people claiming 
>> implementations and using a non company email domain (e.g @gmail.com 
>> )  indicate which organization it is that's done the 
>> implementing. 
>> 
>> thanks,
>> pd
>> 
>> On Oct 27, 2016, at 9:13 AM, Dean Bogdanovic > >
>>  wrote:
>> 
>>> I support this draft publication and we have implemented this draft, so 
>>> there is another vendor implementation.
>>> 
>>> Dean
>>> 
 On Oct 14, 2016, at 11:13 PM, Mahesh Jethanandani >>> > wrote:
 
 I have reviewed this draft and support its publication. We have 
 implemented the model.
 
 Mahesh Jethanandani
 mjethanand...@gmail.com 
 
 On Oct 13, 2016, at 5:05 PM, Kent Watsen >>> > wrote:
 
>  
> This is a notice to start a two-week NETMOD WG last call for the document:
>  
>Network Access Control List (ACL) YANG Data Model
>https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09 
> 
>  
> Please indicate your support or concerns by Thursday, October 27, 2016.
>  
> We are particularly interested in statements of the form:
>   * I have reviewed draft-ietf-netmod-acl-model-09 and found no issues.
>   * I have reviewed draft-ietf-netmod-acl-model-09 and found the 
> following issues: ...
>  
> As well as:
>  * I have implemented the data model in draft-ietf-netmod-acl-model-09.
>   * I am implementing the data model in draft-ietf-netmod-acl-model-09.
>   * I am considering to implement the data model in 
> draft-ietf-netmod-acl-model-09.
>   * I am not considering to implement the data model in 
> draft-ietf-netmod-acl-model-09.
>  
> Thank you,
> NETMOD WG Chairs
>  
>  
> ___
> netmod mailing list
> netmod@ietf.org 
> https://www.ietf.org/mailman/listinfo/netmod 
> 
 ___
 netmod mailing list
 netmod@ietf.org 
 https://www.ietf.org/mailman/listinfo/netmod 
 
>>> ___
>>> netmod mailing list
>>> netmod@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/netmod 
>>> 
>> 
> 

Mahesh Jethanandani
mjethanand...@gmail.com



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 2016)

[Dean Bogdanovic]

Paul,

I apologize. Volta Networks implemented the draft.

Dean

> On Oct 27, 2016, at 9:52 AM, Doolan, Paul (Coriant - US/Irving) 
>  wrote:
> 
> Not sure if there's explicit IETF rules on this and I know we're all 
> individual contributors but, as a courtesy, will people claiming 
> implementations and using a non company email domain (e.g @gmail.com 
> )  indicate which organization it is that's done the 
> implementing. 
> 
> thanks,
> pd
> 
> On Oct 27, 2016, at 9:13 AM, Dean Bogdanovic  >
>  wrote:
> 
>> I support this draft publication and we have implemented this draft, so 
>> there is another vendor implementation.
>> 
>> Dean
>> 
>>> On Oct 14, 2016, at 11:13 PM, Mahesh Jethanandani >> > wrote:
>>> 
>>> I have reviewed this draft and support its publication. We have implemented 
>>> the model.
>>> 
>>> Mahesh Jethanandani
>>> mjethanand...@gmail.com 
>>> 
>>> On Oct 13, 2016, at 5:05 PM, Kent Watsen >> > wrote:
>>> 
  
 This is a notice to start a two-week NETMOD WG last call for the document:
  
Network Access Control List (ACL) YANG Data Model
https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09 
 
  
 Please indicate your support or concerns by Thursday, October 27, 2016.
  
 We are particularly interested in statements of the form:
   * I have reviewed draft-ietf-netmod-acl-model-09 and found no issues.
   * I have reviewed draft-ietf-netmod-acl-model-09 and found the following 
 issues: ...
  
 As well as:
  * I have implemented the data model in draft-ietf-netmod-acl-model-09.
   * I am implementing the data model in draft-ietf-netmod-acl-model-09.
   * I am considering to implement the data model in 
 draft-ietf-netmod-acl-model-09.
   * I am not considering to implement the data model in 
 draft-ietf-netmod-acl-model-09.
  
 Thank you,
 NETMOD WG Chairs
  
  
 ___
 netmod mailing list
 netmod@ietf.org 
 https://www.ietf.org/mailman/listinfo/netmod 
 
>>> ___
>>> netmod mailing list
>>> netmod@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/netmod 
>>> 
>> ___
>> netmod mailing list
>> netmod@ietf.org 
>> https://www.ietf.org/mailman/listinfo/netmod
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 2016)

[Doolan, Paul (Coriant - US/Irving)]

Not sure if there's explicit IETF rules on this and I know we're all individual 
contributors but, as a courtesy, will people claiming implementations and using 
a non company email domain (e.g @gmail.com)  indicate which 
organization it is that's done the implementing.

thanks,
pd

On Oct 27, 2016, at 9:13 AM, Dean Bogdanovic 
mailto:ivand...@gmail.com>>
 wrote:

I support this draft publication and we have implemented this draft, so there 
is another vendor implementation.

Dean

On Oct 14, 2016, at 11:13 PM, Mahesh Jethanandani 
mailto:mjethanand...@gmail.com>> wrote:

I have reviewed this draft and support its publication. We have implemented the 
model.

Mahesh Jethanandani
mjethanand...@gmail.com

On Oct 13, 2016, at 5:05 PM, Kent Watsen 
mailto:kwat...@juniper.net>> wrote:


This is a notice to start a two-week NETMOD WG last call for the document:

   Network Access Control List (ACL) YANG Data Model
   https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09

Please indicate your support or concerns by Thursday, October 27, 2016.

We are particularly interested in statements of the form:
  * I have reviewed draft-ietf-netmod-acl-model-09 and found no issues.
  * I have reviewed draft-ietf-netmod-acl-model-09 and found the following 
issues: ...

As well as:
 * I have implemented the data model in draft-ietf-netmod-acl-model-09.
  * I am implementing the data model in draft-ietf-netmod-acl-model-09.
  * I am considering to implement the data model in 
draft-ietf-netmod-acl-model-09.
  * I am not considering to implement the data model in 
draft-ietf-netmod-acl-model-09.

Thank you,
NETMOD WG Chairs


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 2016)

[Dean Bogdanovic]

I support this draft publication and we have implemented this draft, so there 
is another vendor implementation.

Dean

> On Oct 14, 2016, at 11:13 PM, Mahesh Jethanandani  
> wrote:
> 
> I have reviewed this draft and support its publication. We have implemented 
> the model.
> 
> Mahesh Jethanandani
> mjethanand...@gmail.com 
> 
> On Oct 13, 2016, at 5:05 PM, Kent Watsen  > wrote:
> 
>>  
>> This is a notice to start a two-week NETMOD WG last call for the document:
>>  
>>Network Access Control List (ACL) YANG Data Model
>>https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09 
>> 
>>  
>> Please indicate your support or concerns by Thursday, October 27, 2016.
>>  
>> We are particularly interested in statements of the form:
>>   * I have reviewed draft-ietf-netmod-acl-model-09 and found no issues.
>>   * I have reviewed draft-ietf-netmod-acl-model-09 and found the following 
>> issues: ...
>>  
>> As well as:
>>  * I have implemented the data model in draft-ietf-netmod-acl-model-09.
>>   * I am implementing the data model in draft-ietf-netmod-acl-model-09.
>>   * I am considering to implement the data model in 
>> draft-ietf-netmod-acl-model-09.
>>   * I am not considering to implement the data model in 
>> draft-ietf-netmod-acl-model-09.
>>  
>> Thank you,
>> NETMOD WG Chairs
>>  
>>  
>> ___
>> netmod mailing list
>> netmod@ietf.org 
>> https://www.ietf.org/mailman/listinfo/netmod 
>> 
> ___
> netmod mailing list
> netmod@ietf.org 
> https://www.ietf.org/mailman/listinfo/netmod 
> 
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 2016)

[Mahesh Jethanandani]

I have reviewed this draft and support its publication. We have implemented the 
model.

Mahesh Jethanandani
mjethanand...@gmail.com

> On Oct 13, 2016, at 5:05 PM, Kent Watsen  wrote:
> 
>  
> This is a notice to start a two-week NETMOD WG last call for the document:
>  
>Network Access Control List (ACL) YANG Data Model
>https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09
>  
> Please indicate your support or concerns by Thursday, October 27, 2016.
>  
> We are particularly interested in statements of the form:
>   * I have reviewed draft-ietf-netmod-acl-model-09 and found no issues.
>   * I have reviewed draft-ietf-netmod-acl-model-09 and found the following 
> issues: ...
>  
> As well as:
>  * I have implemented the data model in draft-ietf-netmod-acl-model-09.
>   * I am implementing the data model in draft-ietf-netmod-acl-model-09.
>   * I am considering to implement the data model in 
> draft-ietf-netmod-acl-model-09.
>   * I am not considering to implement the data model in 
> draft-ietf-netmod-acl-model-09.
>  
> Thank you,
> NETMOD WG Chairs
>  
>  
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 2016)

[Kent Watsen]

This is a notice to start a two-week NETMOD WG last call for the document:

   Network Access Control List (ACL) YANG Data Model
   https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09

Please indicate your support or concerns by Thursday, October 27, 2016.

We are particularly interested in statements of the form:
  * I have reviewed draft-ietf-netmod-acl-model-09 and found no issues.
  * I have reviewed draft-ietf-netmod-acl-model-09 and found the following 
issues: ...

As well as:
 * I have implemented the data model in draft-ietf-netmod-acl-model-09.
  * I am implementing the data model in draft-ietf-netmod-acl-model-09.
  * I am considering to implement the data model in 
draft-ietf-netmod-acl-model-09.
  * I am not considering to implement the data model in 
draft-ietf-netmod-acl-model-09.

Thank you,
NETMOD WG Chairs


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod