Skip to main content

The .alt Special-Use Top-Level Domain
draft-ietf-dnsop-alt-tld-25

Revision differences

Document history

Date Rev. By Action
2023-09-14
25 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2023-09-11
25 (System) RFC Editor state changed to AUTH48
2023-06-26
25 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2023-05-11
25 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2023-05-11
25 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2023-05-11
25 (System) IANA Action state changed to In Progress from Waiting on Authors
2023-05-10
25 (System) IANA Action state changed to Waiting on Authors from In Progress
2023-05-08
25 (System) RFC Editor state changed to EDIT
2023-05-08
25 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2023-05-08
25 (System) Announcement was received by RFC Editor
2023-05-08
25 (System) IANA Action state changed to In Progress
2023-05-08
25 Amy Vezza Downref to RFC 8244 approved by Last Call for draft-ietf-dnsop-alt-tld-25
2023-05-08
25 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2023-05-08
25 Amy Vezza IESG has approved the document
2023-05-08
25 Amy Vezza Closed "Approve" ballot
2023-05-06
25 Robert Wilton IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup
2023-05-06
25 Robert Wilton Ballot approval text was generated
2023-05-04
25 Paul Hoffman New version available: draft-ietf-dnsop-alt-tld-25.txt
2023-05-04
25 Paul Hoffman New version accepted (logged-in submitter: Paul Hoffman)
2023-05-04
25 Paul Hoffman Uploaded new revision
2023-05-01
24 (System) Removed all action holders (IESG state changed)
2023-05-01
24 (System) Sub state has been changed to AD Followup from Revised I-D Needed
2023-05-01
24 Paul Hoffman New version available: draft-ietf-dnsop-alt-tld-24.txt
2023-05-01
24 Paul Hoffman New version accepted (logged-in submitter: Paul Hoffman)
2023-05-01
24 Paul Hoffman Uploaded new revision
2023-04-27
23 (System) Changed action holders to Warren Kumari, Paul Hoffman (IESG state changed)
2023-04-27
23 Cindy Morgan IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation
2023-04-27
23 Andrew Alston [Ballot Position Update] New position, No Objection, has been recorded for Andrew Alston
2023-04-26
23 Zaheduzzaman Sarker [Ballot comment]
Thanks for working on this document.
2023-04-26
23 Zaheduzzaman Sarker [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker
2023-04-26
23 John Scudder
[Ballot comment]
One comment -- Section 3.2 has "DNS server operators MAY be aware that queries for name ending in .alt are not DNS names, …
[Ballot comment]
One comment -- Section 3.2 has "DNS server operators MAY be aware that queries for name ending in .alt are not DNS names, and queries for those names were leaked into the DNS context." The RFC 2119 MAY appears misused in this context.

(Also, in that quote, s/queries for name/queries for names/)
2023-04-26
23 John Scudder [Ballot Position Update] New position, No Objection, has been recorded for John Scudder
2023-04-25
23 Erik Kline [Ballot Position Update] New position, Yes, has been recorded for Erik Kline
2023-04-25
23 Roman Danyliw
[Ballot comment]
Thank you to Linda Dunbar for the SECDIR review.

** Section 2.
  Currently deployed projects and protocols that are using pseudo-TLDs
  …
[Ballot comment]
Thank you to Linda Dunbar for the SECDIR review.

** Section 2.
  Currently deployed projects and protocols that are using pseudo-TLDs
  are recommended to move under the .alt pseudo-TLD, but this is not a
  requirement.

I don’t understand the basis of this recommendation.  Projects and protocols using pseudo-TLDs (outside of https://www.iana.org/domains/reserved) are already not following published guidance.  Why is there an expectation that this document can change behavior?

Section 3.2.  Item #3. Editorial.  s/Writers of name resolution APIs/Creators of name resolution APIs/.  Or “developers”, “implementers, or “designers”

** Section 3.2.  Item #7
  7.  DNS registries/registrars for the global DNS will never register
  names in the .alt pseudo-TLD because .alt will not exist in the
  global DNS root.

Items #4 – 6 on this list use RFC2119 language to make the expected behavior clear.  This text seems to be written in an aspiration form describing what registries/registrars will do, without explicitly prohibiting them with normative language.  Is there a reason for that?
2023-04-25
23 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2023-04-24
23 Vladimír Čunát Request for Telechat review by DNSDIR Completed: Ready. Reviewer: Vladimír Čunát. Sent review to list.
2023-04-24
23 Lars Eggert
[Ballot comment]

# GEN AD review of draft-ietf-dnsop-alt-tld-23

CC @larseggert

Thanks to Behcet Sarikaya for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/1LB6_ujGseyZRWPgTQZrP2pS8zk). …
[Ballot comment]

# GEN AD review of draft-ietf-dnsop-alt-tld-23

CC @larseggert

Thanks to Behcet Sarikaya for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/1LB6_ujGseyZRWPgTQZrP2pS8zk).

## Comments

### DOWNREFs

DOWNREF `[RFC8244]` from this Proposed Standard to Informational `RFC8244`.
(For IESG discussion. It seems this DOWNREF was not mentioned in the Last Call
and also seems to not appear in the DOWNREF registry.)

I think RFC8244 could be cited informatively?

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Grammar/style

#### Section 2, paragraph 7
```
performing aggressive use of DNSSEC- validated caches (described in [RFC8198
                              ^^^^^^^^^^^^^^^^^
```
This word seems to be formatted incorrectly. Consider fixing the spacing or
removing the hyphen completely.

#### Section 2, paragraph 8
```
will cover all names under .alt. Currently deployed projects and protocols t
                                ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Currently".

#### Section 7.1, paragraph 2
```
and P. Hoffman, "DNS Query Name Minimisation to Improve Privacy", RFC 9156,
                                ^^^^^^^^^^^^
```
Do not mix variants of the same word ("minimisation" and "minimization") within
a single text.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool
2023-04-24
23 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert
2023-04-24
23 Jim Guichard [Ballot Position Update] New position, No Objection, has been recorded for Jim Guichard
2023-04-24
23 Éric Vyncke
[Ballot comment]
Thanks to the authors and the DNSOP working group, and of course to Suzanne for a detailed shepherd's write-up.

Important document to bring …
[Ballot comment]
Thanks to the authors and the DNSOP working group, and of course to Suzanne for a detailed shepherd's write-up.

Important document to bring some clarity for some use cases.

Just two minor comments:

1/ I support Paul Wouters' issue with the name "pseudo-TLD", it is both too late and a bike-shedding exercice... "ghost-TLD" or "filler-TLD" or "dummy-TLD" would have been better

2/ in section 2, s/because .alt, by definition, is not a DNS name./because .alt, by this specification, is not a DNS name./ ?

Regards

-éric
2023-04-24
23 Éric Vyncke [Ballot Position Update] New position, Yes, has been recorded for Éric Vyncke
2023-04-23
23 Paul Wouters
[Ballot comment]
Some of my comments might be DISCUSS-worthy (my apologies), but I really don't want to block this document for any further time. But …
[Ballot comment]
Some of my comments might be DISCUSS-worthy (my apologies), but I really don't want to block this document for any further time. But please do take my comments into considerations if you can do a quick ref update.

The term pseudo-TLD as defined here is not how I've seen the term
used. A pseudo TLD as I've seen it used is a TLD that's one step
below a real TLD and runs as a general GTLD (open registration),
eg "uk.com". I guess I would qualify the use in this document
more as "fake TLD", but I can see how that might come over as
even more perogative. So I am fine with the current definition
and use case. Perhaps a "to be confused with" note could
be added, but is not strictly required.


        4. Caching DNS servers SHOULD NOT recognize names in the .alt
        pseudo-TLD as special and SHOULD NOT perform any special handling
        with them.

There is value for a recursor to "pre-load" the proof of non-existence
of ".alt" (the entire branch in the hierarchy) to avoid any potential
leakage of subdomains within alt. It could potentially also reduce error
message logs if someone starts using .alt not as a real hierarchy or using
non-DNS valid characters in their name, eg Ulabel stuff or even binary stuff
like 0x00010001000000003616c7400. They could also just return NXDOMAIN instead
of forwarding the query to the root servers to avoid a privacy leak. Or it
could modify the question foo "foo.alt" and only send "alt" to the root. I
see no reason such additional protection mechanisms need to violate this
"SHOULD NOT" clause. Why not flip the statement around?

        4. Caching DNS servers MAY recognize names in the .alt pseudo-TLD
        as special and MAY perform special privacy preserving methods to
        return (DNSSEC signed) NXDOMAIN answers to prevent leaking entries
        under the .alt pseudo-TLD into the global DNS.

        5. Authoritative DNS servers SHOULD NOT recognize names in the
        .alt pseudo-TLD as special and should not perform any special
        handling with them.

Any reason the second "should not" is lowercase ?
Note that I do agree here, and would even say MUST NOT so that people
can use DNS technology even if not rooted in the global DNS for their
.alt names without having to modify existing DNS software (eg run a
shadow .alt using DNS on port 666 or something)

        6. DNS server operators will treat names in ...

I find the use of "will" here a little odd. Perhaps:

        6. DNS servers and operators, which whave no special handling
          for the .alt pseudo-TLD will end up treating names in ...



        7. DNS registries/registrars for the global DNS will never
        register names in the .alt pseudo-TLD because .alt will not
        exist in the global DNS root

"will never" seems wishful thinking. I've seen some very fraudulent stuff
happen with DNS registries/registrars. eg what if one of them will support
pseudo-TLDs along with real DNS domains, and includes bogus .alt registrations?
Perhaps:

        7. DNS registries/registrars for the global DNS can never legitimately
        register names in the .alt pseudo-TLD because .alt will never exist in
        the global DNS root

Again, my apologies to Warren for not balloting a blanc YES :)
2023-04-23
23 Paul Wouters [Ballot Position Update] New position, Yes, has been recorded for Paul Wouters
2023-04-20
23 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2023-04-18
23 Warren Kumari [Ballot comment]
'm a nauthor...
2023-04-18
23 Warren Kumari [Ballot Position Update] New position, Recuse, has been recorded for Warren Kumari
2023-04-18
23 Jim Reid Request for Telechat review by DNSDIR is assigned to Vladimír Čunát
2023-04-17
23 Cindy Morgan Placed on agenda for telechat - 2023-04-27
2023-04-17
23 Robert Wilton Ballot has been issued
2023-04-17
23 Robert Wilton [Ballot Position Update] New position, Yes, has been recorded for Robert Wilton
2023-04-17
23 Robert Wilton Created "Approve" ballot
2023-04-17
23 Robert Wilton IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2023-04-17
23 Robert Wilton Ballot writeup was changed
2023-04-10
23 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2023-04-10
23 Paul Hoffman New version available: draft-ietf-dnsop-alt-tld-23.txt
2023-04-10
23 Paul Hoffman New version accepted (logged-in submitter: Paul Hoffman)
2023-04-10
23 Paul Hoffman Uploaded new revision
2023-04-10
22 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2023-04-09
22 Niclas Comstedt Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Niclas Comstedt. Sent review to list.
2023-04-06
22 Linda Dunbar Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Linda Dunbar.
2023-04-06
22 Linda Dunbar Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Linda Dunbar. Sent review to list. Submission of review completed at an earlier date.
2023-04-06
22 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2023-04-06
22 David Dong
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-dnsop-alt-tld-22. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-dnsop-alt-tld-22. If any part of this review is inaccurate, please let us know.

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

Consistent with the directions to IANA in RFC6761, IANA will place

alt.

in the Special-Use Domain Names registry located at:

https://www.iana.org/assignments/special-use-domain-names/

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions 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 list of actions 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 Specialist
2023-03-28
22 Behcet Sarikaya Request for Last Call review by GENART Completed: Ready. Reviewer: Behcet Sarikaya. Sent review to list.
2023-03-22
22 Vladimír Čunát Request for Last Call review by DNSDIR Completed: Ready. Reviewer: Vladimír Čunát. Sent review to list.
2023-03-17
22 Jean Mahoney Request for Last Call review by GENART is assigned to Behcet Sarikaya
2023-03-16
22 Tero Kivinen Request for Last Call review by SECDIR is assigned to Linda Dunbar
2023-03-15
22 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Niclas Comstedt
2023-03-14
22 Barry Leiba Request for Last Call review by ARTART Completed: Ready. Reviewer: Barry Leiba. Sent review to list.
2023-03-14
22 Barry Leiba Request for Last Call review by ARTART is assigned to Barry Leiba
2023-03-13
22 Jim Reid Request for Last Call review by DNSDIR is assigned to Vladimír Čunát
2023-03-13
22 Amy Vezza IANA Review state changed to IANA - Review Needed
2023-03-13
22 Amy Vezza
The following Last Call announcement was sent out (ends 2023-04-10):

From: The IESG
To: IETF-Announce
CC: dnsop-chairs@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-alt-tld@ietf.org, rwilton@cisco.com, suzworldwide@gmail.com …
The following Last Call announcement was sent out (ends 2023-04-10):

From: The IESG
To: IETF-Announce
CC: dnsop-chairs@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-alt-tld@ietf.org, rwilton@cisco.com, suzworldwide@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (The ALT Special Use Top Level Domain) to Proposed Standard


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'The ALT Special Use Top Level
Domain'
  as Proposed Standard

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 2023-04-10. 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 reserves a TLD label, "alt" to be used in non-DNS
  contexts.  It also provides advice and guidance to developers
  developing alternative namespaces.

  [ This document is being collaborated on in Github at
  .  The most
  recent version of the document, open issues, etc should all be
  available here.  The authors (gratefully) accept pull requests. ]


The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/


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




2023-03-13
22 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2023-03-13
22 Robert Wilton Note, I've updated the end date to indicate that this should be a 4 week last call.
2023-03-13
22 Robert Wilton Last call was requested
2023-03-13
22 Robert Wilton Ballot approval text was generated
2023-03-13
22 Robert Wilton Ballot writeup was generated
2023-03-13
22 (System) Changed action holders to Robert Wilton (IESG state changed)
2023-03-13
22 Robert Wilton IESG state changed to Last Call Requested from Publication Requested
2023-03-13
22 Robert Wilton Last call announcement was changed
2023-03-13
22 Robert Wilton Last call announcement was generated
2023-03-13
22 Robert Wilton Shepherding AD changed to Robert Wilton
2023-03-03
22 Paul Hoffman New version available: draft-ietf-dnsop-alt-tld-22.txt
2023-03-03
22 Paul Hoffman New version accepted (logged-in submitter: Paul Hoffman)
2023-03-03
22 Paul Hoffman Uploaded new revision
2023-03-03
21 Tim Wicinski
# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the …
# Document Shepherd Write-Up for Group 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. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The WG consensus on the merits of the .alt proposal is reasonably
strong. It deals with a fairly esoteric subject, so many participants
in DNSOP didn't have strong views. No one thinkks it's a perfect
solution to the problem it describes. However, there's consensus that
it's likely to help future protocol designers, potentially including
some in the IETF and some outside.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Yes. Some participants felt it would not be appropriate for the IETF
to consider a proposal that they believed was properly in the remit
of ICANN as maintainer of the public DNS root zone. However, this was
eventually solved by being appropriately restricted about the scope of
the draft and the WG's job. The proposal relates only to protocols
that are not the DNS, but use domain names; and there is a liaison
relationship in place between the IETF and ICANN to handle any needed
clarifications.  The WG was only obligated to consider the proposal on
the merits.

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

N/A; this draft documents an IANA registry entry and some
considerations for DNS operators and protocol designers.

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

This draft closely interacts with the responsibilities of ICANN, and is the subject of a liaison discussion and liaison statement draft.


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.

N/A

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

N/A

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.

N/A

## 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][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A

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?

This document is intended as a Proposed Standard. The reasoning is
that the registry it seeks to update requires Standards Action or IESG
Approval, and Proposed Standard seems more appropriate for a naming
convention intended to be widely adopted, inside or outside the IETF.


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.

Yes. Nothing relevant has been identified, and the authors have been
reminded to disclose any such thing that they know of.

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.

Yes.

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

The draft has been through quite a lot of review, and conforms to the
suggested guidelines. The only idnits warning is a flippant reference
in the changelog.

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

No

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

N/A

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.

No

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?

N/A

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.

No

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

This document allocates one new entry in a single registry,
https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml#special-use-domain. Its
intended status is consistent with that registry's policy, and the
required documentation for a proposed registry entry laid out in RFC
6761
is included.

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.

N/A
2023-03-03
21 Tim Wicinski Responsible AD changed to Warren Kumari
2023-03-03
21 Tim Wicinski IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2023-03-03
21 Tim Wicinski IESG state changed to Publication Requested from I-D Exists
2023-03-03
21 Tim Wicinski Document is now in IESG state Publication Requested
2023-02-28
21 Suzanne Woolf
# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the …
# Document Shepherd Write-Up for Group 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. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The WG consensus on the merits of the .alt proposal is reasonably
strong. It deals with a fairly esoteric subject, so many participants
in DNSOP didn't have strong views. No one thinkks it's a perfect
solution to the problem it describes. However, there's consensus that
it's likely to help future protocol designers, potentially including
some in the IETF and some outside.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Yes. Some participants felt it would not be appropriate for the IETF
to consider a proposal that they believed was properly in the remit
of ICANN as maintainer of the public DNS root zone. However, this was
eventually solved by being appropriately restricted about the scope of
the draft and the WG's job. The proposal relates only to protocols
that are not the DNS, but use domain names; and there is a liaison
relationship in place between the IETF and ICANN to handle any needed
clarifications.  The WG was only obligated to consider the proposal on
the merits.

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

N/A; this draft documents an IANA registry entry and some
considerations for DNS operators and protocol designers.

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

This draft closely interacts with the responsibilities of ICANN, and is the subject of a liaison discussion and liaison statement draft.


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.

N/A

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

N/A

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.

N/A

## 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][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A

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?

This document is intended as a Proposed Standard. The reasoning is
that the registry it seeks to update requires Standards Action or IESG
Approval, and Proposed Standard seems more appropriate for a naming
convention intended to be widely adopted, inside or outside the IETF.


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.

Yes. Nothing relevant has been identified, and the authors have been
reminded to disclose any such thing that they know of.

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.

Yes.

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

The draft has been through quite a lot of review, and conforms to the
suggested guidelines. The only idnits warning is a flippant reference
in the changelog.

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

No

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

N/A

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.

No

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?

N/A

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.

No

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

This document allocates one new entry in a single registry,
https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml#special-use-domain. Its
intended status is consistent with that registry's policy, and the
required documentation for a proposed registry entry laid out in RFC
6761
is included.

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.

N/A
2023-02-24
21 Paul Hoffman New version available: draft-ietf-dnsop-alt-tld-21.txt
2023-02-24
21 Paul Hoffman New version accepted (logged-in submitter: Paul Hoffman)
2023-02-24
21 Paul Hoffman Uploaded new revision
2023-01-31
20 Tim Wicinski IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2023-01-31
20 Paul Hoffman New version available: draft-ietf-dnsop-alt-tld-20.txt
2023-01-31
20 Paul Hoffman New version accepted (logged-in submitter: Paul Hoffman)
2023-01-31
20 Paul Hoffman Uploaded new revision
2023-01-24
19 Tim Wicinski Notification list changed to suzworldwide@gmail.com because the document shepherd was set
2023-01-24
19 Tim Wicinski Document shepherd changed to Suzanne Woolf
2023-01-20
19 Tim Wicinski Changed document external resources from: None to:

github_repo https://github.com/wkumari/draft-wkumari-dnsop-alt-tld
2022-12-13
19 Suzanne Woolf Long WGLC bc of the holidays and probably a difficult consensus call.
2022-12-13
19 Suzanne Woolf IETF WG state changed to In WG Last Call from Held by WG
2022-12-13
19 Paul Hoffman New version available: draft-ietf-dnsop-alt-tld-19.txt
2022-12-13
19 Paul Hoffman New version accepted (logged-in submitter: Paul Hoffman)
2022-12-13
19 Paul Hoffman Uploaded new revision
2022-11-02
18 Benno Overeinder Added to session: IETF-115: dnsop  Tue-0930
2022-10-20
18 Paul Hoffman New version available: draft-ietf-dnsop-alt-tld-18.txt
2022-10-20
18 Paul Hoffman New version accepted (logged-in submitter: Paul Hoffman)
2022-10-20
18 Paul Hoffman Uploaded new revision
2022-08-23
17 Paul Hoffman New version available: draft-ietf-dnsop-alt-tld-17.txt
2022-08-23
17 Paul Hoffman New version accepted (logged-in submitter: Paul Hoffman)
2022-08-23
17 Paul Hoffman Uploaded new revision
2022-08-19
16 Paul Hoffman New version available: draft-ietf-dnsop-alt-tld-16.txt
2022-08-19
16 Warren Kumari New version approved
2022-08-19
16 (System) Request for posting confirmation emailed to previous authors: Warren Kumari , dnsop-chairs@ietf.org
2022-08-19
16 Paul Hoffman Uploaded new revision
2022-06-14
15 Warren Kumari New version available: draft-ietf-dnsop-alt-tld-15.txt
2022-06-14
15 Warren Kumari New version accepted (logged-in submitter: Warren Kumari)
2022-06-14
15 Warren Kumari Uploaded new revision
2022-04-12
14 Tim Wicinski
Test to see how these appear.
2021-12-15
14 Warren Kumari New version available: draft-ietf-dnsop-alt-tld-14.txt
2021-12-15
14 (System) New version accepted (logged-in submitter: Warren Kumari)
2021-12-15
14 Warren Kumari Uploaded new revision
2021-06-21
13 Warren Kumari New version available: draft-ietf-dnsop-alt-tld-13.txt
2021-06-21
13 (System) New version approved
2021-06-21
13 (System) Request for posting confirmation emailed to previous authors: Andrew Sullivan , Warren Kumari
2021-06-21
13 Warren Kumari Uploaded new revision
2020-02-24
12 (System) Document has expired
2019-08-23
12 Warren Kumari New version available: draft-ietf-dnsop-alt-tld-12.txt
2019-08-23
12 (System) New version approved
2019-08-23
12 (System) Request for posting confirmation emailed to previous authors: Warren Kumari , Andrew Sullivan
2019-08-23
12 Warren Kumari Uploaded new revision
2019-07-22
11 (System) Document has expired
2019-01-09
11 Warren Kumari New version available: draft-ietf-dnsop-alt-tld-11.txt
2019-01-09
11 (System) New version approved
2019-01-09
11 (System) Request for posting confirmation emailed to previous authors: Warren Kumari , Andrew Sullivan
2019-01-09
11 Warren Kumari Uploaded new revision
2018-07-17
10 Tim Wicinski IETF WG state changed to Held by WG from In WG Last Call
2018-07-16
10 Warren Kumari New version available: draft-ietf-dnsop-alt-tld-10.txt
2018-07-16
10 (System) New version approved
2018-07-16
10 (System) Request for posting confirmation emailed to previous authors: Warren Kumari , Andrew Sullivan
2018-07-16
10 Warren Kumari Uploaded new revision
2018-01-18
09 Warren Kumari New version available: draft-ietf-dnsop-alt-tld-09.txt
2018-01-18
09 (System) New version approved
2018-01-18
09 (System) Request for posting confirmation emailed to previous authors: Warren Kumari , Andrew Sullivan
2018-01-18
09 Warren Kumari Uploaded new revision
2017-09-04
08 (System) Document has expired
2017-03-16
08 Tim Wicinski Tag Revised I-D Needed - Issue raised by WG cleared.
2017-03-16
08 Tim Wicinski IETF WG state changed to In WG Last Call from WG Document
2017-03-03
08 Suzanne Woolf Changed consensus to Yes from Unknown
2017-03-03
08 Suzanne Woolf Intended Status changed to Proposed Standard from Informational
2017-03-03
08 Warren Kumari New version available: draft-ietf-dnsop-alt-tld-08.txt
2017-03-03
08 (System) New version approved
2017-03-03
08 (System) Request for posting confirmation emailed to previous authors: Warren Kumari , Andrew Sullivan
2017-03-03
08 Warren Kumari Uploaded new revision
2017-02-01
07 Warren Kumari New version available: draft-ietf-dnsop-alt-tld-07.txt
2017-02-01
07 (System) New version approved
2017-02-01
07 (System) Request for posting confirmation emailed to previous authors: "Warren Kumari" , "Andrew Sullivan"
2017-02-01
07 Warren Kumari Uploaded new revision
2017-01-30
06 Suzanne Woolf Formally un-parked for further discussion now that there's a problem statement.
2017-01-30
06 Suzanne Woolf Tag Revised I-D Needed - Issue raised by WG set.
2017-01-30
06 Suzanne Woolf IETF WG state changed to WG Document from Parked WG Document
2016-10-30
06 Warren Kumari New version available: draft-ietf-dnsop-alt-tld-06.txt
2016-10-30
06 (System) New version approved
2016-10-30
06 (System) Request for posting confirmation emailed to previous authors: "Warren Kumari" , "Andrew Sullivan"
2016-10-30
06 Warren Kumari Uploaded new revision
2016-09-12
05 Warren Kumari New version available: draft-ietf-dnsop-alt-tld-05.txt
2016-03-21
04 Warren Kumari New version available: draft-ietf-dnsop-alt-tld-04.txt
2015-11-17
03 Tim Wicinski Waiting for the 6761 design team to sort out the bigger issues before moving this forward.
2015-11-17
03 Tim Wicinski IETF WG state changed to Parked WG Document from WG Document
2015-09-30
03 Warren Kumari New version available: draft-ietf-dnsop-alt-tld-03.txt
2015-09-13
02 Warren Kumari New version available: draft-ietf-dnsop-alt-tld-02.txt
2015-07-03
01 Warren Kumari New version available: draft-ietf-dnsop-alt-tld-01.txt
2015-06-05
00 Tim Wicinski Intended Status changed to Informational from None
2015-06-05
00 Tim Wicinski This document now replaces draft-wkumari-dnsop-alt-tld instead of None
2015-06-05
00 Warren Kumari New version available: draft-ietf-dnsop-alt-tld-00.txt