Multiple provider_ids in Cap Policy

[jackdreillyvia]

Discussed in #708

^{Originally posted by jackdreillyvia October 22, 2021}
This single-provider-cap example policy applies a cap to a single provider.

What is the interpretation of a cap policy when provider_ids is empty or has multiple values? Does it mean that the cap applies independently to each provider, or that the cap is set on the sum of devices summed across all providers in the list (or all providers in the city if provider_ids is empty)?

[schnuerle]

If null or absent, then it applies to all providers. See the provider_ids field description.

If multiple, it's independently on each provider in this list. One provider does not have control over what another provider does.

Do you think there needs to be clarification on this in the spec for multiple providers?

[jackdreillyvia]

Thanks for the reply: To summarize: * null/empty/absent implies all providers * Caps are ALWAYS applied independently to each provider, regardless of the number of providers in the list (null, 0,1,n,...). In other words, you NEVER sum across providers for caps. Could you confirm this? Thanks again!

…

On Wed, 27 Oct 2021 at 16:19, Michael Schnuerle ***@***.***> wrote: If null or absent, then it applies to all providers. See the provider_ids field description <https://github.com/openmobilityfoundation/mobility-data-specification/tree/main/policy#policy> . If multiple, it's independently on each provider in this list. One provider does not have control over what another provider does. Do you think there needs to be clarification on this in the spec for multiple providers? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#714 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ARKQURBQFEQER2TC3M7BKNTUJADANANCNFSM5GZXF5EA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

-- *Jack Reilly* | Engineer | ***@***.*** 55 rue la Boétie, 75008 Paris Find us: www.vianova.io | Read us: Medium <https://medium.com/vianova> | Follow us: LinkedIn <https://www.linkedin.com/company/vianova-io/> | Twitter <https://twitter.com/vianova_io> This email may be confidential or privileged. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it went to the wrong person. Thanks The above terms reflect a potential business arrangement, are provided solely as a basis for further discussion, and are not intended to be and do not constitute a legally binding obligation. No legally binding obligations will be created, implied, or inferred until an agreement in final form is executed in writing by all parties involved.

[schnuerle]

Yes that's my understanding and I'll let some steering committee members weigh in with their thoughts: @jean-populus @marie-x @S-eb

[jackdreillyvia]

Thanks @schnuerle if that's the case, I'd be happy to clarify multi-provider in the docs w/ a PR, if you think the docs would benefit from this.

[schnuerle]

If you'd like to make PR about this, please do. Thank you!

[schnuerle]

If you'd like to make a PR for this based on the new MDS 2.0 please do and we can reopen.