Creating and Maintaining a List of Peers

[rettray]

What is this for? Some use cases ?

[wznira]

That is a great question. @rettray, appreciate your opinion on this.

[caroluri]

Questions have arisen about how a given SDS implementation can become aware of other implementations (peers). Here is a proposed set of “operating rules” for SDS providers to help improve the odds that, in the absence of a centrally maintained list of SDS implementations, all providers are made aware of the existence of other SDS implementations with which they might interact.

First, some definitions:

• Discovery Service: A service that provides capabilities to a service consumer to obtain information about available services.
• Peer: A discovery service that interacts or may interact with other discovery services.
• SWIM Discovery Service (SDS): A discovery service developed according to the SDS Specification.
• SDS Provider: An organization that offers the use of a particular SDS to consumers.
• Peer List: A set of peers that are known by an SDS provider to interact with their particular SDS.

Each SDS provider will agree to operate under the following rules:

1. A centralized list of all SDS peers that is maintained by some authority will not be required or established.
2. Each SDS provider will maintain its own list of peers that interact with its own SDS.
3. Each SDS provider that adds a new peer to its peer list will notify* the other peers on its list about this action (i.e., so the other SDS providers can add the new one to their own lists if they choose to).
4. Each SDS provider that removes a peer from its peer list will notify* the other peers on its list about this action (i.e., so the other SDS providers can delete the existing peer from their own lists if they choose to).

*Methods for notification (Manual? Automated?) are yet to be determined and will be defined and documented on https://discovery.swim.aero/.

[mkaplun]

The set of "operating rules" proposed by @caroluri intends not just to modify the interface and behavioral patterns outlined in the SDS Implementation Specification but also to establish a new approach for interaction among SDSs and their providers.

(A somewhat similar vision was outlined by @luxdlzu in one of his comments for the Fan-out issue and further discussed by @TianYungang and @wznira.)

However, I think it may be helpful to take a step back and try to conceptualize the problem before going into operational level details.

The specification describes a behavioral pattern (Section 2.1.4, USE CASE 04: Discovering previously unknown peers (multiple peers)) and the operation GetPeers that every SDS must perform in order to create a list of all known peers. However, the specification contains no provisions regarding the responsibilities of SDS providers.

This brings a couple of questions:

1. Should the rules of behavior for adding a new peer to the existing SDSs network and providers be formalized?
2. If so, what is the most effective way to represent those rules in a formal manner? Should they be a part of a future version SDS specification, or should they be compiled into a separate document? (What kind of document? Governance policies? SDS Handbook? )

[mkaplun]

This is a follow-up on the previous comments regarding Carol's suggestions for adding or removing a new peer.

3. Each SDS provider that adds a new peer to its peer list will notify* the other peers on its list about this action (i.e., so the other SDS providers can add the new one to their own lists if they choose to).
4. Each SDS provider that removes a peer from its peer list will notify* the other peers on its list about this action (i.e., so the other SDS providers can delete the existing peer from their own lists if they choose to).

1) Because an SDS is a RESTful web service by definition, it is unclear how an instance of SDS can send an unsolicited message (i.e., notify) to other SDSs. The changes to the current SDS interface to support a "push" interaction may require significant changes to the whole SDS architecture and it should be carefully considered whether the effect is worth the necessary effort.

2) However, the following is a use case that describes how a new, previously unknown SDS may become known to the existing SDS network without requiring significant changes to the existing SDS architecture.

Precondition
A new user who owns the SDS X (furthermore referred to as User(X)) has contact information about the User who owns service A, User(A).
(Optional) A "knows" B, and therefore A's list includes A and B.

Scenario 
1. User(X)) contacts User(A) and ask for information (A's endpoint).
2. User(A) provides User(X) with the requested information. 
3. User(X) uses provided endpoint to send the GetPeers() request to A.
4. A returns its list of known peers to X may consist of A and B.
5. A adds X to its list of peers.
6. X may start a search (chain or fan-out) for more peers and/or for a list of services or service descriptions offered by known SDSs.

Here's a sequence diagram for this use case. See also Fan-out issue for details Note: this scenario has been implemented among current SDS practitioners.

3) I also question whether there is a need for the scenario described in Carol's bullet 4. If an instance of SDS is out of service and returns some sort of "not found" error, that service simply won't be included in responses to any requests. It would be entirely up to the owner of the SDS to decide whether to remove that service. This would avoid creating a potentially "expensive" notification mechanism.

[wznira]

I agree with what is implied by @mkaplun and @caroluri's comments that "Creating and Maintaining a List of Peers" should be handled outside the SDS specification and defined as "operating rules" by appropriate governance bodies. The SDS specification defines web services to be implemented by SDS providers. Different ICAO regions may well have different approaches to handle this issue. The GetPeers operations provides a means to accomplish this at the information exchange level.

Precondition A new user who owns the SDS X (furthermore referred to as User(X)) has contact information about the User who owns service A, User(A). (Optional) A "knows" B, and therefore A's list includes A and B.

Scenario

1. User(X)) contacts User(A) and ask for information (A's endpoint).
2. User(A) provides User(X) with the requested information.
3. User(X) uses provided endpoint to send the GetPeers() request to A.
4. A returns its list of known peers to X may consist of A and B.
5. A adds X to its list of peers.
6. X may start a search (chain or fan-out) for more peers and/or for a list of services or service descriptions offered by known SDSs.

Also, Step 1 in @mkaplun's diagram can alternatively be User(X) searches for a Discovery Service in the SWIM registry maintained by User(A). After all, A discovery service is just SWIM service with a Service Category of discovery

[caroluri]

So the consensus is that (a) a centralized list of SDS peers need not be maintained, and (b) the existing SDS architecture is sufficient to allow a new SDS provider to build a peers list, as long as the new provider is aware of or can find at least one other SDS provider to contact, right? I agree that in the current SWIM community, knowledge of the SDS development effort will lead swiftly to knowledge of one or more SDS providers who have been involved in the effort. Continued publicity for discovery.swim.aero is important.

[mkaplun]

I agree with Carol and Wen's assessments.

I also agree that a first known peer can be found simply online, e.g., in a registry or on discovery.swim.aero.

There is one more question I do not have a good answer for: what if the User(X) from @mkaplun comment is someone with whom other peers do not wish to exchange information? As an example, what if Russia found the specification online, built the SDS, and after finding an endpoint, began accessing data provided by other SDSs?

And another big question remains: in the said diagram, User(A) can send User(X) credentials for accessing the A, but should User(A) share credentials for accessing B?