<?xml version="1.0" encoding="utf-8"?>
<?xml-model href="rfc7991bis.rnc"?>
<!-- <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> -->

<rfc
  xmlns:xi="http://www.w3.org/2001/XInclude"
  category="info"
  docName="draft-bortzmeyer-more-edes-00"
  ipr="trust200902"
  obsoletes=""
  updates=""
  submissionType="IETF"
  xml:lang="en"
  version="3">

  <front>
    <title abbrev="More EDEs">Addition of Extended DNS Errors codes</title>

    <seriesInfo name="Internet-Draft" value="draft-bortzmeyer-more-edes-00"/>
   
    <author fullname="Stéphane Bortzmeyer" initials="S." surname="Bortzmeyer">
      
      <organization>Afnic</organization>
      <address>
        <postal>
          <street>7 avenue du 8 mai 1945</street>
          <city>Guyancourt</city>
          <code>78280</code>
          <country>FR</country>
          <!-- Uses two letter country code -->
        </postal>        
        <email>bortzmeyer+ietf@nic.fr</email>  
        <uri>https://www.afnic.fr/</uri>
      </address>
    </author>
   
    <date year="2024"/>

    <area>General</area>
    <workgroup>Internet Engineering Task Force</workgroup>

    <keyword>DNS EDE</keyword>

    <abstract>
      <t>This document is the specification of three new EDE (Extended
      DNS Errors) codes, for minimal answers, local roots and ECS
      (EDNS Client Subnet).</t>
    </abstract>
 
  </front>

  <middle>
    
    <section>
      <name>Introduction</name>
      <t><xref target="RFC8914"/> created the EDE (Extended DNS
      Errors). Each error is identified by a code, and there is an
      IANA registry of these codes. This specification adds three
      codes:</t>
      <ul>
        <li>One to say that the response has been tailored because of
	ECS,</li>
	<li>One to say that the response was deliberately minimal,</li>
        <li>One to say that the response comes from a local root.</li>
      </ul>
      
      <section>
        <name>Requirements Language</name>
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
          "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
          RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
          interpreted as described in BCP 14 <xref target="RFC2119"/>
          <xref target="RFC8174"/> when, and only when, they appear in
          all capitals, as shown here.</t>
      </section>

    </section>
    
    <section>
      <name>ECS</name>
      <t>This response code, TBD, means that the response has been
      tailored because of ECS (EDNS CLient Subnet, <xref
      target="RFC7871"/>). It MAY be sent by authoritative servers or
      resolvers when they implement ECS.</t>
      <t>TODO if a resolver receives this EDE from an authoritative,
      should it copy it in the response sent to its client?</t>
      <t>TODO Could it also include tailoring for other reasons (like DNS load balancing)?</t>
    </section>

    <section>
      <name>Minimal response</name>
      <t>This response code, TBD, means that the response to an ANY
      request was
      deliberately minimal, as documented by <xref
      target="RFC8482"/>. It MAY be sent by authoritative servers or
      resolvers.</t>
      <t>TODO should we extend it also for cases like "glue not sent
      since I wanted to save bits"?</t>
    </section>

    <section>
      <name>Local root</name>
      <t>This response code, TBD, means that the response comes from
      a local root, as documented in <xref target="RFC8806"/>. It MAY
      be sent by resolvers using a local root.</t>
    </section>

    <section anchor="IANA">
      <name>IANA Considerations</name>
      <t>IANA is requested to allocate codes to these three EDE and to
      add them to the "Extended DNS Error Codes", with a reference to
      this document.</t>
      <t>Note that the policy for the registry "Extended DNS Error
      Codes" is just "First come, first served" so this document is
      not strictly necessary.</t>
    </section>
    
    <section anchor="Security">
      <name>Security Considerations</name>
      <t>The EDE are sent with EDNS and are not signed. They should be
      used with care (see <xref target="RFC8914"/>, section 6).</t>
    </section>
    
  </middle>

  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        
        <xi:include
            href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include
            href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7871.xml"/>
        <xi:include
            href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include
	    href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8482.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8806.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8914.xml"/>
        
      </references>
 
      <references>
        <name>Informative References</name>
      </references>
    </references>

        <section anchor="Acknowledgements" numbered="false">
      <name>Acknowledgements</name>
      <t>Original idea by Marco Davids.</t>
    </section>
    
 </back>
</rfc>
