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

[[e-mail]]

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" 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"
 the DNS name www.example.com
 LEHO record (Section 5.3.1) containing "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