<?xml version='1.0'encoding='utf-8'?>encoding='UTF-8'?> <!-- pre-edited by ST 06/25/24 --> <!-- draft submitted in xml v3 --> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.13 (Ruby 3.0.2) --><rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-dnsop-qdcount-is-one-04" number="9619" category="std" consensus="true" submissionType="IETF" updates="1035" obsoletes="" tocInclude="true" sortRefs="true" symRefs="true"version="3"> <!-- xml2rfc v2v3 conversion 3.21.0 -->version="3" xml:lang="en"> <front><title>In<title abbrev="In the DNS, QDCOUNTis (usually)Is (Usually) One">In the DNS, QDCOUNT Is (Usually) One</title> <seriesInfoname="Internet-Draft" value="draft-ietf-dnsop-qdcount-is-one-04"/>name="RFC" value="9619"/> <author initials="R." surname="Bellis" fullname="Ray Bellis"> <organization abbrev="ISC">Internet Systems Consortium, Inc.</organization> <address> <postal> <street>PO Box 360</street> <city>Newmarket</city><code>NH 03857</code> <country>US</country><region>NH</region> <code>03857</code> <country>United States of America</country> </postal> <phone>+1 650 423 1300</phone> <email>ray@isc.org</email> </address> </author> <author initials="J." surname="Abley" fullname="Joe Abley"> <organization>Cloudflare</organization> <address> <postal> <city>Amsterdam</city><country>NL</country><country>Netherlands</country> </postal> <phone>+31 6 45 56 36 34</phone> <email>jabley@cloudflare.com</email> </address> </author> <date year="2024"month="May" day="29"/> <area>Internet</area> <workgroup>DNSOP Working Group</workgroup> <keyword>Internet-Draft</keyword>month="July"/> <area>OPS</area> <workgroup>dnsop</workgroup> <abstract><?line 40?><t>This document updates RFC 1035 by constraining the allowed value of the QDCOUNT parameter in DNS messages with OPCODE = 0 (QUERY) to a maximum of one, and it specifies the requiredbehaviourbehavior when values that are not allowed are encountered.</t> </abstract> </front> <middle><?line 47?><section anchor="introduction"> <name>Introduction</name> <t>The DNS protocol <xreftarget="RFC1034"/><xreftarget="RFC1034"/> <xref target="RFC1035"/> includes a parameter QDCOUNT in the DNS messageheader,header whose value is specified to mean the number of questions in the QuestionSectionsection of a DNS message.</t> <t>In a generalsensesense, it seems perfectly plausible for the QDCOUNT parameter, an unsigned 16-bit value, to take a considerable range of values. However, in the specific case of messages that encode DNS queries and responses (messages with OPCODE =0)0), there are other limitations inherent in the protocol that constrain values of QDCOUNT to be either 0 or 1. In particular, several parameters specified for DNS response messages such as AA and RCODE have no defined meaning when the message contains multiplequeries, sincequeries as there is no way to signal which question those parameters relate to.</t> <t>In thisdocumentdocument, we briefly survey the existing written DNS specification;weprovide a description of the semantic and practical requirements for DNS queries that naturally constrain the allowable values of QDCOUNT; andweupdate the DNS base specification to clarify the allowable values of the QDCODE parameter in the specific case of DNS messages with OPCODE = 0.</t> </section> <section anchor="terminology-used-in-this-document"> <name>TerminologyusedUsed inthis document</name> <t>TheThis Document</name> <t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> </section> <section anchor="qdcount-is-usually-one"> <name>QDCOUNTis (usually)Is (Usually) One</name> <t>A brief summary of the guidance provided in the existing DNS specification (<xref target="RFC1035" format="default"/> and many other documents) for the use of QDCOUNT can be found in <xref target="Survey"/>. While the specification is clear in many cases, there is some ambiguity in the specific case of OPCODE =0 there is some ambiguity0, which this document aims to eliminate.</t> </section> <section anchor="updates-to-rfc-1035"> <name>Updates to RFC 1035</name> <t>A DNS message with OPCODE = 0MUST NOT<bcp14>MUST NOT</bcp14> include a QDCOUNT parameter whose value is greater than 1. It follows that the QuestionSectionsection of a DNS message with OPCODE = 0MUST NOT<bcp14>MUST NOT</bcp14> contain more than one question.</t> <t>A DNS message with OPCODE = 0 and QDCOUNT > 1MUST<bcp14>MUST</bcp14> be treated as anincorrectly-formattedincorrectly formatted message. The value of the RCODE parameter in the response messageMUST<bcp14>MUST</bcp14> be set to 1 (FORMERR).</t> <t>Middleboxes(e.g.(e.g., firewalls) that process DNS messages in order to eliminate unwanted trafficSHOULD<bcp14>SHOULD</bcp14> treat messages with OPCODE = 0 and QDCOUNT > 1 as malformed traffic and return a FORMERR response as described above. Such firewallsMUST NOT<bcp14>MUST NOT</bcp14> treat messages with OPCODE = 0 and QDCOUNT = 0 as malformed. SeeSection 4 of<xreftarget="RFC8906"/>target="RFC8906" sectionFormat="of" section="4"/> for further guidance.</t> </section> <section anchor="security-considerations"> <name>Security Considerations</name> <t>This document clarifies the DNS specification <xref target="RFC1035"/> and aims to improve interoperability between different DNS implementations. In general, the elimination of ambiguity seems well-aligned with security hygiene.</t> </section> <section anchor="iana-considerations"> <name>IANA Considerations</name> <t>This document has no IANA actions.</t> </section><section anchor="acknowledgements"> <name>Acknowledgements</name> <t>The clarifications in this document were prompted by questions posed by Ted Lemon, which reminded the authors of earlier, similar questions and motivated them to pick up their pens. Ondrej Sury, Warren Kumari, Peter Thomassen, Mark Andrews, Lars-Johan Liman, Jim Reid and Niall O'Reilly provided useful feedback.</t> </section></middle> <back> <references> <name>References</name> <references anchor="sec-normative-references"> <name>Normative References</name><reference anchor="RFC1034" target="https://www.rfc-editor.org/info/rfc1034" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml"> <front> <title>Domain names - concepts and facilities</title> <author fullname="P. Mockapetris" initials="P." surname="Mockapetris"/> <date month="November" year="1987"/> <abstract> <t>This RFC is the revised basic definition of The Domain Name System. It obsoletes RFC-882. This memo describes the domain style names and their used for host address look up and electronic mail forwarding. It discusses the clients and servers in the domain name system and the protocol used between them.</t> </abstract> </front> <seriesInfo name="STD" value="13"/> <seriesInfo name="RFC" value="1034"/> <seriesInfo name="DOI" value="10.17487/RFC1034"/> </reference> <reference anchor="RFC1035" target="https://www.rfc-editor.org/info/rfc1035" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml"> <front> <title>Domain names - implementation and specification</title> <author fullname="P. Mockapetris" initials="P." surname="Mockapetris"/> <date month="November" year="1987"/> <abstract> <t>This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication.</t> </abstract> </front> <seriesInfo name="STD" value="13"/> <seriesInfo name="RFC" value="1035"/> <seriesInfo name="DOI" value="10.17487/RFC1035"/> </reference> <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"> <front> <title>Key words for use in RFCs to Indicate Requirement Levels</title> <author fullname="S. Bradner" initials="S." surname="Bradner"/> <date month="March" year="1997"/> <abstract> <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="2119"/> <seriesInfo name="DOI" value="10.17487/RFC2119"/> </reference> <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"> <front> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <author fullname="B. Leiba" initials="B." surname="Leiba"/> <date month="May" year="2017"/> <abstract> <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="8174"/> <seriesInfo name="DOI" value="10.17487/RFC8174"/> </reference> <reference anchor="RFC3425" target="https://www.rfc-editor.org/info/rfc3425" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3425.xml"> <front> <title>Obsoleting IQUERY</title> <author fullname="D. Lawrence" initials="D." surname="Lawrence"/> <date month="November" year="2002"/> <abstract> <t>The IQUERY method of performing inverse DNS lookups, specified in RFC 1035, has not been generally implemented and has usually been operationally disabled where it has been implemented. Both reflect a general view in the community that the concept was unwise and that the widely-used alternate approach of using pointer (PTR) queries and reverse-mapping records is preferable. Consequently, this document deprecates the IQUERY operation, declaring it entirely obsolete. This document updates RFC 1035. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="3425"/> <seriesInfo name="DOI" value="10.17487/RFC3425"/> </reference><xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml"/> <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.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3425.xml"/> </references> <references anchor="sec-informative-references"> <name>Informative References</name><reference anchor="RFC8906" target="https://www.rfc-editor.org/info/rfc8906" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8906.xml"> <front> <title>A Common Operational Problem in DNS Servers: Failure to Communicate</title> <author fullname="M. Andrews" initials="M." surname="Andrews"/> <author fullname="R. Bellis" initials="R." surname="Bellis"/> <date month="September" year="2020"/> <abstract> <t>The DNS is a query/response protocol. Failing to respond to queries, or responding incorrectly, causes both immediate operational problems and long-term problems with protocol development.</t> <t>This document identifies a number of common kinds of queries to which some servers either fail to respond or respond incorrectly. This document also suggests procedures for zone operators to apply to identify and remediate the problem.</t> <t>The document does not look at the DNS data itself, just the structure of the responses.</t> </abstract> </front> <seriesInfo name="BCP" value="231"/> <seriesInfo name="RFC" value="8906"/> <seriesInfo name="DOI" value="10.17487/RFC8906"/> </reference> <reference anchor="RFC7873" target="https://www.rfc-editor.org/info/rfc7873" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7873.xml"> <front> <title>Domain Name System (DNS) Cookies</title> <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/> <author fullname="M. Andrews" initials="M." surname="Andrews"/> <date month="May" year="2016"/> <abstract> <t>DNS Cookies are a lightweight DNS transaction security mechanism that provides limited protection to DNS servers and clients against a variety of increasingly common denial-of-service and amplification/ forgery or cache poisoning attacks by off-path attackers. DNS Cookies are tolerant of NAT, NAT-PT (Network Address Translation - Protocol Translation), and anycast and can be incrementally deployed. (Since DNS Cookies are only returned to the IP address from which they were originally received, they cannot be used to generally track Internet users.)</t> </abstract> </front> <seriesInfo name="RFC" value="7873"/> <seriesInfo name="DOI" value="10.17487/RFC7873"/> </reference> <reference anchor="RFC5936" target="https://www.rfc-editor.org/info/rfc5936" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5936.xml"> <front> <title>DNS Zone Transfer Protocol (AXFR)</title> <author fullname="E. Lewis" initials="E." surname="Lewis"/> <author fullname="A. Hoenes" initials="A." role="editor" surname="Hoenes"/> <date month="June" year="2010"/> <abstract> <t>The standard means within the Domain Name System protocol for maintaining coherence among a zone's authoritative name servers consists of three mechanisms. Authoritative Transfer (AXFR) is one of the mechanisms and is defined in RFC 1034 and RFC 1035.</t> <t>The definition of AXFR has proven insufficient in detail, thereby forcing implementations intended to be compliant to make assumptions, impeding interoperability. Yet today we have a satisfactory set of implementations that do interoperate. This document is a new definition of AXFR -- new in the sense that it records an accurate definition of an interoperable AXFR mechanism. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="5936"/> <seriesInfo name="DOI" value="10.17487/RFC5936"/> </reference> <reference anchor="RFC1996" target="https://www.rfc-editor.org/info/rfc1996" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1996.xml"> <front> <title>A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)</title> <author fullname="P. Vixie" initials="P." surname="Vixie"/> <date month="August" year="1996"/> <abstract> <t>This memo describes the NOTIFY opcode for DNS, by which a master server advises a set of slave servers that the master's data has been changed and that a query should be initiated to discover the new data. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="1996"/> <seriesInfo name="DOI" value="10.17487/RFC1996"/> </reference> <reference anchor="RFC2136" target="https://www.rfc-editor.org/info/rfc2136" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2136.xml"> <front> <title>Dynamic Updates in the Domain Name System (DNS UPDATE)</title> <author fullname="P. Vixie" initials="P." role="editor" surname="Vixie"/> <author fullname="S. Thomson" initials="S." surname="Thomson"/> <author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/> <author fullname="J. Bound" initials="J." surname="Bound"/> <date month="April" year="1997"/> <abstract> <t>Using this specification of the UPDATE opcode, it is possible to add or delete RRs or RRsets from a specified zone. Prerequisites are specified separately from update operations, and can specify a dependency upon either the previous existence or nonexistence of an RRset, or the existence of a single RR. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="2136"/> <seriesInfo name="DOI" value="10.17487/RFC2136"/> </reference> <reference anchor="RFC8490" target="https://www.rfc-editor.org/info/rfc8490" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8490.xml"> <front> <title>DNS Stateful Operations</title> <author fullname="R. Bellis" initials="R." surname="Bellis"/> <author fullname="S. Cheshire" initials="S." surname="Cheshire"/> <author fullname="J. Dickinson" initials="J." surname="Dickinson"/> <author fullname="S. Dickinson" initials="S." surname="Dickinson"/> <author fullname="T. Lemon" initials="T." surname="Lemon"/> <author fullname="T. Pusateri" initials="T." surname="Pusateri"/> <date month="March" year="2019"/> <abstract> <t>This document defines a new DNS OPCODE for DNS Stateful Operations (DSO). DSO messages communicate operations within persistent stateful sessions using Type Length Value (TLV) syntax. Three TLVs are defined that manage session timeouts, termination, and encryption padding, and a framework is defined for extensions to enable new stateful operations. This document updates RFC 1035 by adding a new DNS header OPCODE that has both different message semantics and a new result code. This document updates RFC 7766 by redefining a session, providing new guidance on connection reuse, and providing a new mechanism for handling session idle timeouts.</t> </abstract> </front> <seriesInfo name="RFC" value="8490"/> <seriesInfo name="DOI" value="10.17487/RFC8490"/> </reference><xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8906.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7873.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5936.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1996.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2136.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8490.xml"/> </references> </references><?line 124?><section anchor="Survey"> <name>Guidance for theuseUse of QDCOUNT in the DNS Specification</name> <t>The DNSSpecificationspecification <xref target="RFC1035"/> provides some guidance about the values of QDCOUNT that are appropriate in various situations. A brief summary of this guidance is collated below.</t> <section anchor="opcode-0-query-and-1-iquery"> <name>OPCODE = 0 (QUERY) and 1 (IQUERY)</name> <t><xref target="RFC1035"/> significantly predates the use of the normativerequirements keywordsrequirement key words specified in BCP 14 <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="default"/>, and parts of it are consequently somewhat open to interpretation.</t> <t>Section4.1.2 ("Question<xref target="RFC1035" sectionFormat="bare" section="4.1.2">"Question sectionformat") has this to sayformat"</xref> of <xref target="RFC1035"/> states the following about QDCOUNT:</t> <ul empty="true"> <li><t>The<t>"The section contains QDCOUNT (usually 1)entries</t>entries"</t> </li> </ul> <t>The only documented exceptions within <xref target="RFC1035"/> relate to the IQueryOpcode,OpCode, where the request has "an empty question section" (QDCOUNT = 0), and the response has "zero, one, or multiple domain names for the specified resource as QNAMEs in the question section". The IQuery OpCode wasmade obsolete inobsoleted by <xref target="RFC3425"/>.</t> <t>In the absence of clearly expressed normative requirements, we rely on other text in <xref target="RFC1035"/> that makes use of the definite article orother textthat implies a singular question and, by implication, QDCOUNT = 1.</t> <t>For example,Section 4.1:</t><xref target="RFC1035" sectionFormat="of" section="4.1"/> states the following:</t> <ul empty="true"> <li><t>the<t>"the question for the nameserver</t>server"</t> </li> </ul><t>and:</t><t>and</t> <ul empty="true"> <li><t>The<t>"The question section contains fields that describe a question to a nameserver</t>server."</t> </li> </ul><t>and in<t>And per Section4.1.1. ("Header<xref target="RFC1035" sectionFormat="bare" section="4.1.1">"Header sectionformat"):</t>format"</xref> of <xref target="RFC1035"/>:</t> <ul empty="true"> <li><t>AA<t>"AA: Authoritative Answer - this bit is valid in responses, and specifies that the responding name server is an authority for the domain name in questionsection.</t>section."</t> </li> </ul> <t>DNS Cookies<xref target="RFC7873"/> in Section 5.4(<xref target="RFC7873" sectionFormat="of" section="5.4"/>) allow a client to receive a valid Server Cookie without sending a specific question by sending a request (QR = 0) with OPCODE = 0 and QDCOUNT = 0, with the resulting response also containing no question.</t><t>DNS<t>The DNS Zone Transfer Protocol(AXFR) <xref target="RFC5936"/> in Section 2.2(<xref target="RFC5936" sectionFormat="of" section="2.2"/>) allows an authoritative serveroptionallyto optionally send a response message (QR = 1) to a standardAXFRAuthoritative Transfer (AXFR) query (OPCODE = 0, QTYPE=252) with QDCOUNT = 0 in the second or subsequent message of a multi-message response.</t> </section> <section anchor="opcode-4-notify"> <name>OPCODE = 4 (NOTIFY)</name> <t>DNS Notify <xref target="RFC1996"/> also lacks a clearly defined range of values for QDCOUNT. Section3.7 says:</t><xref target="RFC1996" sectionFormat="bare" section="3.7"/> states that:</t> <ul empty="true"> <li><t>A<t>"A NOTIFY request hasQDCOUNT > 0</t>QDCOUNT>0"</t> </li> </ul><t>but<t>However, all other text in the RFCtalks aboutdiscusses the <QNAME, QCLASS, QTYPE> tuple in thesingular.</t>singular form.</t> </section> <section anchor="opcode-5-update"> <name>OPCODE = 5 (UPDATE)</name> <t>DNS Update <xref target="RFC2136"/> renames the QDCOUNT field to ZOCOUNT, but the value is constrained to be one by Section2.3 ("Zone Section"):</t><xref target="RFC2136" sectionFormat="bare" section="2.3">"Zone Section"</xref>:</t> <ul empty="true"> <li><t>All<t>"All records to be updated must be in the same zone, and therefore the Zone Section is allowed to contain exactly onerecord.</t>record."</t> </li> </ul> </section> <section anchor="opcode-6-dns-stateful-operations-dso"> <name>OPCODE = 6 (DNS Stateful Operations, DSO)</name> <t>DNS Stateful Operations (DSO) (OpCode 6) <xref target="RFC8490"/>(DSO - OpCode 6) attempts to preservepreserves compatibility with the standard DNS12 octet header, and does so12-octet header by requiringthatall four of the section count values to be set to zero.</t> </section> <section anchor="conclusion"> <name>Conclusion</name> <t>There is no text in <xref target="RFC1035"/> that describes how other parameters in the DNSmessagemessage, such asAA, RCODEAA and RCODE, should be interpreted in the case where a message includes more than one question. An originator of a query with QDCOUNT > 1 can have no expectations of how it will be processed, and the receiver of a response with QDCOUNT > 1 has no guidance for how it should be interpreted.</t> <t>The allowable values of QDCOUNT seem to be clearly specified for OPCODE = 4 (NOTIFY), OPCODE = 5(UPDATE)(UPDATE), and OPCODE = 6 (DNS Stateful Operations, DSO). OPCODE = 1 (IQUERY) is obsolete and OPCODE = 2 (STATUS) is not specified. OPCODE = 3 is reserved.</t> <t>However, the allowable values of QDCOUNT for OPCODE = 0 (QUERY) are specified in <xref target="RFC1035"/> without the clarity of normative language, and this looseness of language results in some ambiguity.</t> </section> <section anchor="acknowledgements" numbered="false"> <name>Acknowledgements</name> <t>The clarifications in this document were prompted by questions posed by <contact fullname="Ted Lemon"/>, which reminded the authors of earlier, similar questions and motivated them to pick up their pens. <contact fullname="Ondrej Sury"/>, <contact fullname="Warren Kumari"/>, <contact fullname="Peter Thomassen"/>, <contact fullname="Mark Andrews"/>, <contact fullname="Lars-Johan Liman"/>, <contact fullname="Jim Reid"/>, and <contact fullname="Niall O'Reilly"/> provided useful feedback.</t> </section> </section> </back><!-- ##markdown-source: H4sIAAAAAAAAA5VZ2XYbNxJ9x1dglIeRzpA8ojbHymRhJDl2RhZlUTqZ5A3s BkVEvaXRLZrx8b/kW/Jlc6uwdJOSZjIPPiKbDaCWW7duwcPhUDSmyfSpfFfI Zqnl+dVsID+cn03vrm6lsXK3ta3KsvWenBZapGVSqBxvp7VaNEOjm8UwLWxZ DX9Lk7It8MgOy0IP9w9FW6Wq0fZU3rw5G+8fHgth23lurDVl0awrOvLi9o0w VX0qm7q1zcH+/uv9A6FqrcicRteFbsTq/pSMml7Ln8r6wRT38oe6bCvxsOpe Gp6TOSJRzam0TSpEUqZ481S2dqhsYoyozKmQciibMuG/dp3XemHd57Ju+ItQ bbMsa34T/6Q0BZk/kt/rLDOWHzn3b9S6/7Cs7ztj5GxtG51beVYWtLVp8wF+ TEb8qprPa/2It2dn/N3iaA2zr6fy+/KjPDzZ58eJadan8kqvclU/IAr8rExx 9NVbuX/45fEr/wgxr/Hm3Yy/V0sE/1T+YyxPjvfl0cGhHB/uux11rkx2Kmu1 /s7YZASTN938cSQn80yve17+WOreM3byLCvbdJEhRz0zJzkcrlOVb9p0dblh 0yGMkkfH8vgEXsrDo75Vvyo65rsk7j5KylyI4XCIgCFEKmmEuF0Cj0Bgm+ui kR5ehC5J8JLzNY4u6GVTEEwIzUBuudKpfFRZq2W5oIcioLtSNdyE5QgAQUzm 2lp1jz1XplnK6fXZ9PxCfi335e6Hu4ubn/eAHqlkrj6avM0FdoNjA6mKVNpK J2ZhsJROrfVvralx7Fwv1aMp21qulrpwVtArqpHwURZlI4KF9F0XHDuNpSPn fG7SNNNCfEHoqsu0TRpUD4WCK1VWdQlEl5n89OlvrsyOPn+On48/f4ZrSdam OFV1/sYImFjzwXe51CrV9QAGl1b7uCHswcGUYpBrVQhaWLT5HOFDJH6DY2Sa DXt+8A/kTLPN9JIKp8A70I2S97rQtcqk1QUOMw0+UOFUul5gVbaWVaZaa4AN uShrt68zXURnKAGyLay5L2Dd+GQ4xz5s94BsbdQDYMDIMHCMcIYaKO415c8l ZCTfIgWPtJU33nubyERZhk1EBueO8pRqQWGD3zWlnUBQa1vhGHzbfQlJe7Q9 Mk3ZLumjyExuGhVCRz8C296MmF0+NYI74Ah2hWjA0TnwY2hL4BWxGo+I0RGl xiQtKmqA2D5ysGPkelkVFF7yJ/jQeWzbZCmVlZMJO3nDrgDWBF+Z6oVB2AUh gmqOYU6mBzjB6AYmW5m3WWMqBN9HDPYAmtrHAzyK3VZgVXhCqYSdq6XByQFY eJEA2TO+1hkIAAscmpoNdlhpOccxC2DItvWjXrNV+qPBZmRnbZpGc9WLkGxO wle0EnF/BFgAGxROUpsqAJixAcoqEFSORkXMhKWZ8DVPh1sZohnQwfkrVNPW 1Ep7mYwcRbgUT/L6FR8CixzZxWKdEyw37EYYRII0m8V6c9MeWEL5IH8b1NdH vAiI/yt8OCJiutV1booyK+/XaLcoQbOVC8dWD0jBqqxTK3fe381udwbur7ya 8uebiw93724uzunz7O3k8jJ+cG8IfJneXfrf6VO38mz6/v3F1blbjKdy69H7 yc/YgCK5M72+fTe9mlzuPLGSS9KVkSEKrmqEJyXgOwzMgXKs+f7sWo6PPN0e jMevQbHuy5fjV+BergDXE8oCqXZfEeG1VFWlVU2bIDlglgp1n6EOcIRdlqtC UiVwSF+UX2LiUA1M5xAG65DV+9akiqrJIzcNaY2AfwL0SKity3c4MwGbzolu 24J3+fRpxvXz+fNI/LQ0md6Ai9sKdiYZfKP3URxrpk37hE0jtp7rrJ4GIMZy oDefG/jUrD0JUKZElymDHoFUaeJOVJUL2p3XA/ghSAKKV7+3vdTWAxBDs0Th P2kz2w3xHiqVHqO0CybbBjGjovPV3u+BYqMH/jeLoiWeN2VeEixxhoDWiGQ4 +queEQ5DZr+RY7c/0tuw9alQ1LnI7bKuueMOAYtcNQT90KulpPrtKyjfBDo9 4RO93TzicRaqGHkZy90305v3Fzc3RB1vQJcrYNsHDNBNsGyTeLAxOIPC3Es3 uv0KFAzzQaILatOeEdirl1lrOxjKilxl5DDJGr+Va+RgatIn3trOsT4dQJmW j8DejBrkIjoTU/h/WIPvlIpoDWI+0zpKpyOK+6dP3xLLvN4/ActQ8S7amtt9 KH6uAixpayqcsyB4WFpsi2fXKoJepZBvVjQZF8rM5MQqWjAtlhVpKJPREXPd rDSaaGoWC6dbaCO8nnEbdCezDPE6b8CiMeQxFESsdSf+Vhirhipzco6DZr1P Yrm+N9iJHP3zj3eTq8n/8HKJmEJW8JsqceZQkCbJQ1GuMp3eu37tOpSPSaJ6 OnZTUtRMsHlF1YFpo9O8FaghFXh0i18udV4WA89cUASmIELmpszjJfdisGVm SHFaBAMHd5txo8rLxjxShdK6nLJQmeQBMoC+mxoKmSI7LdJa/ypB0OuB/Emh hAv5rxaNwQzENZPW7bLMlbXUg95jkJQTWrECNV+q2g5/LIm8Lg04eyB/NLm8 0Sbl3F8ZYFlM/44HJFhiW0GzWLSZXGidzlXy4KcU+khx/SG0oRd6S2/cmG3A 7dMXvsl0k83mC94A3x5iu0MFto5qo8qJs02cstB3AdvaEHOweK4xkWEn07QB olttVTDNEcmHg6jDgd05I3MNliccffES44Ln3rmvQmwMY6Rs2amChxvMea5l daEqmH7NYxwiHUChnlg8OWVBqp5RZJyHpCfxtuZdKUIr8h2lyrIwyhnlW0ek ldF4dCB3d+KoZv0Prgfs7HEBcSBIlUOcc7xDhE+F+IZbQ1gWtX5IQRAvcryH makhKewSzNIoFBZCqj8munKlRBXPsqMXtqj0OVLvYC9yNK1oCKM607WOYzc8 Yat3AGyNSu2qNJi5g1R1tLvnhOFG9+L1v4PrBm7AB5jj9JKinmAe3Y/YAHPR DcfYA9N+wo3iw9Xk/UWch5+YMeLYOWfktDqjiXLFTQACpJzbMtMOsC4Uh0cH x6TBhL+nU3NUdcKYYe2FgOqPyLIlCf48igY0SSCWwHfhpk/Z6I+N3A43V06O udkGVNKBPOqZhmZXTDyYVuB8bxNeRNzP0zANd/dtn9cIuANiTX7HlfVAdJkY kyLAlvqjogYykD2UMtI2ghgIhvKAiII7akGJjJjcDncHTuQpS73mCL0cBndz ZikVNtnemaLULxxIvt2dt3xZ8qRu2ArMyxPmex7vkYpJYdFC6A6SKopuKfAH vGV473h5MMBauifculXyktK9RpebfQtpJ0hEt9Afuo5B6mGWTtoODQJPhHtW lg90lNMZr758dci3R9Hp49GRmyrpNgVZLljSQTVqOCeU92Tm7HGbcTETQwOq bLLqblaiFfN1+BmbuGqo0E+gGHddVbh7E1YCvcIduCc+JlSe2KDTaZktQ8o5 VmVfO5O7v5Cevq1VYaFd5HW4admd/PvNzZ4PwvHrw5PNIByAMDkI1KZjqF1+ fSpKJjKmPWJNTUrqiTIWux9uCPT+StE2SLeqU0mn863Buu/9QH64/fn64uuD 4wMXiF7d7McpS8PflMjKtnPfDqIQd5dvFKVhsCCYtNXJjuQuxOu7N9S7KE5X UCKLtQ/I+PVrCghHN0OSLGPBsY+/CnKXazJervHNkjeXZa0L5OHoFXUU60pF uiM3GLxT6vtCzAEimpo3WYtHEcx6mKPJlCgG/snUi6idXU5mMx+9b0TTEoOH cHmCYvf//CP6fyx3767PJ7cX3n83Vnr/D8YMCOgs5v/efaSjFcrmL1N+AK5D q4zSxCkIf+3jblHn1Ac14b9D1yFIhZHpHwUugeuoNL4+cSvdhRCEYotwzTuv qMZ/j9fSPFUv3AipsU9/a+YMf/ncxGIh/uWbV3rTHbkFkBO5y/oMqGctOK2C /B7I89nUh+2Zn8MEc/R6HzHcxbvgQg/yEwgnDJ1o2OSgoD5G1QSr8gqr/cAR Kz7WCx01PpBl0oAvwtU1fhNpyWKRoutaoPsfAeVgtKAr+XifFxpEWzRBR87R 1N3MSjrARQCzRpK1Nty/u+sKEMvLPTS0FyuXoE2H3e4CU5int+/dZevAD9kW BJql29dSbqm7UHECKN6tdzf+8e5AbtwdoBGBJcw9zWBlLZgaHOVscCxNyHQZ FK56oS4QKZ9KLCKX0MNWGBDEXIfxXacReaE31I59IgU+OQXVTre/9/3pwe/+ rPcjJyKfu+IM29Io6Ssl8FMn0rC/eIbvBvIZEmBnXsK+2Mb+qHu1mwEIJlHP bWx3IHZnt5Pbu9meg1LTGdnb6ZB+9AVBvsf/rHjpnjdSEuL43IRS9xUrA/fb DrihZTdhIm7Wm3NJBn5vgbMgnGFcVmL+LejyBm+G331bZgG8eakHH/4DC9TU d3geAAA= --></rfc>