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 |