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

["Schanzenbach, Martin" <[e-mail]>]

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?


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
>