Re: [auth48] [ISE] Re: AUTH48: RFC-to-be 9498 <draft-schanzen-gns-28> for your review

["Independent Submissions Editor (Eliot Lear)" <[e-mail]>]

Hi Martin!

On 24.10.2023 13:22, Schanzenbach, Martin wrote:
> Cheers!
>
> Before we start: I assume we can simply make the changes to our xml 
> and upload a new version to address the feedback?
> Or by email?


No need to update the XML, although the RPC can usually manage that as 
well.  Just respond to the Email and state what wording you want, as the 
instructions explain.  As you will see, most of this is just agreeing to 
what the RPC has done.  But you can choose to disagree and clarify.  In 
some cases, you must provide some feedback.


Eliot



>
>
> Best
> Martin
> ------------------------------------------------------------------------
> *Von:* Independent Submissions Editor (Eliot Lear) 
> <[e-mail]>
> *Gesendet:* Dienstag, 24. Oktober 2023 07:04
> *An:* [e-mail] <[e-mail]>; 
> Schanzenbach, Martin <[e-mail]>; 
> [e-mail] <[e-mail]>; [e-mail] 
> <[e-mail]>
> *Cc:* [e-mail] <[e-mail]>
> *Betreff:* Re: [ISE] Re: AUTH48: RFC-to-be 9498 
> <draft-schanzen-gns-28> for your review
> Thank you, RFC Editor.  Authors: please promptly address each point made.
>
> Eliot
>
> On 23.10.2023 18:40, [e-mail] wrote:
> > Authors and Eliot,
> >
> > * Eliot, as ISE, please reply regarding #29.
> >
> > While reviewing this document during AUTH48, please resolve (as 
> necessary) the following questions, which are also in the XML file.
> >
> > 1) <!-- [rfced] Please note that because this XML file was submitted in
> > "prepped" format, we created an "unprepped" file so that we could
> > edit the document properly.  This does not impact the document's
> > text but resulted in many changes to the XML. -->
> >
> >
> > 2) <!-- [rfced] Datatracker "idnits" output for the original approved
> > document included the following warning.  Although an author recently
> > referred to the lines indicated in this warning as "false positives",
> > please let us know if any changes are needed as related to this
> > warning:
> >
> >   == There are 6 instances of lines with non-RFC2606-compliant FQDNs in
> >      the document. -->
> >
> >
> > 3) <!-- [rfced] Abstract and subsequent:  To what does "including" refer
> > in the following sentences?  If our suggestions are incorrect, please
> > clarify the text in each sentence.
> >
> > Original:
> >   It is published here to inform readers about the
> >   function of GNS, guide future GNS implementations, and ensure
> >   interoperability among implementations including with the pre-
> >   existing GNUnet implementation.
> > ...
> >   When names are resolved, signatures on resource
> >   records including delegations are verified by the recursive
> >   resolver.
> > ...
> >   In the remainder of this document, the "implementer" refers to the
> >   developer building a GNS implementation including the resolver, zone
> >   master, and supporting configuration such as start zones (see
> >   Section 7.1).
> > ...
> >   The encoding and decoding symbols for Base32GNS including
> >   this modification are defined in Figure 30.
> > ...
> >   It
> >   defines the context in which the signature is created so that it
> >   cannot be reused in other parts of the protocol including possible
> >   future extensions.
> > ...
> >   It
> >   defines the context in which the signature is created so that it
> >   cannot be reused in other parts of the protocol including possible
> >   future extensions.
> >
> > Suggested:
> >   It is published here to inform readers about the
> >   function of the GNS, guide future GNS implementations, and ensure
> >   interoperability among implementations (for example, pre-
> >   existing GNUnet implementations).
> > ...
> >   When names are resolved, signatures on resource
> >   records, including delegations, are verified by the recursive
> >   resolver.
> > ...
> >   In the remainder of this document, the "implementer" refers to the
> >   developer who builds a GNS implementation that includes the
> >   resolver, zone master, and supporting configuration such as start
> >   zones (see Section 7.1).
> > ...
> >   The encoding and decoding symbols for Base32GNS, including
> >   this variation, are defined in Table 4 (Appendix C).
> > ...
> >   It
> >   defines the context in which the signature is created so that it
> >   cannot be reused in other parts of the protocol that might include
> >   possible future extensions.
> > ...
> >   It
> >   defines the context in which the signature is created so that it
> >   cannot be reused in other parts of the protocol that might include
> >   possible future extensions. -->
> >
> >
> > 4) <!-- [rfced] Please review each artwork element in the XML file.
> > Should any artwork element be tagged as sourcecode? For example,
> > should the "GET / HTTP/1.1" entries in Appendix A.3 be sourcecode
> > with type="http-message", and should the test-vector entries in
> > Appendix D be sourcecode with type="test-vectors"?
> >
> > Please see
> > <https://www.rfc-editor.org/materials/sourcecode-types.txt>; if the
> > current list of preferred values for "type" does not contain an
> > applicable type, please let us know.  Also, it is acceptable to leave
> > the "type" attribute unset. -->
> >
> >
> > 5) <!-- [rfced] The following author comments, as found in the original
> > XML file, appear to be pending.  Is any action required for the
> > following?
> >
> >   FIXME: Is this really really necessary? Really?
> >   FIXME: add non-normative reference to Tor / Tor hidden services here?
> >   FIXME replace with RFC
> >   Check if we want to use RFC8032 instead of paper ed25519 -->
> >
> >
> > 6) <!-- [rfced] Section 1:  As there can only be one "first", we changed
> > "A first" to "One of the first" here.  If this is incorrect, please
> > provide clarifying text.
> >
> > Original:
> >   A first academic description of the
> >   cryptographic ideas behind GNS can be found in [GNS].
> >
> > Currently:
> >   One of the first academic
> >   descriptions of the cryptographic ideas behind GNS can be found in
> >   [GNS]. -->
> >
> >
> > 7) <!-- [rfced] Section 2:  To what does "in examples which is" refer?
> > Should it say "in examples that are" or something else?  Please
> > clarify.
> >
> > Original:
> >   In order to avoid misinterpretation of example
> >   domains with (reserved) DNS domains this draft uses the suffix
> >   ".gns.alt" in examples which is also registered in the GANA ".alt
> >   Subdomains" registry [GANA] (see also [I-D.ietf-dnsop-alt-tld]). -->
> >
> >
> > 8) <!-- [rfced] Section 2:  As it appears that "which" in this text
> > refers to the zTLD (per Sections 4 and 4.1), we updated this item
> > accordingly.  If this is incorrect, please provide clarifying text.
> >
> > Original:
> >   Zone Top-Level Domain  A GNS Zone Top-Level Domain (zTLD) is a
> >      sequence of GNS labels at the end of a GNS name which encodes a
> >      zone type and zone key of a zone (see Section 4.1).
> >
> > Currently:
> >   Zone Top-Level Domain (zTLD):  A GNS zTLD is a sequence of GNS labels
> >      at the end of a GNS name.  The zTLD encodes a zone type and zone
> >      key of a zone (see Section 4.1). -->
> >
> >
> > 9) <!-- [rfced] Section 4.1:  As it appears that "this table" refers to
> > what is now Table 4 in Appendix C, we updated these two sentences
> > accordingly.  If these updates are not correct, please clarify
> > "this table".
> >
> > Original:
> >   The encoding and decoding symbols for Base32GNS including
> >   this modification are defined in Figure 30.  The functions for
> >   encoding and decoding based on this table are called Base32GNS-Encode
> >   and Base32GNS-Decode, respectively.
> >
> > Currently:
> >   The
> >   encoding and decoding symbols for Base32GNS including this
> >   modification are defined in Table 4 (Appendix C). The functions for
> >   encoding and decoding based on Table 4 are called Base32GNS-Encode
> >   and Base32GNS-Decode, respectively. -->
> >
> >
> > 10) <!-- [rfced] Figures 3 through 7 and 20 through 22:  Should the use
> > of vertical lines ("|") versus slashes "/") be made consistent where
> > the continuation of fields is indicated?  If so, how?
> >
> > A few examples (double dashes removed to avoid confusion with XML
> >    comments):
> >
> >   |       ZONE TYPE       |      ZONE KEY         /
> >   +- - -+- - -+- - -+- - -+                       /
> >   /                                               /
> >   /                                               /
> >
> > ...
> >
> >   |       ZONE TYPE       |    ZONE KEY           |
> >   +- - -+- - -+- - -+- - -+                       |
> >   /                                               /
> >   /                                               /
> >
> > ...
> >
> >   |                    BDATA                      /
> >   /                                               /
> >   /                                               |
> >
> > ...
> >
> >   |                    BDATA                      |
> >   /                                               /
> >   /                                               / -->
> >
> >
> > 11) <!-- [rfced] Section 4.2:  We found "a number Z different PoWs"
> > difficult to follow.  We updated the text per the definition of "Z"
> > that appears a few lines later.  Please let us know any objections.
> >
> > Original:
> >   In order to
> >   reduce the variance in time it takes to calculate the PoW, a valid
> >   GNS revocation requires that a number Z different PoWs must be found
> >   that on average have D leading zeroes.
> >
> > Currently:
> >   In order to
> >   reduce the variance in time it takes to calculate the PoW, a valid
> >   GNS revocation requires that a number of different PoWs (Z, as
> >   defined below) must be found that on average have D leading 
> zeroes. -->
> >
> >
> > 12) <!-- [rfced] Section 4.2:  Does "time stamp and public key fields"
> > mean "TIMESTAMP and PUBLIC KEY fields", even though we only see
> > "PUBLIC KEY" mentioned in Sections 5.1.1 and 5.1.2?
> >
> > Original:
> >   The signature over the public key covers a 32-bit header prefixed to
> >   the time stamp and public key fields. -->
> >
> >
> > 13) <!-- [rfced] Sections 4.2 and subsequent: Please note that we
> > updated some of the GANA registry names to match those found on
> > [GANA].  Please review, and let us know any objections.
> >
> > Examples from original:
> >   .alt subdomains (Section 10.2)
> >   GNUnet Signature Purpose (Sections 4.2, 6.3, and 10)
> >   GANA "Overlay Protocols" registry (Section 5.3.3)
> >   GNU Name System Record Types (Section 10.1)
> >   GANA Resource Record (Figure 25 in Section 10.1)
> >
> > Currently:
> >   .alt Subdomains (also per Section 10.2, and per [GANA])
> >   GNUnet Signature Purposes
> >   GANA "GNUnet Overlay Protocols" registry
> >   GNS Record Types
> >   GANA GNS Record Types (title of what is now Table 2) -->
> >
> >
> > 14) <!-- [rfced] Section 4.2:  As it appears that "evict then from"
> > should be "evict them from", we updated accordingly. If this is
> > incorrect, please clarify "evict then from".
> >
> > Original (the previous sentence is included for context):
> >   Verified revocations MUST be stored locally.  The implementation MAY
> >   discard stale revocations and evict then from the local store at any
> >   time.
> >
> > Currently:
> >   The implementation MAY
> >   discard stale revocations and evict them from the local store at any
> >   time. -->
> >
> >
> > 15) <!-- [rfced] Section 5:  Please confirm that "16-bit bit field" (and
> > not "16-bit field") is correct.
> >
> > Original:
> >   FLAGS  is a 16-bit bit field indicating special properties of the
> >      resource record.
> >
> > Possibly:
> >   FLAGS:  16 bits.  A bit field indicating special properties of the
> >      resource record. -->
> >
> >
> > 16) <!-- [rfced] Section 5:  xml2rfc v3 permits superscripting.  Would
> > you like to apply superscripting to numbers where the caret ("^") is
> > used (e.g., 2^16, 2^255)?  The superscripts would appear in the HTML
> > and PDF output files, but the textfile would still show the caret.
> > For an example, please see the last paragraph in Section 2.4.2 of
> > RFC 9426 (https://www.rfc-editor.org/rfc/rfc9426.html).
> >
> > If yes, please also let us know if anything else might need to be
> > superscripted or subscripted. -->
> >
> >
> > 17) <!-- [rfced] Sections 5.1.1 and 5.1.2:  "using an HKDF using" reads
> > oddly.  Does it mean "using an HKDF that uses", "using an HKDF and
> > using" (i.e., the key material is retrieved by using an HKDF as well
> > as the string "key-derivation"), or something else? If this needs to
> > be clarified, please provide updated text.
> >
> > Original:
> >   PRK_h is key material retrieved using an HKDF using the string "key-
> >   derivation" as salt and the zone key as initial keying material.
> > ...
> >   PRK_h is key material retrieved using an HKDF using the string "key-
> >   derivation" as salt and the zone key as initial keying material.
> >
> > Possibly:
> >   PRK_h is key material retrieved using an HKDF that uses the string
> >   "key-derivation" as the salt and the zone key as the initial keying
> >   material.
> > ...
> >   PRK_h is key material retrieved using an HKDF that uses the string
> >   "key-derivation" as the salt and the zone key as the initial keying
> >   material. -->
> >
> >
> > 18) <!-- [rfced] Section 5.1.1:  For ease of the reader, we defined "IV"
> > as "Initialization Vector" here, per the title of Figure 12.  Please
> > let us know any concerns.
> >
> > Original:
> >   The key K and counter IV are derived from the record label and the
> >   zone key zk using an HKDF as defined in [RFC5869].
> >
> > Currently:
> >   The key K and counter IV (Initialization Vector) are derived from the
> >   record label and the zone key zk, using an HKDF as defined in
> >   [RFC5869]. -->
> >
> >
> > 19) <!-- [rfced] Section 5.1.2:  This sentence is very difficult to
> > parse; it is not clear what represents the KeyGen() function.  Should
> > parentheses be added, per the definition of KeyGen() provided in
> > Section 5.1.1?
> >
> > Original:
> >   KeyGen()  The generation of the private key d and the associated
> >      public key zk := a*G where G is the group generator of the
> >      elliptic curve and a is an integer derived from d using the
> >      SHA-512 hash function as defined in Section 5.1.5 of [RFC8032]
> >      represents the KeyGen() function.
> >
> > Definition in Section 5.1.1 (for comparison purposes):
> >   KeyGen()  The generation of the private scalar d and the curve point
> >      zk := d*G (where G is the group generator of the elliptic curve)
> >      as defined in Section 2.2. of [RFC6979] represents the KeyGen()
> >      function. -->
> >
> >
> > 20) <!-- [rfced] Section 5.1.2:  For ease of the reader, may we clarify
> > this text as suggested?
> >
> > Original:
> >   The calculation
> >   of a is defined in Section 5.1.5 of [RFC8032].
> >
> > Suggested:
> >   As noted above for KeyGen(), a is calculated from d using the
> >   SHA-512 hash function as defined in Section 5.1.5 of [RFC8032]. -->
> >
> >
> > 21) <!-- [rfced] Section 5.1.2:
> > a) Because it appears that using d' (as opposed to d' itself) is not
> > compliant with [RFC8032], we updated this sentence accordingly.  If
> > this is not correct, please provide clarifying text.
> >
> > Original:
> >   Signatures for EDKEY zones use a derived private scalar d' which is
> >   not compliant with [RFC8032].
> >
> > Currently:
> >   Signatures for EDKEY zones use a derived private scalar d'; this is
> >   not compliant with [RFC8032].
> >
> > b) We found "key to" confusing in this context. Should "key to" be
> > "key for" here?
> >
> > Original:
> >   As the corresponding private key to
> >   the derived private scalar is not known, it is not possible to
> >   deterministically derive the signature part R according to [RFC8032].
> >
> > Perhaps:
> >   As the corresponding private key for
> >   the derived private scalar is not known, it is not possible to
> >   deterministically derive the signature part R according to [RFC8032].
> >
> > Or possibly:
> >   As the private key that corresponds to
> >   the derived private scalar is not known, it is not possible to
> >   deterministically derive the signature part R according to 
> [RFC8032]. -->
> >
> >
> > 22) <!-- [rfced] Section 5.1.2:  We could not find any mention of
> > "Poly1305", "Poly", or "1305" in [XSalsa20].  Will this sentence be
> > clear to readers?
> >
> > Original:
> >   The S-Encrypt() and S-Decrypt() functions use XSalsa20 as defined in
> >   [XSalsa20] (XSalsa20-Poly1305):
> >
> > Possibly:
> >   The S-Encrypt() and S-Decrypt() functions use XSalsa20 as defined in
> >   [XSalsa20] and use the XSalsa20-Poly1305 encryption function: -->
> >
> >
> > 23) <!-- [rfced] Sections 5.2.1 and subsequent: Per more common usage in
> > published RFCs, we changed "0-terminated" to "zero terminated", as this
> > term is not used as a modifier.  Please let us know any objections.
> >
> > Original:
> >   The string is UTF-8 encoded and 0-terminated.
> > ...
> >   The value is UTF-8 encoded
> >      and 0-terminated.
> > ...
> >   The value is UTF-8 encoded and 0-terminated.
> > ...
> >   A UTF-8 string (which is not 0-terminated)
> >      representing the legacy hostname.
> > ...
> >   A UTF-8 string (which is not 0-terminated) representing the
> >      preferred label of the zone.
> >
> > Currently:
> >   The string is UTF-8 encoded and zero terminated.
> > ...
> >   The value is UTF-8 encoded
> >      and zero terminated.
> > ...
> >   The value is UTF-8 encoded and zero terminated.
> > ...
> >   A UTF-8 string (which is not zero terminated)
> >      representing the legacy hostname.
> > ...
> >   A UTF-8 string (which is not zero terminated) representing
> >      the preferred label of the zone. -->
> >
> >
> > 24) <!-- [rfced] Section 6:  Do "176 byte blocks" and "1024 byte blocks"
> > refer to blocks that are (at least) 176 bytes or 1024 bytes in size,
> > or is "byte blocks" a proper term (as in some number of byte blocks)?
> >
> > Original:
> >   To be useful, the API MUST permit
> >   storing at least 176 byte blocks to be able to support the defined
> >   zone delegation record encodings, and SHOULD allow at least 1024 byte
> >   blocks.
> >
> > Possibly:
> >   To be useful, and to be able to support the defined zone delegation
> >   record encodings, the API MUST permit storing blocks of size 176 bytes
> >   or more and SHOULD allow blocks of size 1024 bytes or more. -->
> >
> >
> > 25) <!-- [rfced] Section 6.3:  Does "is considered" refer to the maximum
> > expiration time only (in which case "is" is correct) or the maximum
> > expiration time and also the expiration times of the non-shadow
> > records (in which case "is" should be "are")?
> >
> > Original:
> >   If the RDATA includes shadow
> >   records, then the maximum expiration time of all shadow records
> >   with matching type and the expiration times of the non-shadow
> >   records is considered. -->
> >
> >
> > 26) <!-- [rfced] Section 7.3.2:  We had trouble following the "and"
> > relationships in this sentence.  We updated as follows.  If this is
> > incorrect, please clarify the text.
> >
> > Original:
> >   When a resolver encounters one or more GNS2DNS records and the
> >   remaining name is empty and the desired record type is GNS2DNS, the
> >   GNS2DNS records are returned.
> >
> > Currently:
> >   When a resolver encounters one or more GNS2DNS records, the
> >   remaining name is empty, and the desired record type is GNS2DNS, the
> >   GNS2DNS records are returned. -->
> >
> >
> > 27) <!-- [rfced] Section 7.3.2:  We changed "error is SHOULD be 
> returned"
> > to "error SHOULD be returned" here.  Please let us know if the text
> > should be "error is returned" instead.
> >
> > Original:
> >   If
> >   different DNS names are present the resolution fails and an
> >   appropriate error is SHOULD be returned to the application.
> >
> > Currently:
> >   If
> >   different DNS names are present, the resolution fails and an
> >   appropriate error SHOULD be returned to the application. -->
> >
> >
> > 28) <!-- [rfced] Section 7.3.4:  This paragraph is difficult to parse.
> > For example, the last sentence is a fragment, and it isn't clear
> > under what circumstances the delegation record is returned.  If the
> > suggested text is not correct, please clarify.
> >
> > Original:
> >   If the remainder of the name to resolve is empty and a record set was
> >   received containing only a single delegation record, the recursion is
> >   continued with the record value as authoritative zone and the apex
> >   label "@" as remaining name.  Except in the case where the desired
> >   record type as specified by the application is equal to the ztype, in
> >   which case the delegation record is returned.
> >
> > Suggested:
> >   If the remainder of the name to resolve is empty and a record set was
> >   received containing only a single delegation record, the recursion is
> >   continued with the record value as the authoritative zone and the
> >   apex label "@" as the remaining name.  The exception is the case
> >   where the desired record type as specified by the application is
> >   equal to the ztype, in which case the delegation record is 
> returned. -->
> >
> >
> > 29) <!--[rfced] Section 9: [ISE] Please confirm that it is intentional
> > to title this section "Security and Privacy Considerations"
> > rather than "Security Considerations" as described in RFC 3552.
> >
> > Past RFCs have rarely used this title; specifically:
> > - RFC 9223 used it and had subsections to divide them.
> > - RFC 7989 used it (and did not have subsections).
> > -->
> >
> >
> > 30) <!-- [rfced] Section 9.1:  Does "considered just like" here mean
> > "treated just like", "also considered to be just like", or something
> > else?  Please clarify.
> >
> > Original:
> >   Private records are
> >   considered just like regular records when resolving labels in local
> >   zones, but their data is completely unavailable to non-local 
> users. -->
> >
> >
> > 31) <!-- [rfced] Section 9.3:  In the first sentence, [ed25519] appears
> > to be one paper.  Should RFC 7748 also be cited here as the other
> > paper?
> >
> > In the second sentence, does the hash function or the key destroy the
> > linearity that the key blinding in GNS depends upon?
> >
> > If the suggested text is not correct, please provide clarifying text.
> >
> > Original:
> >   However,
> >   standardized ECDSA curves are problematic for a range of reasons
> >   described in the Curve25519 and EdDSA papers [ed25519].  Using EdDSA
> >   directly is also not possible, as a hash function is used on the
> >   private key which destroys the linearity that the key blinding in GNS
> >   depends upon.
> >
> > Suggested (guessing the hash function and including RFC 7748):
> >   However,
> >   standardized ECDSA curves are problematic for a range of reasons, as
> >   described in the Curve25519 and EdDSA papers [RFC7748] [ed25519].
> >   Using EdDSA directly is also not possible, as a hash function is
> >   used on the private key and will destroy the linearity that the key
> >   blinding in GNS depends upon. -->
> >
> >
> > 32) <!-- [rfced] Section 9.5:  Because it appears that "or names" should
> > be "of names" here, we updated accordingly.  Please let us know if
> > this is incorrect.
> >
> > Original:
> >   In order to ensure integrity and availability or
> >   names, users must ensure that their local start zone information is
> >   not compromised or outdated.
> >
> > Currently:
> >   In order to ensure the integrity and availability of
> >   names, users must ensure that their local start zone information is
> >   not compromised or outdated. -->
> >
> >
> > 33) <!-- [rfced] Section 9.5:  Does "provided" only refer to the
> > processing, or does it also refer to the initial start zone (in
> > which case "is" should be "are")?
> >
> > Original:
> >   It can be expected that the processing
> >   of zone revocations and an initial start zone is provided with a GNS
> >   implementation ("drop shipping"). -->
> >
> >
> > 34) <!-- [rfced] Section 9.10:  As it appears that "taking into account"
> > applies to the applications and not some other method, we updated
> > this sentence accordingly.  If this is incorrect, please provide
> > clarifying text.
> >
> > Original:
> >   In order to prevent disclosure of queried GNS names it is RECOMMENDED
> >   that GNS-aware applications try to resolve a given name in GNS before
> >   any other method taking into account potential suffix-to-zone
> >   mappings and zTLDs.
> >
> > Currently:
> >   In order to prevent disclosure of queried GNS names, it is
> >   RECOMMENDED that GNS-aware applications try to resolve a given name
> >   in GNS before any other method, taking into account potential suffix-
> >   to-zone mappings and zTLDs. -->
> >
> >
> > 35) <!-- [rfced] Section 9.10:  As it appears that "It" in this sentence
> > refers to the NSS and not to a resolution process, we updated
> > accordingly, in line with text in the third paragraph of
> > Appendix A.4.  If this is incorrect, please provide clarifying text.
> >
> > Original (the previous sentence is included for context):
> >   Mechanisms such as the Name Service Switch (NSS) of Unix-like
> >   operating systems are an example of how such a resolution process can
> >   be implemented and used.  It allows system administrators to
> >   configure host name resolution precedence and is integrated with the
> >   system resolver implementation.
> >
> > Currently:
> >   The NSS allows system administrators to
> >   configure hostname resolution precedence and is integrated with the
> >   system resolver implementation. -->
> >
> >
> > 36) <!-- [rfced] Section 10:  The title of this table seems to indicate
> > that the requested assignments have not yet been made.  Should
> > "Requested" be "Assigned", as suggested below?
> >
> > Original:
> >   Figure 24: Requested Changes in the GANA GNUnet Signature Purpose
> >                                    Registry.
> >
> > Perhaps:
> >   Table 1: Assigned Changes in the GANA GNUnet Signature Purposes
> >                                    Registry
> >
> > Or possibly:
> >          Table 1: The GANA GNUnet Signature Purposes Registry -->
> >
> >
> > 37) <!-- [rfced] Sections 10.1 and 10.2:  Which paragraph or paragraphs
> > are referenced by these "by GANA:" sentences?  We ask because of the
> > use of the colon (":"); it appears that one or more of the paragraphs
> > after the colon should appear as a list (i.e., should be
> > "bullet items").
> >
> > Alternatively, should the colons be periods?
> >
> > Original:
> >   The registration policy for this registry is "First Come First
> >   Served".  This policy is modeled on that described in [RFC8126], and
> >   describes the actions taken by GANA:
> >
> >   Adding new entries is possible after review by any authorized GANA
> >   contributor, using a first-come-first-served policy for unique name
> >   allocation.  Reviewers are responsible to ensure that the chosen
> >   "Name" is appropriate for the record type.  The registry will define
> >   a unique number for the entry.
> >
> >   Authorized GANA contributors for review of new entries are reachable
> >   at [e-mail].
> >
> >   Any request MUST contain a unique name and a point of contact.  The
> >   contact information MAY be added to the registry given the consent of
> >   the requester.  The request MAY optionally also contain relevant
> >   references as well as a descriptive comment as defined above.
> >
> >   GANA has assigned numbers for the record types defined in this
> >   specification in the "GNU Name System Record Types" registry as
> >   listed in Figure 25.
> > ...
> >   The registration policy for this registry is "First Come First
> >   Served".  This policy is modeled on that described in [RFC8126], and
> >   describes the actions taken by GANA:
> >
> >   Adding new entries is possible after review by any authorized GANA
> >   contributor, using a first-come-first-served policy for unique
> >   subdomain allocation.  Reviewers are responsible to ensure that the
> >   chosen "Subdomain" is appropriate for the purpose.
> >
> >   Authorized GANA contributors for review of new entries are reachable
> >   at [e-mail].
> >
> >   Any request MUST contain a unique subdomain and a point of contact.
> >   The contact information MAY be added to the registry given the
> >   consent of the requester.  The request MAY optionally also contain
> >   relevant references as well as a descriptive comment as defined
> >   above.
> >
> >   GANA has assigned the subdomain defined in this specification in the
> >   ".alt subdomains" registry as listed in Figure 26.
> >
> > Perhaps (Section 10.1; assuming that the next three paragraphs, and
> >   not the "GANA has assigned" paragraph, should be in list form):
> >   This policy is modeled on that described in [RFC8126] and
> >   describes the actions taken by GANA:
> >
> >   *  Adding new entries is possible after review by any authorized
> >      GANA contributor, using a first-come-first-served policy for
> >      unique name allocation.  Reviewers are responsible for ensuring
> >      that the chosen "Name" is appropriate for the record type.  The
> >      registry will define a unique number for the entry.
> >
> >   *  Authorized GANA contributors for review of new entries are
> >      reachable at [e-mail].
> >
> >   *  Any request MUST contain a unique name and a point of contact.
> >      The contact information MAY be added to the registry, with the
> >      consent of the requester.  The request MAY optionally also
> >      contain relevant references as well as a descriptive comment, as
> >      defined above.
> >
> >   GANA has assigned numbers for the record types defined in this
> >   specification in the "GNS Record Types" registry as listed in
> >   Table 2. -->
> >
> >
> > 38) <!-- [rfced] Section 10.1:  We see a discrepancy between this
> > document and [GANA] for the "BOX" entry (number 65541).  It appears
> > that all other entries match.  Should the listings be made
> > consistent between this document and [GANA]?  If so, how?
> >
> > "Comment" entry for this document:  Boxed records
> > "Comment" entry in the GANA "GNS Record Types" registry:  Box record
> > -->
> >
> >
> > 39) <!-- [rfced] Section 10.2:  Should "Comment" be "Description" in
> > these entries and should "Subdomain" be "Label" here, per [GANA]
> > (specifically https://gana.gnunet.org/dot-alt/dot_alt.html)?
> >
> > We also see "a first-come-first-served policy for unique subdomain
> > allocation" in the text in this section, so it's not clear whether
> > "Subdomain" or "Label" might be preferred for this document and
> > [GANA] (if they should indeed match).
> >
> > Original:
> >   *  Label: The label of the subdomain (in DNS LDH format as defined in
> >      Section 2.3.1 of [RFC5890]).
> >
> >   *  Comment: Optionally, a brief English text describing the purpose
> >      of the subdomain (in UTF-8)
> > ...
> >   Subdomain | Contact | References | Comment
> > -->
> >
> >
> > 40) <!--[rfced] Section 12: Is it intentional to keep the
> > "Implementation and Deployment Status" section, or would
> > you like it to be removed before publication?
> >
> > Regarding "Implementation Status" sections in general, RFC 7942 states:
> > "We recommend that the Implementation Status section should be
> > removed from Internet-Drafts before they are published as RFCs."
> >
> > That said, if you prefer to keep it, that's fine.
> > -->
> >
> >
> > 41) <!-- [rfced] Normative References:  Please confirm that the URL
> > provided for [XSalsa20] is stable.
> >
> > Original:
> >   [XSalsa20] Bernstein, D., "Extending the Salsa20 nonce", 2011,
> >              <https://cr.yp.to/snuffle/xsalsa-20110204.pdf>. -->
> >
> >
> > 42) <!-- [rfced] [SDSI]:  The provided URL yields a "Not Found" error.
> > We see that
> > <https://people.csail.mit.edu/rivest/pubs/RL96.ver-1.1.html>, dated
> > October 1996, works, but is it stable?  We have been advised that
> > ".edu" URLs are not always stable.
> >
> > Please advise regarding how to update this listing, noting that we
> > try to use "https://" instead of "http://" as much as possible.
> >
> > Original:
> >   [SDSI]     Rivest, R. and B. Lampson, "SDSI - A Simple Distributed
> >              Security Infrastructure", April 1996,
> >              <http://people.csail.mit.edu/rivest/Sdsi10.ps>. -->
> >
> >
> > 43) <!-- [rfced] Informative References:  Please confirm that the URL
> > provided for [Kademlia] is stable.
> >
> > Original:
> >   [Kademlia] Maymounkov, P. and D. Mazieres, "Kademlia: A peer-to-peer
> >              information system based on the xor metric.", 2002,
> >              
> <http://css.csail.mit.edu/6.824/2014/papers/kademlia.pdf>. -->
> >
> >
> > 44) <!-- [rfced] [GNUnetGNS]:  The title as provided in this document
> > doesn't appear on the provided page.  May we change the title to
> > "gnunet.git - GNUnet core repository"?
> >
> > Original:
> >   [GNUnetGNS]
> >              GNUnet e.V., "The GNUnet GNS Implementation",
> >              <https://git.gnunet.org/gnunet.git/tree/src/gns>. -->
> >
> >
> > 45) <!-- [rfced] [Ascension]:  The title as provided in this document
> > doesn't appear on the provided page.  May we change the title to
> > "ascension.git - DNS zones to GNS migrating using incremental zone
> > transfer (AXFR/IXFR)"?
> >
> > Original:
> >   [Ascension]
> >              GNUnet e.V., "The Ascension Implementation",
> >              <https://git.gnunet.org/ascension.git>. -->
> >
> >
> > 46) <!-- [rfced] [GNUnet]:  The title as provided in this document
> > doesn't appear on the provided page.  Should the title be updated?
> >
> > Original:
> >   [GNUnet]   GNUnet e.V., "The GNUnet Project", <https://gnunet.org>.
> >
> > Perhaps:
> >   [GNUnet]   GNUnet e.V., "The GNUnet Project (Home Page)",
> >              2023, <https://gnunet.org>. -->
> >
> >
> > 47) <!-- [rfced] Appendix A.2:  Does the colon after "configuration" 
> mean
> > that only the first paragraph that follows it applies, or do both
> > subsequent paragraphs apply?  In other words, it appears that one or
> > both of the subsequent paragraphs should be in list form (i.e., a
> > bullet list).  Please advise.
> >
> > Alternatively, should the colon be a period?
> >
> > Original:
> >   At
> >   this point the user may delete or otherwise modify the
> >   implementation's default configuration:
> >
> >   Deletion of suffix-to-zone mappings may become necessary of the zone
> >   owner referenced by the mapping has lost the trust of the user.  For
> >   example, this could be due to lax registration policies resulting in
> >   phishing activities.  Modification and addition of new mappings are
> >   means to heal the namespace perforation which would occur in the case
> >   of a deletion or to simply establish a strong direct trust
> >   relationship.  However, this requires the user's knowledge of the
> >   respective zone keys.  This information must be retrieved out of
> >   band, as illustrated in Appendix A.1: A bank may send the user a
> >   letter with a QR code which contains the GNS zone of the bank.  The
> >   user scans the QR code and adds a new suffix-to-name mapping using a
> >   chosen local name for his bank.  Other examples include scanning zone
> >   information off the device of a friend, from a storefront, or an
> >   advertisement.  The level of trust in the respective zone is
> >   contextual and likely varies from user to user. Trust in a zone
> >   provided through a letter from a bank which may also include a credit
> >   card is certainly different from a zone found on a random
> >   advertisement in the streets.  However, this trust is immediately
> >   tangible to the user and can be reflected in the local naming as
> >   well.
> >
> >   User clients should facilitate the modification of the start zone
> >   configuration, for example by providing a QR code reader or other
> >   import mechanisms.  Implementations are ideally implemented according
> >   to best practices and addressing applicable points from Section 9.
> >   Formalizing such best practices is out of scope of this
> >   specification. -->
> >
> >
> > 48) <!-- [rfced] Appendix A.2:  We changed "necessary of" to "necessary
> > if" here.  If this is incorrect, please provide clarifying text.
> >
> > Original:
> >   Deletion of suffix-to-zone mappings may become necessary of the zone
> >   owner referenced by the mapping has lost the trust of the user.
> >
> > Currently:
> >   Deletion of suffix-to-zone mappings may become necessary if the zone
> >   owner referenced by the mapping has lost the trust of the user. -->
> >
> >
> > 49) <!-- [rfced] Appendix A.3: We could not determine what a second
> > query might be or whether it might be important to point it out.
> > Will this text be clear to readers?  If not, please provide
> > clarifying text.
> >
> > Original:
> >   In order to determine the canonical representation of the record with
> >   a zTLD, at most two queries are required: First, it must be checked
> >   whether "www.example.gns.alt <http://www.example.gns.alt>" itself 
> points to a zone delegation
> >   record which would imply that the record set which was originally
> >   resolved is published under the apex label. -->
> >
> >
> > 50) <!-- [rfced] Appendix D.2:  Should the following entries be written
> > consistently (i.e., with or without "delegation", with or without the
> > number of (delegation) records)?
> >
> > Original:
> >   *(1) PKEY zone with ASCII label and one delegation record*
> >   *(2) PKEY zone with UTF-8 label and three records*
> >   *(3) EDKEY zone with ASCII label and delegation record*
> >   *(4) EDKEY zone with UTF-8 label and three records*
> >
> > Possibly (assuming that "delegation" also applies to UTF-8 labels):
> >   *(1) PKEY zone with ASCII label and one delegation record*
> >   *(2) PKEY zone with UTF-8 label and three delegation records*
> >   *(3) EDKEY zone with ASCII label and one delegation record*
> >   *(4) EDKEY zone with UTF-8 label and three delegation records* -->
> >
> >
> > 51) <!-- [rfced] Please review the "Inclusive Language" portion of the
> > online Style Guide at
> > <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>,
> > and let us know if any changes are needed.
> >
> > For example, please consider whether the following should be updated:
> >   master (zone master) (perhaps "zone administrator")
> >   his (generally changed to "their")
> >   man-in-the-middle (sometimes changed to "on-path attacker") -->
> >
> >
> > 52) <!-- [rfced] Please let us know if any changes are needed for the
> > following:
> >
> > a) The following terms were used inconsistently in this document.
> > We chose to use the latter forms.  Please let us know any objections.
> >
> >   encode and decode symbols (Appendix C) / encoding and decoding symbols
> >
> >   internet services / Internet services
> >
> >   legacy host name / legacy hostname*
> >
> >     * We also changed "host name" to "hostname" where used generally,
> >       per "hostname resolution" in Appendix A.4. Please let us know
> >       any objections.
> >
> >   zeros / zeroes
> >
> > b) The following terms/phrases appear to be used inconsistently in
> > this document.  Please let us know which form is preferred.
> >
> >   for the nonce / for the NONCE
> >
> >   "Host"-header (noun) / "Host:" header (noun)
> >     (We also see '"Host"-header field' in Appendix A.3.)
> >
> >   Keygen() / KeyGen()
> >
> >   records block / record block (e.g., "resource records block
> >     (RRBLOCK)", "resource record block (RRBLOCK)")
> >
> >   REDIRECT DATA ("REDIRECT DATA entry") /
> >     REDIRECT data ("the REDIRECT data")
> >
> >   redirect name / REDIRECT NAME
> >
> >   Redirect record (first sentence of Section 5.2) /
> >     REDIRECT record (We also see "redirection record" in running text
> >      and "with redirect" in Appendix B.2.)
> >
> >   Start Zone / start zone (e.g., "a Start Zone", "the start zone")
> >
> > c) We see that "zone key" is defined as "zk" but that "zkey" is also
> > used.  Please confirm that this is as intended and will be clear to
> > readers (e.g., are "zk" and "zkey" the same thing or two different
> > things?).  We have a similar question regarding the use of
> > "zone type" and "ztype"; do they both mean the same thing?
> >
> > d) Should "record data" be defined as "RDATA" at first use and
> > "RDATA" used thereafter?  We ask because of "6.2. Plaintext Record
> > Data (RDATA)" and "Record data (RDATA) is the format ..." used a few
> > lines into Section 6.2.
> >
> > e) Please confirm that the usage of "boxed record" versus "BOX record"
> > is correct.
> >
> > f) Should the spacing of parameters in parentheses be made
> > consistent for the following?  If so, how?
> >
> > For example:
> >
> >   ZKDF(zk, label)
> >   ZKDF(zk,label)
> >   S-Encrypt(zk,label,expiration,plaintext)
> >   Sign(d,message)
> >   Verify(zk,message,signature)
> >   PUT(key,block)
> >   PUT(q, RRBLOCK)
> >   ZKDF(zk0, "example")
> >
> > g) Should the following be consistently quoted in text or unquoted?
> >
> > For example:
> >   the GNS name "www.example.gns <http://www.example.gns>"
> >   the DNS name www.example.com <http://www.example.com>
> >   LEHO record (Section 5.3.1) containing "www.example.com 
> <http://www.example.com>"
> >   a single REDIRECT record containing www2.+ -->
> >
> >
> > Thank you.
> >
> > RFC Editor/lb/ar
> >
> >
> > On Oct 23, 2023, [e-mail] wrote:
> >
> > *****IMPORTANT*****
> >
> > Updated 2023/10/23
> >
> > RFC Author(s):
> > --------------
> >
> > Instructions for Completing AUTH48
> >
> > Your document has now entered AUTH48.  Once it has been reviewed and
> > approved by you and all coauthors, it will be published as an RFC.
> > If an author is no longer available, there are several remedies
> > available as listed in the FAQ (https://www.rfc-editor.org/faq/).
> >
> > You and you coauthors are responsible for engaging other parties
> > (e.g., Contributors or Working Group) as necessary before providing
> > your approval.
> >
> > Planning your review
> > ---------------------
> >
> > Please review the following aspects of your document:
> >
> > *  RFC Editor questions
> >
> >    Please review and resolve any questions raised by the RFC Editor
> >    that have been included in the XML file as comments marked as
> >    follows:
> >
> >    <!-- [rfced] ... -->
> >
> >    These questions will also be sent in a subsequent email.
> >
> > *  Changes submitted by coauthors
> >
> >    Please ensure that you review any changes submitted by your
> >    coauthors.  We assume that if you do not speak up that you
> >    agree to changes submitted by your coauthors.
> >
> > *  Content
> >
> >    Please review the full content of the document, as this cannot
> >    change once the RFC is published.  Please pay particular 
> attention to:
> >    - IANA considerations updates (if applicable)
> >    - contact information
> >    - references
> >
> > *  Copyright notices and legends
> >
> >    Please review the copyright notice and legends as defined in
> >    RFC 5378 and the Trust Legal Provisions
> >    (TLP – https://trustee.ietf.org/license-info/).
> >
> > *  Semantic markup
> >
> >    Please review the markup in the XML file to ensure that elements of
> >    content are correctly tagged.  For example, ensure that <sourcecode>
> >    and <artwork> are set correctly.  See details at
> >    <https://authors.ietf.org/rfcxml-vocabulary>.
> >
> > *  Formatted output
> >
> >    Please review the PDF, HTML, and TXT files to ensure that the
> >    formatted output, as generated from the markup in the XML file, is
> >    reasonable.  Please note that the TXT will have formatting
> >    limitations compared to the PDF and HTML.
> >
> >
> > Submitting changes
> > ------------------
> >
> > To submit changes, please reply to this email using ‘REPLY ALL’ as all
> > the parties CCed on this message need to see your changes. The parties
> > include:
> >
> >    *  your coauthors
> >
> >    * [e-mail] (the RPC team)
> >
> >    *  other document participants, depending on the stream (e.g.,
> >       IETF Stream participants are your working group chairs, the
> >       responsible ADs, and the document shepherd).
> >
> >    * [e-mail], which is a new archival mailing list
> >       to preserve AUTH48 conversations; it is not an active discussion
> >       list:
> >
> >      *  More info:
> > 
> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
> >
> >      *  The archive itself:
> > https://mailarchive.ietf.org/arch/browse/auth48archive/
> >
> >      *  Note: If only absolutely necessary, you may temporarily opt out
> >         of the archiving of messages (e.g., to discuss a sensitive 
> matter).
> >         If needed, please add a note at the top of the message that you
> >         have dropped the address. When the discussion is concluded,
> > [e-mail] will be re-added to the CC list and
> >         its addition will be noted at the top of the message.
> >
> > You may submit your changes in one of two ways:
> >
> > An update to the provided XML file
> > — OR —
> > An explicit list of changes in this format
> >
> > Section # (or indicate Global)
> >
> > OLD:
> > old text
> >
> > NEW:
> > new text
> >
> > You do not need to reply with both an updated XML file and an explicit
> > list of changes, as either form is sufficient.
> >
> > We will ask a stream manager to review and approve any changes that seem
> > beyond editorial in nature, e.g., addition of new text, deletion of 
> text,
> > and technical changes.  Information about stream managers can be 
> found in
> > the FAQ.  Editorial changes do not require approval from a stream 
> manager.
> >
> >
> > Approving for publication
> > --------------------------
> >
> > To approve your RFC for publication, please reply to this email stating
> > that you approve this RFC for publication.  Please use ‘REPLY ALL’,
> > as all the parties CCed on this message need to see your approval.
> >
> >
> > Files
> > -----
> >
> > The files are available here:
> > https://www.rfc-editor.org/authors/rfc9498.xml
> > https://www.rfc-editor.org/authors/rfc9498.html
> > https://www.rfc-editor.org/authors/rfc9498.pdf
> > https://www.rfc-editor.org/authors/rfc9498.txt
> >
> > Diff file of the text:
> > https://www.rfc-editor.org/authors/rfc9498-diff.html
> > https://www.rfc-editor.org/authors/rfc9498-rfcdiff.html (side by side)
> >
> > This alternate diff file shows the changes in the moved text:
> > https://www.rfc-editor.org/authors/rfc9498-alt-diff.html
> >
> > Diff of the XML:
> > https://www.rfc-editor.org/authors/rfc9498-xmldiff1.html
> >
> >
> > Tracking progress
> > -----------------
> >
> > The details of the AUTH48 status of your document are here:
> > https://www.rfc-editor.org/auth48/rfc9498
> >
> > Please let us know if you have any questions.
> >
> > Thank you for your cooperation,
> >
> > RFC Editor
> >
> > --------------------------------------
> > RFC9498 (draft-schanzen-gns-28)
> >
> > Title            : The GNU Name System
> > Author(s)        : M. Schanzenbach, C. Grothoff, B. Fix
> >
>