[Clarify] Does one need to follow geography change chain for a policy

[kheraankit]

Is your feature request related to a problem? Please describe.

Do we need to follow geography changes for a policy? Example: Policy A refers to Geography A. Now Geography B was published to replace Geography A and later C was published to replace B. Does policy A now automatically apply to Geography C if one were to follow the chain of Geography changes then yes? Or should the operator publish new Policies replacing Policy A? Both can do the trick but having clarity/recommendation on approach on the spec will help.

Describe the solution you'd like

A clear and concise description of what you want to happen.

Is this a breaking change

• No, not breaking

Impacted Spec

For which spec is this feature being requested?

• policy

[schnuerle]

I'd like to hear a bit from the community using Policy about how best to handle this, how it reads now, and what improved clarifying wording can look like.

Current wording here states:

"Published policies, like geographies, should be treated as immutable data. Obsoleting or otherwise changing a policy is accomplished by publishing a new policy with a field named prev_policies, a list of UUID references to the policy or policies superseded by the new policy."

My read is that if a geography changes its shape, you need a new policy id. If a policy changes its geography id, then you also need a new policy id.

[jiffyclub]

if a geography changes its shape, you need a new policy id. If a policy changes its geography id, then you also need a new policy id.

This is my take as well. A policy that applies to geography A is fundamentally different than one that applies to geography B and we need to be able to reference both for historical compliance analysis.

[schnuerle]

Moving to a future release for now, unless a PR is made this week.