Re: [auth48] AUTH48: RFC-to-be 9499 <draft-ietf-dnsop-rfc8499bis-10> for your review

[[e-mail]]

Authors,

While reviewing this document during AUTH48, please resolve (as necessary) 
the following questions, which are also in the XML file.

1) <!-- [rfced] For the three name formats in the "Format of names" 
definition, would it be helpful to format the definitions below as follows?

Original:
The basic wire format for names in the global DNS is a list of...

The presentation format for names in the global DNS is a list of...

The common display format is used in applications and free text...

Perhaps: 
Wire format: The basic wire format for names in the global DNS is a
list of...
                       
Presentation format: The presentation format for names in the global DNS is 
a list of...
                       
Common display format: The common display format is used in applications 
and free text...
-->


2) <!-- [rfced] For the definition of "Locally served DNS zone", is this 
sentence missing an article before "private DNS"?

Original: 
A locally served DNS zone is a special case of private DNS.

Perhaps: 
A locally served DNS zone is a special case of a private DNS.
-->


3) <!-- [rfced] May we update the following unordered list to a definition 
list for consistency with the other definitions listed in the document?

Original:
To address this potential confusion, it is helpful to distinguish
between three meanings:

*  QNAME (original): The name actually sent in the Question
   section in the original query, which is always echoed in the
   (final) reply in the Question section when the QR bit is set to
   1.

*  QNAME (effective): A name actually resolved, which is either
   the name originally queried or a name received in a CNAME chain
   response.

*  QNAME (final): The name actually resolved, which is either the
   name actually queried or else the last name in a CNAME chain
   response.

Perhaps:
To address this potential confusion, it is helpful to distinguish
between three meanings:

QNAME (original): The name actually sent in the Question section in the
original query, which is always echoed in the (final) reply in the Question
section when the QR bit is set to 1.

QNAME (effective): A name actually resolved, which is either the name
originally queried or a name received in a CNAME chain response.

QNAME (final): The name actually resolved, which is either the name actually
queried or else the last name in a CNAME chain response.  
-->


4) <!-- [rfced] Please note that we have added quotation marks to 
definitions/quotes from other RFCs that appear in definition lists 
throughout the document, as <blockquote> cannot be used within definition 
lists.  -->


5) <!-- [rfced] For the defintion of TTL, may we remove the parenthesis 
from the following text so that two sentences in parentheses aren't next to
each other? Note that this is the only instance in the document.

Original: 
(Quoted from [RFC2181], Section 8) (Note that [RFC1035] erroneously
stated that this is a signed integer; that was fixed by [RFC2181].)

Perhaps: 
(Quoted from [RFC2181], Section 8) Note that [RFC1035] erroneously
stated that this is a signed integer; that was fixed by [RFC2181].
-->


6) <!-- [rfced] For the following sentence, "such as if" reads a bit
awkwardly. May we propose the following rephrase?

Original: 
The reason that the TTL is the maximum time to live is that a cache
operator might decide to shorten the time to live for operational purposes,
such as if there is a policy to disallow TTL values over a certain number.

Perhaps: 
The reason that the TTL is the maximum time to live is that a cache
operator might decide to shorten the time to live for operational purposes,
for example, if there is a policy to disallow TTL values over a certain
number.
-->


7) <!-- [rfced] We are unsure if the second instance of "class" should be 
plural in this sentence. Does the following suggestion retain your
intended meaning?

Original: 
A resource record type that is not class independent has different
meanings depending on the DNS class of the record, or the meaning is undefined
for some class.

Perhaps: 
A resource record type that is not class independent has different
meanings, depending on the DNS class of the record or if the meaning is
undefined for some classes.
-->


8) <!--[rfced] May we rephrase the following for readability?

Original: 
An earlier RFC, [RFC4641], said that the hidden master's name
"appears in the SOA RRs MNAME field", although, in some setups, the 
name does not appear at all in the global DNS.

Perhaps: 
[RFC4641] said that the hidden master's name
"appears in the SOA RRs MNAME field"; however, the name does
not appear at all in the global DNS in some setups. 
-->


9) <!-- [rfced] For readability, may we place "nevertheless" at the 
beginning of this sentence?

Original: 
The effect of this is that a domain name that is notionally globally
unique nevertheless has different meanings for different network users.

Perhaps: 
Nevertheless, the effect of this is that a domain name that is
notionally globally unique has different meanings for different network users.
-->


10) <!-- [rfced] To match the original text in RFC 9250, may we update the
definition of "DNS-over-QUIC" as follows?

Original: 
[RFC9250] specifically defines DoQ as a general purpose transport
for DNS that can be used in stub to recursive, recursive to authoritative or
zone transfer scenarios.

Perhaps: 
[RFC9250] specifically defines DoQ as general-purpose transport for
DNS that can be used in stub to recursive, recursive to authoritative, and
zone transfer scenarios.
-->


11) <!-- [rfced] May we format this unordered list as follows for readability?

Original:
*  a nameserver with an NS record for a zone that does not answer
   DNS queries

*  a nameserver with an IP address that is not reachable by the
   resolver
 
*  a nameserver that responds to a query for a specific name with
   an error or without the authoritative bit set

Perhaps:
*  a nameserver with an NS record for a zone that does not answer
   DNS queries;

*  a nameserver with an IP address that is not reachable by the
   resolver; and

*  a nameserver that responds to a query for a specific name with
   an error or without the authoritative bit set. -->


12) <!-- [rfced] We added an <xref> for RFC 20 in the quoted text, so we also added an informative reference to RFC 20.  Please let us know if any updates are needed.

Original:
   Asterisk label:  "The first octet is the normal label type and length
      for a 1-octet-long label, and the second octet is the ASCII 
      representation [RFC20] for the '*' character.  A descriptive name
      of a label equaling that value is an 'asterisk label'."  (Quoted
      from [RFC4592], Section 2.1.1)
-->


13) <!-- [rfced] The following RDAP RFCs have been obsoleted.  

RFC 7482 -> 9082
RFC 7483 -> 9083
RFC 7484 -> 9224 

May we refer to the current RFCs?  

Original: 
   RDAP:  The Registration Data Access Protocol, defined in [RFC7480],
      [RFC7481], [RFC7482], [RFC7483], [RFC7484], and [RFC7485].  The
      RDAP protocol and data format are meant as a replacement for
      WHOIS.
-->


14) <!-- [rfced] For the definition of "Validation", is it correct that Section 4.3 of RFC 4035 and Section 5 of RFC 4033 provide more info about "secure"? 

Original: 
A response is considered to be authentic if "all RRsets in the
Answer and Authority sections of the response [are considered] to be
authentic" (Quoted from [RFC4035]) DNS data or responses deemed to be
authentic or validated have a security status of "secure" ([RFC4035], 
Section 4.3; [RFC4033], Section 5).
-->


15) <!-- [rfced] For clarity, would you like to specify that the reference to RFC 8499 in the Extra Parameters field of the dns_error entry within the "HTTP Proxy Error Types" registry has been updated to refer to this document? 

Original:
   Any reference to RFC 8499 in the IANA registries should be replaced
   with a reference to this document.
-->


16) <!-- [rfced] Hyphenation

a) Note that we removed the hyphen from "fully-qualified domain name" for
grammatical correctness and for consistency with recent RFCs. 

b) We note that terms such as "DNS-over-TLS" are used inconsistently. Past
RFCs, including the RFCs that introduce these terms, typically refer to them with
no hyphen when they are not modifying a noun. For instances that occur outside
of quoted/DNE text, may we update the terms below as follows to use the form
on the right?

DNS-over-TLS vs. DNS over TLS
DNS-over-HTTPS vs. DNS over HTTPS
DNS-over-QUIC vs. DNS over QUIC
XFR-over-TLS vs. XFR over TLS
-->


17) <!-- [rfced] Although we see your note about inconsistent capitalization in the Introduction, we wonder if you'd like to make the terms below consistent within this document.  The following terms use inconsistent capitalization outside of quoted/DNE text. If there is a desire to make these consistent, please let us know which form you prefer.

additional section vs. Additional section
answer section vs. Answer section 
authority section vs. Authority section
Opt-Out vs. opt-out
-->


18) <!-- [rfced] Please review the "Inclusive Language" portion of the 
online Style Guide
<https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let
us know if any changes are needed.  Note that our script flagged
"slave", and "master", though it seems these terms have been updated where possible.  -->


Thank you.

RFC Editor


On Mar 4, 2024, at 3:25 PM, [e-mail] wrote:

*****IMPORTANT*****

Updated 2024/03/04

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/rfc9499.xml
   https://www.rfc-editor.org/authors/rfc9499.html
   https://www.rfc-editor.org/authors/rfc9499.pdf
   https://www.rfc-editor.org/authors/rfc9499.txt

Diff file of the text:
   https://www.rfc-editor.org/authors/rfc9499-diff.html
   https://www.rfc-editor.org/authors/rfc9499-rfcdiff.html (side by side)

Diff of the XML: 
   https://www.rfc-editor.org/authors/rfc9499-xmldiff1.html

The following files are provided to facilitate creation of your own 
diff files of the XML.  

Initial XMLv3 created using XMLv2 as input:
   https://www.rfc-editor.org/authors/rfc9499.original.v2v3.xml 

XMLv3 file that is a best effort to capture v3-related format updates 
only: 
   https://www.rfc-editor.org/authors/rfc9499.form.xml


Tracking progress
-----------------

The details of the AUTH48 status of your document are here:
   https://www.rfc-editor.org/auth48/rfc9499

Please let us know if you have any questions.  

Thank you for your cooperation,

RFC Editor

--------------------------------------
RFC9499 (draft-ietf-dnsop-rfc8499bis-10)

Title            : DNS Terminology
Author(s)        : P. Hoffman, K. Fujiwara
WG Chair(s)      : Suzanne Woolf, Benno Overeinder, Tim Wicinski

Area Director(s) : Warren Kumari, Robert Wilton