Mahesh Jethanandani <mjethanand...@gmail.com> 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
> 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.
It wouldn't be the *absence* that implies match on all, but rather it
is the explicit setting of the type to 'any-acl' that means match on
all:
<acl>
<name>my-any-acl</name>
<type>any-acl</type>
</acl>
Having to also define the leaf "any" as well would just be redundant:
<acl>
<name>my-any-acl</name>
<type>any-acl</type>
<aces>
<ace>
<name>my-any-rule</name>
<any/>
</ace>
</aces>
</acl>
BTW, I support Kristian's suggestion of have just the "name" as the
key in the "acl" list, and making "type" mandatory.
I also suggest you remove redundant prefixes in the leaf names,
e.g. as above s/acl-type/type/ s/acl-name/name/ and
s/rule-name/name/. This is how we usually name nodes in the IETF YANG
models.
> 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’.
But do they also have the acl type definition?
/martin
>
> > On Nov 20, 2017, at 2:20 PM, Jeff Haas <jh...@juniper.net> wrote:
> >
> >>
> >> On Nov 20, 2017, at 4:54 PM, Kristian Larsson <krist...@spritelink.net>
> >> 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 <k...@dev.terastrm.net
> >>>> <mailto:k...@dev.terastrm.net>> 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
> mjethanand...@gmail.com
>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
