-
Notifications
You must be signed in to change notification settings - Fork 231
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Policy API's order-of-operations system may have undocumented implications #481
Comments
@avatarneil , as discussed during the city-services working group call, please add your use-cases for multiple rule-type policies. |
Hi @jrheard, sorry for not responding earlier, I wanted to take the time to make sure I had a solid response to the issue. I think your understanding of rule-evaluation isn't totally aligned with what the spec is intended to express; the notion of rules taking precedence is meant to apply to the evaluation of the Policy in the context of a particular vehicle, not for a client to ignore rules wholesale. In the scenario you described, at Compliance evaluation time a client (compliance engine) would pipe the vehicle data (events/telemetry/device info) through the rule set. The evaluation would be ordered, so you would evaluate the vehicles against the rules in order. If they match with the first rule, they are not then considered in evaluation of subsequent rules, and so on. This allows flexibility with how the client interprets the results from each rule -- for example, you could have an initial rule which acts as a "filter" for vehicles before they are evaluated for a subsequent rule. The question about the mixing of rule_types is super great, thank you for noticing this issue! As I mentioned in the last City Services WG, when we were first throwing around ideas for the Policy spec we went back and forth on the mixing of rule_types a couple times. For the first few passes of Policy as we were prototyping, rule ordering did not matter at all, there was no interaction between one rule and another; this is when the concept of a Policy with multiple rule_types was brought up. A scenario where it could be useful:
That being said, that policy would make basically no sense because of the implications of rule ordering (you'd get some very strange compliance output). Seems to me like this is totally an artifact of us adding some functionality while brainstorming, never using it, and then making the feature useless (and potentially wrought with peril) down the road without realizing it! I think it'd make sense to rename |
Thanks for that response! That context is very helpful. It seems like we're on the same page re: thinking that |
@jrheard We should look at how this would work in practice in the spec. If it's a breaking change it would need to wait for the next release since 1.1 is a minor release (though if we have lots of requests for breaking changes, it's possible to make it a major release 2.0). Maybe we can address it in a non breaking way (documentation/clarification) until then. |
Is this still a pressing issue we want to address or is it ok to close it for now? |
I think we can close this, open to counter-arguments tho. |
Is your feature request related to a problem? Please describe.
The Policy API has an "order of operations" section, which states:
It seems to me that this means that it would be an error to have multiple
rule_type
s be included in a single Policy.Here's an example to show what I'm talking about: if a server returned a response that had multiple
rule_type
s within a single Policy, then it seems to me that a client that implemented the letter of the spec would be forced to e.g. ignore aspeed
rule if the client had previously encountered an applicablecount
rule earlier in the same Policy.I don’t think that the spec clearly calls this out. I'm opening this issue so I can confirm that I'm understanding this situation correctly, and so that we can update the spec to make this not-mixing-
rule_type
s constraint clear if it does indeed exist.Describe the solution you'd like
I think that the "description" section of the
rules
section of thePolicy
object's definition should be updated to read something like "List of applicable Rule objects, all of which must have the samerule_type
value."It probably couldn't hurt to mention this constraint a couple of other times throughout the spec, e.g. maybe in the "order of operations" section.
Is this a breaking change
Impacted Spec
For which spec is this feature being requested?
policy
Describe alternatives you've considered
None at this time
The text was updated successfully, but these errors were encountered: