Dear colleagues,
I have reviewed the current version of this document and the discussion up to the date this note was sent.
First, let me thank the shepherd for the write-up, which contains the follow rather blunt text:
This document has not been formally reviewed on any IETF list, including on the i18ndir list, though a few key directorate participants have read and commented on the document. The document was mentioned on the idna-update list, and some comments came from there. That said, this is a document regarding recommendations to the registry and registrar community that could only be developed by experts on IDNA, of which the IETF has very few. A 4-week IETF-wide Last Call (as required for individual submissions) is more than enough time for the i18ndir list to remind experts to take a final look and confirm that there is community consensus, insofar as that ever exists for these kinds of documents.
While this is clear on the issues with soliciting I18ndir review, I am not sure I understand what review was solicited from the registry communities. Was outreach made by the authors or the IESG to the ccNSO, GNSO, or ICANN more broadly?
If that has not been done, then I suggest doing so before progressing the document (e.g. via a liaison statement or set of liaison statements). That is the community that will need to implement this advice, and their review of whether or not the document is comprehensible and useful seems like a prerequisite to publication. They will need to parse sections 3 and 4, and requests for clarification in the text would be much better handled before the publication of the RFC than after.
regards,
Ted Hardie
On Mon, Oct 7, 2024 at 5:58 PM The IESG <iesg-secretary@xxxxxxxx> wrote:
The IESG has received a request from an individual submitter to consider the
following document: - 'Internationalized Domain Names in Applications (IDNA):
Registry
Restrictions and Recommendations'
<draft-klensin-idna-rfc5891bis-07.txt> as Proposed Standard
This is a revision to a document that previously went through Last Call in
2019, but stalled in IESG Evaluation specifically with respect to the content
of Section 4. This new revision modernizes significant portions of the text,
and is now being returned to the community to verify continued consensus and
then progress toward publication.
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@xxxxxxxx mailing lists by 2024-10-21. Exceptionally, comments may
be sent to iesg@xxxxxxxx instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.
Abstract
The IDNA specifications for internationalized domain names combine
rules that determine the labels that are allowed in the DNS without
violating the protocol itself and an assignment of responsibility,
consistent with earlier specifications, for determining the labels
that are allowed in particular zones. Conformance to IDNA by
registries and other implementations requires both parts. Experience
strongly suggests that the language describing those responsibilities
was insufficiently clear to promote safe and interoperable use of the
specifications and that more details and discussion of circumstances
would have been helpful. Without making any substantive changes to
IDNA, this specification updates two of the core IDNA documents (RFCs
5890 and 5891) and the IDNA explanatory document (RFC 5894) to
provide that guidance and to correct some technical errors in the
descriptions.
The file can be obtained via
https://datatracker.ietf.org/doc/draft-klensin-idna-rfc5891bis/
No IPR declarations have been submitted directly on this I-D.
The document contains these normative downward references.
See RFC 3967 for additional information:
rfc1591: Domain Name System Structure and Delegation (Informational - Legacy stream)
_______________________________________________
IETF-Announce mailing list -- ietf-announce@xxxxxxxx
To unsubscribe send an email to ietf-announce-leave@xxxxxxxx
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
