Conversation
|
|
||
| | [[term_transport_address, Transport Address]] Transport Address | ||
| | A physical endpoint address that can be used to communicate with a <<vol1_spec_sdpi_p_actor_somds_provider>>. | ||
| | A physical or virtual endpoint address that can be used to communicate with a <<vol1_spec_sdpi_p_actor_somds_provider>> or <<vol1_spec_sdpi_p_actor_somds_consumer>> . |
There was a problem hiding this comment.
It is actually meant to be a physical transport address only. Any reason you changed that?
There was a problem hiding this comment.
I was thinking of VPNs but isn't the physical address the MAC address? Wouldn't the transport address be the combination of IPv4 or IPv6 address and port number? I guess that ties things to IP transport, while some may be interested in other transports like Bluetooth and carrier pigeon. I may be over thinking this. Chatgpt came up with
"A transport address is a transport-layer identifier consisting of a node locator and an endpoint selector, which together uniquely identify a communication endpoint within a specific transport network."
Anyway, the important part for me was consumer's have transport addresses too. I'll just get rid of the "virtual" part.
| SDC allows a <<vol1_spec_sdpi_p_actor_somds_consumer>> to open multiple, concurrent TCP | ||
| connections to a <<vol1_spec_sdpi_p_actor_somds_provider>>'s hosted services. | ||
| While this offers flexibility for implementations, <<vol1_spec_sdpi_p_actor_somds_provider>> | ||
| may constrain the number of concurrent TCP connections to ensure availability of its |
There was a problem hiding this comment.
Please use increase/improve over ensure.
| [NORMATIVE] | ||
| ==== | ||
| The <<term_manufacturer>> of a <<vol1_spec_sdpi_p_actor_somds_provider>> may limit the number of | ||
| concurrent TCP connections from an individual <<vol1_spec_sdpi_p_actor_somds_consumer>> to its hosted services to ensure availability and |
There was a problem hiding this comment.
This should be removed: "to ensure availability and responsiveness of its <<acronym_sfc,system function contribution>>." Either we move that to the requirement notes or we can just delete it. The same statement is given in the introduction of this clause.
| ** <<term_transport_address>> and/or, | ||
| ** `[source endpoint]` message property (see <<ref_oasis_ws_addressing_2006>>) and/or, | ||
| ** client credentials used for TLS authentication. | ||
| * Securing the connection may be the most expensive part of an operation, so a <<vol1_spec_sdpi_p_actor_somds_provider>> may |
There was a problem hiding this comment.
What does "operation" refer to here?
|
|
||
| ===== Related Requirements | ||
|
|
||
| * RefRequirement:r1001[]: Single connection to consumer for sending reports |
There was a problem hiding this comment.
Why does this macro exist? Shouldn't xref? or <<...>>` do the trick?
There was a problem hiding this comment.
Mainly to provide the json interoperability export cross-referencing independent of the asciidoc source.
| to reduce its connection count and/or frequency. | ||
| ==== | ||
|
|
||
| // todo: specify how client credentials can identify consumer based on the work from the |
There was a problem hiding this comment.
This todo should be added as an issue as otherwise it will get lost
2 participants
📑 Description
Not all providers can support many concurrent consumer connections while some consumers and/or providers may benefit from multiple concurrent connections to mitigate risks. This PR outlines an approach, leveraging the HTTP 429 status code, to support interoperability for both scenarios.
☑ Mandatory Tasks
The following aspects have been respected by the pull request assignee and at least one reviewer: