4 ms·

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.
- deleted 6y ago
  [deleted]
- schanzen 6y ago
  Your comment does not make sense because it fundamentally says that the spec needs to define the DHT so that no 10 name systems exist. But that is simply nonsense. If you implement a new DNS stub resolver that follows the record wire formats but uses different root servers it will be effectively not the "same" name system as vanilla DNS. It will have different records under names and certainly different security properties. That is the whole point of hyper-local root for DNS. I am simply implying that you are wrong in that we have to specify the underlying layer. Anyone can (should be) able to use the spec an implement it. It could be done on top of Bittorrent (not Kademlia as that is the protocol, not the network!), IPFS (the DHT they use) or any other DHT. With the respective implicatoins on security. It will still be conforming to the spec.

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.

deleted 6y ago
[deleted]
schanzen 6y ago
Your comment does not make sense because it fundamentally says that the spec needs to define the DHT so that no 10 name systems exist. But that is simply nonsense. If you implement a new DNS stub resolver that follows the record wire formats but uses different root servers it will be effectively not the "same" name system as vanilla DNS. It will have different records under names and certainly different security properties. That is the whole point of hyper-local root for DNS. I am simply implying that you are wrong in that we have to specify the underlying layer. Anyone can (should be) able to use the spec an implement it. It could be done on top of Bittorrent (not Kademlia as that is the protocol, not the network!), IPFS (the DHT they use) or any other DHT. With the respective implicatoins on security. It will still be conforming to the spec.