Hi,
That appears to be the current version on the data-tracker. I agree with you that the access-control-list-type leaf should be mandatory. I noticed that the example in Figure 2 has an extra 'top' container and the namespace for 'access-lists' is missing. Andy On Mon, Jun 1, 2015 at 11:31 AM, Nabil Michraf <nabil.mich...@gmail.com> wrote: > Hi all, > > Can you please clarify if we are talking about > https://www.ietf.org/id/draft-ietf-netmod-acl-model-02.txt or some other > draft? > I just want to make sure I am looking at the right ACL model version. > > Thank you, > Nabil > > On Mon, Jun 1, 2015 at 7:06 AM, Dana Blair (dblair) <dbl...@cisco.com> > wrote: >> >> >> >> On 4/13/15, 10:11 AM, "Sterne, Jason (Jason)" >> <jason.ste...@alcatel-lucent.com> wrote: >> >> >Hi guys, >> > >> >Extracting my comments about ACL type into its own thread. I saw Martin >> >also had some comments on this topic. >> > >> >The ACL type was mandatory in an older version of the draft and I think >> >we should put it back as mandatory. Implementations that don't *need* >> >that leaf value can work fine whether they get it during ACL creation or >> >not but some implementations need to know the type. >> >> We don¹t want to make the ACL type mandatory because then we have to a >> create a new type for every combination of match criteria. The model >> should support any combination of >> match criteria with typing optional to map to pre-existing >> implementations. This is a tradeoff between making the model backward >> compatible with existing implementations but >> make it flexible enough so that a new match criteria doesn¹t require a new >> type. >> >> > >> >It would also be good to create separate identities for >> >IPv4-access-control-list and IPv6-access-control-list instead of bundling >> >them into IP-access-control-list. If we're separating into types in the >> >model it should be the 3 basic types in the base model: v4, v6 and enet. >> >> A vendor specific augmentation/implementation could do this, but the model >> needs to support inclusion of ipv4 and ipv6 in the same acl. I¹m aware of >> outstanding customers >> requests for combining ipv4 rules and ipv6 rules in the same acl, but most >> implementations have not caught up to this. When it comes to managing >> acls there shouldn¹t be >> this distinction between IPv6 and IPv4. They are both IP addresses. >> >> > >> >That would also help if we decide to put some constraints that >> >allow/disallow certain matching criteria when the type is a specific >> >value (e.g. don't allow a v6 address match in a v4 list). >> > We'd have to be careful about how those constraints are formulated >> >though - especially if we want to allow augmentations of the list-type >> >for "mixed" ACLs. A new "mixed-v4-enet" type (identity) would also need >> >to use the destination-ipv4-network matching criteria (can "when" or >> >"must" logic be changed by an augmentation ? I'm not sure that works). >> >> Yes, would have to be careful, and defining constraints based on existing >> implementations could be a very slippery slope. Vendors should be able >> to map to their implementations and/or >> have a proprietary augmentation that constrains things more according to >> their implementation. Proprietary augmentations could be proposed, and >> reviewed for standardization. >> >> thanks, >> Dana >> >> > >> >Regards, >> >Jason >> > >> > >> >_______________________________________________ >> >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
