1. Summary
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.
Checklist
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: