[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0001] branch master updated: public feedback rs
From: |
gnunet |
Subject: |
[lsd0001] branch master updated: public feedback rs |
Date: |
Fri, 29 Apr 2022 12:20:43 +0200 |
This is an automated email from the git hooks/post-receive script.
martin-schanzenbach pushed a commit to branch master
in repository lsd0001.
The following commit(s) were added to refs/heads/master by this push:
new 14f3c80 public feedback rs
14f3c80 is described below
commit 14f3c80c0a9206525f8e2b28eb3446bb406de969
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Fri Apr 29 12:20:25 2022 +0200
public feedback rs
---
rs_review_202204.txt | 63 ++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 63 insertions(+)
diff --git a/rs_review_202204.txt b/rs_review_202204.txt
new file mode 100644
index 0000000..bd5c782
--- /dev/null
+++ b/rs_review_202204.txt
@@ -0,0 +1,63 @@
+I read, and am reviewing, draft-schanzen-gns-13. These comments are public.
+
+It would be appropriate for the [ISE] to publish this document. It is about a
decentralized naming scheme known as GNS (the GNU Name System), analogous to
DNS, that operates over the Internet and allows clients to find information
about servers and services. That seems to fall exactly into the IETF (sic)
domain. I have some questions, which the authors could address: is the GNS
protocol and data structures, etc., "done"? When was the last that affected
interoperability?
+
+The document seems completely and competent. It is certainly in reasonable
editorial shape, and once again I am impressed by the ability of (I assume)
non-native speakers.
+
+The abstract is very nice and definitely makes the document worth reading.
+
+Overall, I think the use of 2119 language isn't right (e.g., there's no
mandatory-to-implement redirection zone type). But I think that is okay given
the stream for this doc.
+
+Some people might be offended by "limiting" IANA registrations (e.g., Sec
5.3.3's PROTO). Maybe you need to have story here and explain that is not the
intent? Or not.
+
+This seems incomplete, since an implementation needs to be able to talk to
remote storage (i.e., the GET in sec 7ff), and that is not defined. Does the
storage need to be globally consistent? What if two views diverge? Suggest you
discuss that. Somewhat addressed in section 9.5, should be joined with the
other global storage sections in my view. Okay if you disagree.
+
+Some minor items, or nits, follow. None of them, in my view, are intended to
block publication.
+
+Abstract, should it mention SDSI?
+
+Sec 1, the first two paragraphs are going to disturb some folks in the IETF
DNS community. Has anyone in DNS, in particular DNSSEC, looked at this? I
think the "in practice it relies on" phrase is wrong. The term "petname"
should have a definition, even if something parenthetical like "petname (user's
personal name for something)." The paragraph containing "In DNS terminology,"
is a *very nice* one.
+
+Sec 2, the items seem in arbitrary order. Consider alphabetical or explaining
the ordering. Each definition might be more clear if the repetition of the
term were omitted as in:
+ Application A component which uses a GNS implementation to ...
+In the "Name" definition, do you mean "applications MAY *require* that ... "?
Using "Zone type" as the term for cipher and encoding seemed strange to me, why
not "Zone Representation" or something shorter? One or two examples before the
terms, with text identifying the parts in the definition, would be helpful.
+
+Sec 3, "cryptographically secured zones" is redundant, aren't all zones
cryptographically secured? Last sentence of first paragraph repeats the
definition we just read. Second para "A zone can be populated by its owner
with ..." A clarification that the distributed storage isn't required by the
protocol would be useful. The text introducing figure 2 makes me think it's
going to show all the flows for a recursive resolution, and it is rather a
high-level view.
+
+Sec 4, which user creates and manages zones? The Zone admin? The end-user?
The forward ref to Section 5.1 should be before the list of algorithms in my
opinion.
+
+Sec 4.1, maybe say "||" is the concatenation operator and that "[a..b]" is the
semi-closed range from A to B-1
+
+Sec 4.2, "strictly monotonically increasing order" I think monotonically is
wrong.
+
+Sec 5, nice to block of IANA numbers for interop. Are timestamps in GNS always
64bit microsec since 1/1/1970? Maybe add a definition or something at the top?
+
+Sec 5.1, period missing in last line.
+
+Sec 5.1.1, the crypto heart starts to appear. ;) This all looks okay to me,
and follows current practice.
+
+Sec 5.1.2, "highest 32 bytes" maybe "top-most"? Nit. SignDerived is clever.
Consider asking CFRG to review the crypto in Sec 5.
+
+Sec 5.2.1+5.2.2, have you thought of allowing multiple REDIRECT records to
achieve some kind of load-balancing or other?
+
+Sec 5.3.1, I would think TLS SNI value is also common for LEHO data.
+
+Sec 5.3.3, not unlike the new SVCB RR type?
+
+Sec 6, is this whole storage strictly necessary for interop? You could split
it off into a separate document. There's not enough here to implement the
storage. What happens to resolution if the GET() fails? I assume that's
discussed.
+
+Sec 7, the application filters record sets. Oh, that is *VERY* interesting.
And that picture is starting to look familiar. Third time?
+
+Sec 7.1+7.2+7.3 very nice, very clear, I could implement this (modulo the
storage aspect).
+
+Sec 9.3 seems very important. Somewhere up near the front you should
forward-link to it. And in the security considerations, backlink.
+
+Sec 9.4, it's difficult because it requires law enforcement, etc., to get the
private key? Is that really so hard? https://xkcd.com/538/
+
+Sec 9.5, "offline signing of records" not quite sure, maybe a better word,
but I cannot think of one.
+
+Sec 9.6, this belongs with Sec 6 I think. Should the DHT be part of the zone
type?
+
+Sec 9.7 is good.
+
+Sec 12, last sentence of paragraph 1. "given that they are built on top of the
same underlying DHT storage." Does that mean *any* implementation should
interoperate? Does an implementation *have to use* the DHT storage?
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [lsd0001] branch master updated: public feedback rs,
gnunet <=