Re: [netmod] IETF ACL model

[Robert Wilton <[e-mail]>]

On 21/11/2017 16:25, Mahesh Jethanandani wrote:
> [Taking the discussion to the mailing list]
>
> The summary of the discussion happening on a private thread has to do 
> with the ‘any’ container (now leaf) definition in the ACL model for 
> something that matches anything, much like a ‘*’ would do in regex. 
> The discussion has come down to:
>
> - leave the definition as is, so users would have to explicitly define it
What would it mean if the client configured an ACL type of "any" but 
didn't configure the "any" leaf?


>   pro: It is explicit and there would be no confusion about its 
> presence or absence.
>   con: It is verbose, in that every access list entry would have to 
> define it.
>
> - remove the any definition, so an absence of the definition implies 
> match on all. The text in the draft would have to be updated to state 
> this, and YANG parsers would need to watch out for the non-definition 
> in the match container.
>
> Opinion? Preferences?
>
> p.s. Current CLI configurations require explicit declaration of ‘any’.

If we have an "any" leaf that it seems that:
- it only applies for an ACL of type "any-acl", and can't be used for 
other ACL types.
- it has to be applied for an ACL of type "any-acl" (to have any use).
- it makes is ambiguous if the leaf isn't configured, which would sort 
of force the any leaf to be mandatory for ACLs of type "any-acl".

So it seems redundant to me.  I.e. I'm not sure what extra information 
an "any" leaf imparts beyond knowing that the ACL is of type"any-acl".

Thanks,
Rob


>
>> On Nov 20, 2017, at 2:20 PM, Jeff Haas <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>>>
>>> On Nov 20, 2017, at 4:54 PM, Kristian Larsson 
>>> <[e-mail] <mailto:[e-mail]>> wrote:
>>>
>>>
>>>
>>> On 2017-11-20 18:26, Jeff Haas wrote:
>>>> IMO, the contention here is a consequence of proof by assertion. >
>>>>> On Nov 17, 2017, at 5:56 AM, Kristian Larsson 
>>>>> <[e-mail] <mailto:[e-mail]> 
>>>>> <mailto:[e-mail]>> wrote:
>>>>>
>>>>>>>
>>>>>>> Changes I'd like to see to this PR:
>>>>>>> * remove any-acl completely as it serves no purpose (we achieve
>>>>>>>  this through a ACE with no match conditions)
>>>>>> Will let Jeff respond as he articulated this requirement. Agree 
>>>>>> that most platforms have deny as the default. But what if the ace 
>>>>>> entry is something like this:
>>>>>> access-list 11 permit tcp any any
>>>>>> Would the absence of match rules for IP addresses imply any any?
>>>>>
>>>>> An absence of any match means it matches on everything. If there 
>>>>> are no IP matches at all, then yes, it implies any source or 
>>>>> destination address. I don't see why we would need to explicitly 
>>>>> have an any-acl container or leaf to point this out. With the same 
>>>>> concept applied uniformly you would explicitly call out "any" 
>>>>> matches for all types of matches. That would be extremely verbose.
>>>> Where in the model does it say that the absence of a matches 
>>>> container implies a match all vs. match none?
>>>> Where in the normative text of the internet-draft does it say that?
>>>> In the absence of either of the above, an "any" removes ambiguity.
>>>> FWIW, I'm totally fine with removing the any; however you *MUST* 
>>>> clarify the above.  Preferably both in the matches container and 
>>>> also in the normative text.  For my part, I think it's easier on 
>>>> the parser if you basically require at least one item from the 
>>>> container so you don't have to deal with optional contents.  But 
>>>> I'm not the one writing yang parsers for a living.
>>>
>>> I think it's clear that if no match condition is defined for a 
>>> particular (header) field then that means any value will match. It 
>>> is only an extension of this that no match conditions at all means 
>>> we match any and all packets. I think that is logical.
>>>
>>> This can naturally be spelled out in the text :)
>>
>> You think it's clear, but where is it in the document or model?
>>
>> Of such "implied clarity" is many interop bugs made. :-P
>>
>> -- Jeff
>>
>>>
>>> Kind regards,
>>>  Kristian.
>
> Mahesh Jethanandani
> [e-mail] <mailto:[e-mail]>
>