Document Shepherd Writeup
draft-davids-forsalereg-19
I have been asked to act as Document Shepherd for this document.
This is a Document Shepherd Write-Up as described in RFC 4858 section
3 and is based on the template published at:
<https://datatracker.ietf.org/doc/shepherdwriteup-template/individual>
which is applicable to this draft as an AD-sponsored individual
submission. The sponsoring AD is Mohamed Boucadair.
Document History
1. Was the document considered in any WG, and if so, why was it not
adopted as a work item there?
The document was presented in dnsop at IETF 124. There was no
objection to the proposal, and support in the room for it to be
published in the RFC series. The general sentiment recorded in
the minutes was that there was "no energy to adopt here [in dnsop],
no objection to ISE path".
The dnsop working group has a lot going on and the document was
in good shape. My assessment of the situation is that the working
group sees value in the work but does not feel that working group
consensus is necessary for the document to proceed.
2. Was there controversy about particular points that caused the
WG to not adopt the document?
No.
3. Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in separate
email messages to the responsible Area Director. (It should be in
a separate email because this questionnaire is publicly available.)
No.
4. For protocol documents, are there existing implementations of
the contents of the document? Have a significant number of potential
implementers indicated plans to implement? Are any existing
implementations reported somewhere, either in the document itself
(as RFC 7942 recommends) or elsewhere (where)?
The protocol has been implemented in the .NL registry by SIDN and
as a result there are 2+ years of experience in using it. That
implementation is described in section 7, "Implementation Status".
There is running code available at:
<https://forsalereg.sidnlabs.nl/demo>
with source code available at:
<https://github.com/mdavids/rfc/blob/main/tools/webserver.go>
A DNS zone has been published for the purposes of checking
implementations of this protocol: testdns.nl
Another implementation of a tool to perform syntax checking is
available at <https://forsale.bitfire.nl>. Notably this tool was
constructed using an LLM trained on the specification that is the
subject of this review. This provides additional confidence that
the specification is sufficiently complete and unambiguous for
it to be used to produce a conformant implementation.
An implementation of a lightweight Model Context Protocol (MCP)
server that allows clients to check whether a domain name advertises
itself for sale can be found here:
<https://github.com/CultriX-Github/mcp-forsale>
Additional Reviews
5. Do the contents of this document closely interact with technologies
in other IETF working groups or external organizations, and would
it therefore benefit from their review? Have those reviews occurred?
If yes, describe which reviews took place.
The document describes a protocol for publishing and consuming
particular information in the DNS. It has been reviewed by
participants of the dnsop working group (for which see section 1).
The document does not closely relate to work in other IETF working
groups, or conflict with other proposals known to be underway or
anticipated by any IETF working group.
The ideas in this draft have been discussed informally with various
ccTLD registry operators in the CENTR community over the past
several years. This document is in part a result of those
conversations and the associated positive feedback. Those
conversations do not constitute review of this specific proposal,
but they illustrate the recognition of the problem space.
This specific proposal has been presented to the Technical and
Marketing Commission of the Dutch Association of Registrars
<https://www.verenigingvanregistrars.nl/> who indicated interest
and expressed no concerns.
This specific proposal was described in blog posts published by
SIDN in both Dutch and English. The feedback received by SIDN was
supportive and expressed no concerns:
<https://www.sidnlabs.nl/en/news-and-blogs/a-digital-for-sale-sign-for-nl-domain-names>
This specific proposal was discussed in the form of publications
by two independent industry commentators, illustrating awareness
of the proposal in communities that could reasonably be expected
to have an interest:
<https://www.namepros.com/threads/could-dns-txt-records-soon-show-your-domains-price-ietf-draft.1358501/>
<https://domain-recht.de/domain-handel/sonstiges-domain-handel/cctlds-sidn-bringt-fuer-nl-domains-in-das-dns-integrierte-verkaufsanzeigen-70136.html>
An early DNS directorate review of an earlier revision of this
document was completed in June 2025. That review found no technical
issues, but recommended additional review given the potential for
wide adoption. In my opinion, the additional reviews described
here address that concern.
The document has been reviewed by GENART, SECDIR, DNSDIR, INTDIR,
ARTART and OPSDIR and in all cases any issues raised have been
addressed to the satisfaction of the reviewer.
6. Describe how the document meets any required formal expert review
criteria, such as the MIB Doctor, YANG Doctor, media type, and URI
type reviews.
No such expert review is required.
The document includes an IANA action to add an entry to the
"Underscored and Globally Scoped DNS Node Names" registry defined
in RFC 8552, a registry that operates under "Expert Review"
registration. In my opinion the requirements of RFC 8552 saection
4.1.5 are clearly met by this document.
The author of this document consulted the IANA support desk at
IETF 124 who did not recommend any specific changes.
7. If the document contains a YANG module, has the final version
of the module been checked with any of the recommended validation
tools for syntax and formatting validation? If there are any resulting
errors or warnings, what is the justification for not fixing them
at this time? Does the YANG module comply with the Network Management
Datastore Architecture (NMDA) as specified in RFC 8342?
The document contains no YANG modules.
8. Describe reviews and automated checks performed to validate
sections of the final version of the document written in a formal
language, such as XML code,BNF rules, MIB definitions, CBOR's CDDL,
etc.
A formal definition of the "for-sale" record format is provided
in section 2.1 using ABNF. I have used the ABNF checker at
<https://author-tools.ietf.org/abnf> to confirm that the definition
contains no errors or undefined rules. No such problems were
found.
Document Shepherd Checks
9. Based on the shepherd's review of the document, is it their
opinion that this document is needed, clearly written, complete,
correctly designed, and ready to be handed off to the responsible
Area Director?
Yes.
10. Several IETF Areas have assembled lists of common issues that
their reviewers encounter. For which areas have such issues been
identified and addressed? For which does this still need to happen
in subsequent reviews?
I have reviewed the guidelines in RFC 5706 and in my opinion there
are no outstanding issues relevant to this document.
11. What type of RFC publication is being requested on the IETF
stream (Best Current Practice, Proposed Standard, Internet Standard,
Informational, Experimental or Historic)? Why is this the proper
type of RFC? Do all Datatracker state attributes correctly reflect
this intent?
Informational. The document defines an operational convention
that is proposed for the general information of the Internet
community. The document does not include a recommendation or
contain any protocol change. Both the document front page and
Datatracker state attributes correctly reflect this intended
status.
12. Have reasonable efforts been made to remind all authors of the
intellectual property rights (IPR) disclosure obligations described
in BCP 79? To the best of your knowledge, have all required disclosures
been filed? If not, explain why. If yes, summarize any relevant
discussion, including links to publicly-available messages when
applicable.
The author has confirmed that there are no IPR claims on the
contents of this document.
13. Has each author, editor, and contributor shown their willingness
to be listed as such? If the total number of authors and editors
on the front page is greater than five, please provide a justification.
There is one author. The author has shown their willingness to
be listed as such.
14. Document any remaining I-D nits in this document. Simply running
the idnits tool is not enough; please review the "Content Guidelines"
on authors.ietf.org. (Also note that the current idnits tool generates
some incorrect warnings; a rewrite is underway.)
The document has been validated using idnits on 2025-11-25 and
no issues were found.
I have reviewed the document using the "Content Guidelines" at
<https://authors.ietf.org/en/required-content> and did not find
any issue that the idnits tool had missed.
15. Should any informative references be normative or vice-versa?
See the IESG Statement on Normative and Informative References.
The references are consistent with the IESG guidelines.
16. List any normative references that are not freely available to
anyone. Did the community have sufficient access to review any such
normative references?
There are no such normative references.
17. Are there any normative downward references (see RFC 3967 and
BCP 97) that are not already listed in the DOWNREF registry? If so,
list them.
There are no normative downward references.
18. Are there normative references to documents that are not ready
to be submitted to the IESG for publication or are otherwise in an
unclear state? If so, what is the plan for their completion?
There are no such normative references.
19. Will publication of this document change the status of any
existing RFCs? If so, does the Datatracker metadata correctly reflect
this and are those RFCs listed on the title page, in the abstract,
and discussed in the introduction? If not, explain why and point
to the part of the document where the relationship of this document
to these other RFCs is discussed.
The publication of this document will not change the status of
any existing RFCs.
20. Describe the document shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body
of the document. Confirm that all aspects of the document requiring
IANA assignments are associated with the appropriate reservations
in IANA registries. Confirm that any referenced IANA registries
have been clearly identified. Confirm that each newly created IANA
registry specifies its initial contents, allocations procedures,
and a reasonable name (see RFC 8126).
The IANA Considerations section is present and conforms to BCP
26.
21. List any new IANA registries that require Designated Expert
Review for future allocations. Are the instructions to the Designated
Expert clear? Please include suggestions of designated experts, if
appropriate.
The document does not request the creation of any new IANA
registries.