The "_for-sale" Underscored and Globally Scoped DNS Node Name
draft-davids-forsalereg-21

RFC Editor Note was changed to

RFC Editor Note

  Please make this change:

  OLD: Some URI schemes RECOMMENDED in Section 2.2.3 do not mandate

  NEW: Some URI schemes recommended in Section 2.2.3 do not mandate

[Ballot comment]
This can indeed be useful ;-) thanks for doing it in the IETF stream.

Like others, I would prefer not having "RECOMMEND http".

Also, should there be a registry for all tag rather than an open-ended section 2.2.5 about 'future tags' ?

[Ballot comment]
Thanks to Watson Ladd for their secdir review.

I also agree with Mike Bishop and Gorry Fairhurst on the RECOMMENDED use of http, it should not be recommended, or at least addressed as an issue in Section 4 (section 2.2.3).

[Ballot comment]
# Andy Newton, ART AD, comments for draft-davids-forsalereg-20
CC @anewton1998

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-davids-forsalereg-20.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Thanks to the Reviewers

Many thanks to Takahiro Nemoto for the two ARTART reviews.


## Comments

Thank you for addressing the concerns that occured during Last Call, and for removing the Ethical Considerations
from this document.

[Ballot comment]
I am abstaining on this document because of Section 6.  The IETF doesn’t have a community consensus set of ethics for DNS operations, and I feel they are being added here without appropriate review.  The DISCUSS criteria set in https://datatracker.ietf.org/doc/statement-iesg-discuss-criteria-in-iesg-review-20140507/ does not a way to raise these concerns.

More specifically:

** Section 6
  Although not specifically designed for this purpose, the mechanism
  described in this document may also facilitate domain name
  transactions by professional speculators, often referred to as
  domainers, and those commonly referred to as domain drop catchers.
  Some may view this as controversial.
…
  This
  potentially reduces the advantage currently held by these
  professionals, and fosters a more equitable environment for all.

Why is a value judgement being made on a business model?  Why is this text needed?

** Section 6
  Furthermore, this mechanism avoids creating unnecessary dependencies
  on registries for market transactions, which could otherwise
  introduce complexities and potential for unintended commercial
  entanglements.

What is the “ethical consideration” for reducing dependencies on registries?

===

Thank you to Russ Housley for the GENART review.

Technical comment feedback on the document:

** Section 2.2.4
  For current and
  reliable information, interested parties SHOULD engage directly with
  the seller via "furi=" or conventional mechanisms.

-- Is the use of a “SHOULD” the right narrative approach?  What is the alternative to “engaging directly with the seller …”?

-- If the normative “SHOULD” stands, please define the interoperable definition of “conventional mechanisms”?

** Section 2.3
  Any text suggesting that a domain is not for sale is invalid content.
  If a domain name is not or no longer for sale, a "_for-sale"
  indicator SHOULD NOT exist.  The presence of a valid "_for-sale" TXT
  record SHOULD therefore be regarded as an indication that the domain
  name is for sale.

Is the use of “SHOULD” the right narrative approach?  If so, what are the circumstances for which the “_for-sale” would be used but the domain is not for sale, that is the use of “SHOULD NOT” suggests a recommendation.

** Section 4
  Therefore, it is RECOMMENDED that any parsing and publishing be
  conducted with the utmost care.

Is “RECOMMENDED” the right narrative approach?  If so, what is the interoperable definition of “parsing and publishing utmost care”?

** Section 4
  Automatically following URIs from "_for-sale" records without user
  consent creates security risks, including exposure to malware,
  phishing pages, and scripted attacks.  Implementations SHOULD NOT
  automatically redirect users when encountering "furi=" content tags.

If automatic redirection from _for-sale record is risky, when should an implementation ignore this concern and automatically redirect the user (since the text says SHOULD NOT vs. MUST NOT)

[Ballot comment]
It would be good to know that the use of unencrypted http has been considered and it would be nice to see a little text relating to these considerations in the Security Considerations section. (See similar comment by Mike Bishop.)

[Ballot comment]
I'm somewhat surprised to see unencrypted "http" as a RECOMMENDED URI scheme. I would omit it; we should RECOMMEND the use of a mechanism that includes some authentication.

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:

 

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:

   

  with source code available at:

   

  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 . 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:

   

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
  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:

   

  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:

   
   

  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
  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
  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.

IESG/Authors/WG Chairs:

IANA has completed its review of draft-davids-forsalereg-18. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there is a single action which we must complete.

In the Underscored and Globally Scoped DNS Node Names registry in the Domain Name System (DNS) Parameters registry group, a single new registration will be made as follows:

RR Type: TXT
_NODE NAME: _for-sale
Reference: [ RFC-to-be ]

As this document requests a registration in an Expert Review or Specification Required (see RFC 8126) registry, we have initiated the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

We understand that this is the only action required to be completed upon approval of this document.

NOTE: The action requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the action that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2025-12-29):

From: The IESG
To: IETF-Announce
CC: draft-davids-forsalereg@ietf.org, jabley@strandkip.nl, mohamed.boucadair@orange.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (The "_for-sale" Underscored and Globally Scoped DNS Node Name) to Informational RFC


The IESG has received a request from an individual submitter to consider the
following document: - 'The "_for-sale" Underscored and Globally Scoped DNS
Node Name'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2025-12-29. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document defines an operational convention that uses the
  reserved underscored DNS leaf node name "_for-sale" to indicate that
  the parent domain name is available for purchase.  The convention can
  be deployed without disrupting existing operations, and it may be
  applied even when the domain name is still actively in use.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-davids-forsalereg/



No IPR declarations have been submitted directly on this I-D.

Document Shepherd Writeup
draft-davids-forsalereg-17

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:

 

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:

   

  with source code available at:

   

  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 . 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:

   

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
  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:

   

  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:

   
   

  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.

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
  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
  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.

IPR poll reply from Marco:

> -----Message d'origine-----
> De : Marco Davids (SIDN)
> Envoyé : lundi 24 novembre 2025 15:47
> À : BOUCADAIR Mohamed INNOV/NET
> Cc : Joe Abley
> Objet : Re: Writeup & IPR Check for draft-davids-forsalereg-16
>
> Med,
>
> On Mon, 24 Nov 2025 12:36:28 +0000 mohamed.boucadair@orange.com
> wrote:
>
> > @Marco: Can you please reply to this message indicating whether
> you are aware of any IPR related to this document?
>
> I hereby declare that I am not aware of any related IPR.
>
> --
> Marco

# Document Shepherd Write-Up for Individual Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Was the document considered in any WG, and if so, why was it not adopted as a
  work item there?

2. Was there controversy about particular points that caused the WG to not adopt
  the document?

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.)

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][3] recommends) or elsewhere
  (where)?

## 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.

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.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] 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][5]?

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.

## 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?

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? 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.

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.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

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?

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.

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][11]).

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.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

understand that when this document is sent to us for processing, we will perform two registry actions.

First, if the designated experts approve (this review is pending), we'll add the following to the Underscored and Globally Scoped DNS Node Names registry at

https://www.iana.org/assignments/dns-parameters

RR Type _NODE NAME Reference
TXT _for-sale RFC XXXX

Second, we'll create the following registry in that same registry group, at that URL:

"_for-sale" Underscored and Globally Scoped DNS Node Name
Registration Procedure: RFC Required
Reference:RFC XXXX

Tag Name Reference Status Description
fcod RFC XXXX active For Sale Proprietary Code
ftxt RFC XXXX active For Sale Free Format Text
furi RFC XXXX active For Sale URI
fval RFC XXXX active For Sale Asking Price

IESG: please note invitation in IANA considerations below.

draft-davids-forsalereg-15has been presented to the ISE for
publication as an Informational RFC on the Independent Stream.

==Purpose==

This document defines an operational convention that uses the
reserved underscored DNS leaf node name "_for-sale" to indicate that
the parent domain name is available for purchase.

== History==

This draft was first presented to the in April of 2025 to the
independent submissions editor, who referred the author to the
dnsop working group... twice.

==Non-IETF Work==

This work has been developed in the context of SIDN Labs.

==Security Considerations==

See Section 6 of the draft.

==IANA==

This memo makes a request of IANA to assign _for-sale in the
Underscored and Globally Scoped DNS Node Names, in accordance
with RFC 8552.

It also creates a subregistry for the content of the TXT record
in accordance with RFC 8726.  That memo invites the IESG to review
the subregistry's creation.

==Reviews==

This memo received reviews from James Gannon, who suggested that
the work be brought to dnsop (and it was).  John Levine described
it as "mostly harmless", but stated that it required a lot of
work.  At least some of that work has happened based on John's
more detailed review.