commit 5f9bb11bb38398d853b487c40c2d1c2ff8f7578d
parent 9a178b9dfff7d6f15d7fdc3a58988ff73d234371
Author: Christian Grothoff <christian@grothoff.org>
Date: Sat, 1 Jul 2023 00:39:35 +0200
clarify that this is about the remote storage, not the local store
Diffstat:
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -2667,34 +2667,35 @@ NICK: john (supplemental)
</t>
<t>
While implementations following this specification will be
- interoperable, if two implementations connect to different storages
+ interoperable, if two implementations connect to different remote storages
they are mutually unreachable.
This can lead to a state where a record exists in the global
namespace for a particular name, but the implementation is not
- communicating with the storage and is hence unable to resolve it.
+ communicating with the remote storage that contains the respective
+ block and is hence unable to resolve it.
This situation is similar to a split-horizon DNS configuration.
- Which storages are implemented usually depends on the application
+ Which remote storages are implemented usually depends on the application
it is built for.
- The storage used will most likely depend on the specific application
+ The remote storage used will most likely depend on the specific application
context using GNS resolution.
For example, one application is the resolution of hidden services
- within the Tor network, which would suggest using Tor routers for storage.
+ within the Tor network, which would suggest using Tor routers for remote storage.
<!-- FIXME: add non-normative reference to Tor / Tor hidden services here? -->
- Implementations of "aggregated" storages are conceivable, but
+ Implementations of "aggregated" remote storages are conceivable, but
are expected to be the exception.
</t>
</section>
<section anchor="security_dht" numbered="true" toc="default">
- <name>DHTs as Storage</name>
+ <name>DHTs as Remote Storage</name>
<t>
This document does not specify the properties of the underlying
- storage which is required by any GNS implementation.
+ remote storage which is required by any GNS implementation.
It is important to note that the properties of the underlying
- storage are directly inherited by the
+ remote storage are directly inherited by the
GNS implementation. This includes both security as well as
other non-functional properties such as scalability and performance.
Implementers should take great care when selecting or implementing
- a DHT for use as storage in a GNS implementation.
+ a DHT for use as remote storage in a GNS implementation.
DHTs with reasonable security and performance properties exist
<xref target="R5N"/>.
It should also be taken into consideration that GNS implementations
