Nicolas De loof

> configs grant access to configs on a per-service basis using the per-service configs configuration. (https://github.com/docker/compose-spec/blob/master/spec.md#configs) could probably be rephrased to clarify the requirement to declare configs a service can...

I expect such things to happen in many places. Only a few of the existing Compose fields will be supported on all platforms. I propose two complimentary approaches here 1....

Could you please open a pull request to fix this?

I like the idea we introduce ingress concept in such an abstract way. By defining an URL we clearly don't just focus on http (even this would probably be 99%...

`routing` might indeed be a more generic noon for this purpose, and we could then have nested attribute to define if those are actually exposed externaly (aka ingress) or just...

@karolz-ms this would be moslty equivalent to an agregate of service-scoped ingress attributes. With [profiles](https://github.com/compose-spec/compose-spec/pull/110) discussion in progress it would anyway make more sense too get this declared at service...

Yes indeed, an abstract ingress declaration I compose file could be either mapped to labels to embrace traeffik (and other) habits, or used by implementation for a plain imperative service...

a top-level `routing` definition will require to link to target services. As sole benefit I can see, it offers a central view on routing rules. But is this what we...

@hangyan if we apply same approach as volumes/networks, this would look like this: ```yaml routing: routeA: - protocol: http path: /A port: 5000 service: svc-A services: foo: ... routes: -...

In addition to my previous comment, main reason volumes and networks have a dedicated section, is that those resources are expected to be used by 1_or_more services, while a `route`...