Document Shepherd: Tim Wicinski
Area Director: Terry Manderson
Document Type: Proposed Standard
This document specifies the EDNS(0) ’Padding’ option, which allows
DNS clients and servers to pad request and response messages by a
variable number of octets.
Since this is deploying a new EDNS(0) option, it is marked as Proposed Standard while it is deployed.
2. Review and Consensus
This document was brought to the working group and immediately found consensus. The only process issue was that this was being handled by the DPRIVE working group, and not DNSOP. It was quickly confirmed by the co-chairs and the area director of DNSOP that this document could be handled here, and there was plenty of DNS subject experts to provide expert reviews
This document had wide consensus, and there was little controversy in this.
3. Intellectual Property
There are no known IPR disclosures, and the authors have confirmed they know of none.
4. Other Points
There are no downward references.
Under IANA considerations, the EDNS option code '12' was assigned to this feature.
This section is not meant to be submitted, but is here as a useful checklist of things the document shepherd is expected to have verified before publication is requested from the responsible Area Director. If the answers to any of these is "no", please explain the situation in the body of the writeup.
X Does the shepherd stand behind the document and think the document is ready for publication?
X Is the correct RFC type indicated in the title page header?
X Is the abstract both brief and sufficient, and does it stand alone as a brief summary?
X Is the intent of the document accurately and adequately explained in the introduction?
X Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been requested and/or completed?
X Has the shepherd performed automated checks -- idnits (see http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of BNF rules, XML code and schemas, MIB definitions, and so on -- and determined that the document passes the tests? (In general, nits should be fixed before the document is sent to the IESG. If there are reasons that some remain (false positives, perhaps, or abnormal things that are necessary for this particular document), explain them.)
X Has each author stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79?
X Have all references within this document been identified as either normative or informative, and does the shepherd agree with how they have been classified?
X Are all normative references made to documents that are ready for advancement and are otherwise in a clear state?
X If publication of this document changes the status of any existing RFCs, are those RFCs listed on the title page header, and are the changes listed in the abstract and discussed (explained, not just mentioned) in the introduction?
X If this is a "bis" document, have all of the errata been considered?
X IANA Considerations: