When the server or a tool receives a notification section, it logs it but does not further processing.
Implement logic there if needed, especially the capability case.
Capabilities sent in response do not need a notification type, they can be attached to a bare message.

Use #45 instead of the current binary trie implementation and make the number of children per node dependent on a server configuration.

Right now we are only able to verify signatures from the global context. Implement methods to extract the authority from the context field and verify the signature(s) against it.

Add a clock synchronization protocol to the rains server.

Change the way how we read in the config file represented as json.
Do not directly read the input into the internal object.

1. Read in values
2. Copy/Cast them to the internal representation.

Design and Implement a high bandwidth airgapping mechanism to sign elements of a zone file.

An external process must be able to dynamically update the blacklist. I.e. that the server has an up to date blacklist which could e.g. be used to defend against DOS attacks

Currently only a section from a message containing the same token as the query message triggers the pending query callback function. Extend the behavior such that an unrelated section also answering the query can be used to directly send the response back

"Reverse lookups are done using a completely separate tree, supporting delegations of any prefix length, in accordance with CIDR [RFC4632] and the IPv6 addressing architecture [RFC4291]" [1]
Also look at section 5.8-5.10
[1] https://britram.github.io/rains-prototype/#introduction

Currently a random section answering the query is returned.
How to efficiently determine which has the smallest encoding size

Implement engine.handleAddressZoneQueryResponse()

RAINS is designed to be address-family and architecture-independent, and initial work has focused on building out RAINS as an Internet naming service. The codebase and protocol need minor updates to be usable as a naming service for SCION:

Subtasks:

• Add support for a :scionip4: assertion object type, carrying a SCION address as an octet array
• Add support for a :scionip6: assertion object type, carrying a SCION address as an octet array
• Design and build tooling to add RAINS root keys to a SCION TRC
• Integrate verification of the RAINS root key against the SCION TRC into RAINS

Add infrastructure signature to all messages sent between servers

Move examples and test servers to a different folder or repo.
There should be an interface where one can specify which kind of servers are wanted and then they get automatically started.

Because we only accept sections from servers and rainspub we need to be able to distinguish them. How can we do that? (for rainspub we can configure it manually but how do we handle other servers?)

Currently assertions are sorted and then split up in groups of a configurable size.
The size is currently per assertion instead of per assertion name. This must be changed. Otherwise if there are more assertions of a name than the configured size, they will always be rejected.

Currently a random connection information is chosen from the redirection cache

implement using #45 and add it to the server

Implement capabilities according to https://britram.github.io/rains-prototype/#rfc.section.5.15
The cache design must be taken into account, but might be changed.

The caches are currently not able to lookup an anyContext query.

The server's ip blacklist should be updated in real time and only messages originating from different addresses are forwarded in the switchboard

engine.containedAssertionQueryResponse()

Make it configurable when consistency checks are stopped. Based on what stats is the load of the system/server evaluated.

We want to remove the dependency between wire and signing format.
We use capnproto to binary encode a rains message before we send it over the wire. The capnproto schema must be refined and a library (which uses capnproto's encode and decode) to encode and decode must be implemented.

First the caches for reverse lookup must be refactored. #45, #46, #47

When a contained assertion or shard is validated it gets dropped in the verify step because it does not yet inherit the signature(s) from its outer section.

Description should be generated from internal constants.
We also want string mnemonics for query options on the command-line.

This includes how Tokens are handled by the server (if they are stored in a cache or not), which determines prioritization of packets and dropping in case of congestion

Use the zone file format to output received messages in the command line

Right now the system can only handle 1 (the first) object per assertion although one could add several. Make it work also for multiple objects per assertion. Be aware that the cache implementation must also be changed.

Currently cap'n'proto is used.

Decide which consistency checks MUST be done at run time by the server and which SHOULD be analyzed by a separate service (which then must be able to take appropriate actions, e.g. remove elements from the server's cache, blacklist an entity, etc.)
Implement/refactor consistency checks
Shard's and Zone's content are sorted. We do not have to sort them for consistency checks but only check that they are really sorted (if not drop the section and send a msgInconsistent notification back).

Document which ports we use and why

We currently have a binary trie data structure. Make it generic and use a n-trie where n is configurable

Currently all non expired assertions are sent back

Design and implement a policy by which the server can decide if it wants to cache the section for
Assertion, Shard, Zone, AddressAssertion, AddressZone.

Instead of loading a hard coded default config and then rewrite parts of it by parsing a json encoded config file, we should create a cmd line interface where these values are the flags' default value.

Write down which operations are necessary for which cache and how performance critical they are.
Which replacement strategy we choose for each.
Find data structures that fit our needs.