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
