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

From: Eliot Lear <[email-masked]>
Date: Thu, 1 Feb 2018 18:30:45 +0100

Hi Kent,

In the Department of Moving Things Along, I think I counted two comments
that Mahesh addressed during WGLC.  What are next steps?

Eliot

On 17.01.18 22:55, Kent Watsen wrote:
> All,
>
> This starts a two-week working group last call on
> draft-ietf-netmod-acl-model-15.
>
> This working group last call ends on January 31st.
> 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 welcome!
> This is useful and important, even from authors.
>
> Also, could the authors, explicitly CC-ed on this email,
> please confirm at this time that they are unaware of
> any IPR related to this draft.
>
> Thank you,
> NETMOD Chairs
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Kristian Larsson <[email-masked]>
Date: Fri, 2 Feb 2018 08:44:13 +0100

Mahesh,

I've reviewed this model, I think I largely caused the last couple of 
updates to it late last year. Overall I think it is a good model. 
Placement of feature-statements could be debated - no clear answers.
object groupings is something I would like to see in the model but it 
was always deferred.

On 2018-01-22 16:50, Kent Watsen wrote:
> Hi Mahesh,
> 
> Thanks, it doesn't get much more concrete then a pull request  ;)
> 
> Okay, so from a chair/shepherd perspective, can folks please consider 
> this update to -15 as the LC solution to removing the open issue Juergen 
> found in the draft?
> 
> As a contributor, I don't think the name of the groupings or their 
> description statements should allude to something that doesn't exist 
> yet.  Rather than e.g. "source-or-group", could it be instead something 
> like "source-type"?

+1

> Also, the update seems to be for both when 
> specifying networks as well as when specifying port-ranges, but the 
> original issue (see below) only mentioned addresses - is the 
> pull-request actually what's needed and the description of the issue in 
> Section 8 is incomplete?
> 
>      8.  Open Issues
> 
>         o  The current model does not support the concept of "containers"
> 
>              used to contain multiple addresses per rule entry.

Object groupings are useful whenever there are many of something. There 
are usually more address entries than ports, so perhaps more useful for 
addresses, but it can still be useful to say "NFS-PORTS" and mean all 
the ports that NFS use (god knows what they are).

Other have mentioned scale ACL and that it can be solved in other ways. 
To me, this sort of object-groupings is not about optimising things for 
the hardware but rather making it easy for me to write rules. I think it 
is paramount for security that ACLs can be easily read and understood. 
If we do not understand them, then we cannot say they are effective and 
secure. Object groupings greatly improves the readability of ACLs and 
thus makes it easier to write secure ACLs.

I understand the authors wishes to get the first version out the door 
but I can't help but wonder if it isn't just easier to add in object 
groupings now. It's not that damn complicated (they are just lists).
If not, I'm happy to work with them on the next version which could 
include object groupings.

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

    kll

---

From: Eliot Lear <[email-masked]>
Date: Fri, 2 Feb 2018 08:48:16 +0100

Hi Kristian,

On 02.02.18 08:44, Kristian Larsson wrote:
>> this update to -15 as the LC solution to removing the open issue
>> Juergen found in the draft?
>>
>> yet.  Rather than e.g. "source-or-group", could it be instead
>> something like "source-type"?
>
> +1
>
>> Also, the update seems to be for both when specifying networks as
>> well as when specifying port-ranges, but the original issue (see
>> below) only mentioned addresses - is the pull-request actually what's
>> needed and the description of the issue in Section 8 is incomplete?
>>
>>      8.  Open Issues
>>
> Object groupings are useful whenever there are many of something.
> There are usually more address entries than ports, so perhaps more
> useful for addresses, but it can still be useful to say "NFS-PORTS"
> and mean all the ports that NFS use (god knows what they are).
>
> Other have mentioned scale ACL and that it can be solved in other
> ways. To me, this sort of object-groupings is not about optimising
> things for the hardware but rather making it easy for me to write
> rules. I think it is paramount for security that ACLs can be easily
> read and understood. If we do not understand them, then we cannot say
> they are effective and secure. Object groupings greatly improves the
> readability of ACLs and thus makes it easier to write secure ACLs.
>

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

Eliot

---

From: Robert Wilton <[email-masked]>
Date: Fri, 2 Feb 2018 09:53:05 +0000

> what I think is its FIFTH last call, which to me is nothing short of insane.
+1 for publishing the draft now.

If there are further bells and whistles that need to be added then 
ideally they would be covered by an ACL-extensions model that augments 
the base ACL model.  If tweaks are required to the base model to achieve 
it then I think that creating a v2 version of the ACL model is also OK.

Thanks,
Rob

---

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 2 Feb 2018 10:35:48 -0800

> On Jan 22, 2018, at 7:50 AM, Kent Watsen <[email-masked]> wrote:
> 
> Hi Mahesh,
>  
> Okay, so from a chair/shepherd perspective, can folks please consider this update to -15 as the LC solution to removing the open issue Juergen found in the draft?
>  
> As a contributor, I don't think the name of the groupings or their description statements should allude to something that doesn't exist yet.  Rather than e.g. "source-or-group", could it be instead something like "source-type"?    Also, the update seems to be for both when specifying networks as well as when specifying port-ranges, but the original issue (see below) only mentioned addresses - is the pull-request actually what's needed and the description of the issue in Section 8 is incomplete?
>  
>     8.  Open Issues
>  

I have updated the description of the issue on GitHub to refer to IP addresses and ports, the two thing object groups are used for, and removed the Open Issues section in the draft. The PR(#23) has the capability to add this in the future. 

Thanks.

>  
> Thanks,
> Kent
>  
>  
> On 1/21/18, 12:32 AM, "Mahesh Jethanandani" <[email-masked] <mailto:[email-masked]>> wrote:
>  
>  
> 
> 
>> On Jan 20, 2018, at 7:21 AM, Kent Watsen <[email-masked] <mailto:[email-masked]>> wrote:
>>  
>> Hi Mahesh,
>> 
>> I'm okay not adding the ability to reference an external rulebase now, or are you saying that you'd also like to defer priming the YANG model now so that it can be added later in a backwards compatible manner?
>> 
>> If you plan to prime the YANG model so that the ability to reference an external rulebase can added later in a backwards compatible manner, can you please send a concrete proposal to the list so that we can better understand the impact?  
>> 
>> My expectation is that it merely adds a 'choice' statement around the existing rulebase container, thereby enabling something other than a rulebase container to exist some day in the future.  
>  
> That is correct. The proposal is to add a ‘choice’ statement in parts of the model that will allow an external rulebase to be added in the future as another case statement.
>  
> Here is the concrete proposal of what those changes will look like:
>  
> https://github.com/netmod-wg/acl-model/pull/23 <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_netmod-2Dwg_acl-2Dmodel_pull_23&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=TTcVNmD-pP5Jg3P0iLLmNN-oThtmLiDD-i-cfmml-d4&s=9amd15fEoT406blmduaLuqGo7l1Mi0jt86nidbOJ2fU&e=>
>  
> Thanks
>  
> 
>> 
>> If the addition is indeed just this, then I don't believe that it materially changes the ACL model and therefore can be added as a LC comment.  Of course, the WG will want to review the addition for correctness, but otherwise should be alright.
>> 
>> Thanks,
>> Kent // co-chair and shepherd
>> 
>> 
>> ===== original message =====
>> 
>> Kent,
>> 
>> I have not heard a strong requirement to have the open issue fixed in this version of the RFC. We would therefore like to defer it to a bis document.
>> 
>> I will wait for the LC to complete, and update the draft to address all the comments received during the LC.
>> 
>> Thanks.
>> 
>> 
>>> On Jan 17, 2018, at 3:33 PM, Kent Watsen <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> 
>>> H Mahesh,
>>> 
>>> 
>>>>> - There is an open issue in the document (section 8) - are we going
>>>>> to resolve that during WG last call or is this a leftover?
>>>> 
>>>> This will be resolved in the next version of the module. It is
>>>> documented under Issues tab in GitHub. Should we remove it from
>>>> the draft?
>>> 
>>> Most of Juergen's comments are editorial in nature and can truly be handled as part of the LC process, but this open issue has me worried, as it may result in a significant technical change.  
>>> 
>>> What will it take to close this open issue?  Is it just a matter of the getting the WG to agree that it's not an issue, or do we already know that it is a real issue and only the solution is pending?
>>> 
>>> Thanks,
>>> Kent
>>> 
>>> 
>>> 
>>> 
>> 
>> Mahesh Jethanandani
>> [email-masked] <mailto:[email-masked]>
>> 
>> 
> 
>  
> Mahesh Jethanandani
> [email-masked] <mailto:[email-masked]>
> 
> 

Mahesh Jethanandani
[email-masked]