4 ms·

> Why would this be an IETF document when the GNUnet protocol itself isn't? Nothing in the spec suggests it must run on GNUnet. This is almost like asking why

> Why would this be an IETF document when the GNUnet protocol itself isn't? Nothing in the spec suggests it must run on GNUnet. This is almost like asking why should IETF standardize JSON-schema when gRPC is not standardized. One thing does not require the other or depend on the other. > "This document does not specifiy the properties of the underlying distributed hash table (DHT) which is required by any GNS implementation." Well they do specify the interfaces, why should they care about the impliementation? > GNS resource records are published in a distributed hash table (DHT). We assume that a DHT provides two functions: GET(key) and PUT(key,value). > Okay... so... So what?

espadrine 6y ago
>> "This document does not specifiy the properties of the underlying distributed hash table (DHT) which is required by any GNS implementation." > Well they do specify the interfaces, why should they care about the impliementation? The choice of DHT typically has protocolar implications, such as the use of XOR metric in Kademlia, or the bootstrap algorithm. All nodes must use the same DHT. As a result, this cannot be implemented without knowing the particular DHT in use. Furthermore, different DHTs have distinct properties, including provisions for fault tolerance, resource recovery, latency bounds, and byzantine tolerance, which here seems like a concern.
- some-username 6y ago
  Yes, sure. But that's fine - everyone who wants to have their GNS can design their own DHT. It's still outside of the spec. (Which makes a lot of sense to me.)
- jaekash 6y ago
  > The choice of DHT typically has protocolar implications, such as the use of XOR metric in Kademlia, or the bootstrap algorithm. > Furthermore, different DHTs have distinct properties, including provisions for fault tolerance, resource recovery, latency bounds, and byzantine tolerance, which here seems like a concern. What in the RFC is dependent or contingent on those? from what I read in it none of those properties affect what is specified in the draft. > All nodes must use the same DHT. As a result, this cannot be implemented without knowing the particular DHT in use. Not according to the draft. Sure, if a zone uses a specific DHT and then other nodes not using the same DHT they won't be able to resolve addresses from that zones, but everything in this draft would still be valid.
eqvinox 6y ago
> So what? So, it's currently a disconnected lego brick hanging in the air. It serves no purpose until other documents accompany it that specify how to use it either for GNUnet, for IP, or something else. If there is more than one application document coming, at least one should (IMHO) be submitted at the same time¹ in order to aid review and understanding. If only one such application is expected, they should probably be merged into the same document. Particularly, if it's to be applied for non-GNUnet (e.g. IP), it does need to say what underlying DHT is to be used. Otherwise it's not actually a naming system but 10 naming systems – which is, er, rather useless. ¹: it doesn't need to progress or be finalized at the same time, but the document should at least be published.
- antsoul 6y ago
  "lego brick" ? No, it's actually the most important pillars of the digital future (GNS, reclaim:id, Taler, Secushare... all based on gnunet)
- schanzen 6y ago
  This is not true. Please study, for example, https://tools.ietf.org/html/rfc6537 https://tools.ietf.org/html/rfc6537.
  - eqvinox 6y ago
    RFC6537 specifies an "upwards" (application direction) interface to HIP (RFC5201). Through that it is fully wired into IPsec / Mobile IP use. The GNS draft makes references to DNS but doesn't actually say how it would be used in that relationship. RFC6537 references OpenDHT as a "downwards" (wire direction) interface and points to XML-RPC calls and expected behavior on that. The GNS draft simply presumes the existence of a "DHT". Maybe you could tell me which part of my comment is not true? I don't see what your example is intended to illustrate... [Edited to add:] P.S.: please read the guidelines at https://www.ietf.org/standards/process/informational-vs-experimental/ https://www.ietf.org/standards/process/informational-vs-expe... (section 3.) GNS is very much something that can be "practiced" — or rather, it should be possible to practice. I don't think it can with your draft. I suppose that might be why you went for Informational rather than Experimental, but that kinda misses the point: you should be going for Experimental. To walk through the guideline bulletpoints: 1. GNS can be practiced. Or rather: should be. It's a protocol. 2. If you want to push it through the IETF, you should probably open it to changes. What's the point otherwise? The IETF is not a rubber-stamping organization. 3. I'm pretty sure you're not publishing this as "dropped, just for the record"? 4. "If the IETF may publish something based on this on the standards track once we know how well this one works, it's Experimental." I feel that's exactly your intent? 5. Doesn't seem to apply. Maybe it should too? All I'm saying is that your draft should be practice-able, but isn't, and I think it should be.

espadrine 6y ago

>> "This document does not specifiy the properties of the underlying distributed hash table (DHT) which is required by any GNS implementation." > Well they do specify the interfaces, why should they care about the impliementation? The choice of DHT typically has protocolar implications, such as the use of XOR metric in Kademlia, or the bootstrap algorithm. All nodes must use the same DHT. As a result, this cannot be implemented without knowing the particular DHT in use. Furthermore, different DHTs have distinct properties, including provisions for fault tolerance, resource recovery, latency bounds, and byzantine tolerance, which here seems like a concern.

some-username 6y ago
Yes, sure. But that's fine - everyone who wants to have their GNS can design their own DHT. It's still outside of the spec. (Which makes a lot of sense to me.)
jaekash 6y ago
> The choice of DHT typically has protocolar implications, such as the use of XOR metric in Kademlia, or the bootstrap algorithm. > Furthermore, different DHTs have distinct properties, including provisions for fault tolerance, resource recovery, latency bounds, and byzantine tolerance, which here seems like a concern. What in the RFC is dependent or contingent on those? from what I read in it none of those properties affect what is specified in the draft. > All nodes must use the same DHT. As a result, this cannot be implemented without knowing the particular DHT in use. Not according to the draft. Sure, if a zone uses a specific DHT and then other nodes not using the same DHT they won't be able to resolve addresses from that zones, but everything in this draft would still be valid.

eqvinox 6y ago

> So what? So, it's currently a disconnected lego brick hanging in the air. It serves no purpose until other documents accompany it that specify how to use it either for GNUnet, for IP, or something else. If there is more than one application document coming, at least one should (IMHO) be submitted at the same time¹ in order to aid review and understanding. If only one such application is expected, they should probably be merged into the same document. Particularly, if it's to be applied for non-GNUnet (e.g. IP), it does need to say what underlying DHT is to be used. Otherwise it's not actually a naming system but 10 naming systems – which is, er, rather useless. ¹: it doesn't need to progress or be finalized at the same time, but the document should at least be published.

antsoul 6y ago
"lego brick" ? No, it's actually the most important pillars of the digital future (GNS, reclaim:id, Taler, Secushare... all based on gnunet)
schanzen 6y ago
This is not true. Please study, for example, https://tools.ietf.org/html/rfc6537 https://tools.ietf.org/html/rfc6537.
- eqvinox 6y ago
  RFC6537 specifies an "upwards" (application direction) interface to HIP (RFC5201). Through that it is fully wired into IPsec / Mobile IP use. The GNS draft makes references to DNS but doesn't actually say how it would be used in that relationship. RFC6537 references OpenDHT as a "downwards" (wire direction) interface and points to XML-RPC calls and expected behavior on that. The GNS draft simply presumes the existence of a "DHT". Maybe you could tell me which part of my comment is not true? I don't see what your example is intended to illustrate... [Edited to add:] P.S.: please read the guidelines at https://www.ietf.org/standards/process/informational-vs-experimental/ https://www.ietf.org/standards/process/informational-vs-expe... (section 3.) GNS is very much something that can be "practiced" — or rather, it should be possible to practice. I don't think it can with your draft. I suppose that might be why you went for Informational rather than Experimental, but that kinda misses the point: you should be going for Experimental. To walk through the guideline bulletpoints: 1. GNS can be practiced. Or rather: should be. It's a protocol. 2. If you want to push it through the IETF, you should probably open it to changes. What's the point otherwise? The IETF is not a rubber-stamping organization. 3. I'm pretty sure you're not publishing this as "dropped, just for the record"? 4. "If the IETF may publish something based on this on the standards track once we know how well this one works, it's Experimental." I feel that's exactly your intent? 5. Doesn't seem to apply. Maybe it should too? All I'm saying is that your draft should be practice-able, but isn't, and I think it should be.