Hi John,
At 12:44 PM 09-03-2025, John C Klensin wrote:
What does this show? Given a sample of registries that is both very
small (two) and chosen by looking at two comments about particular
registries, perhaps nothing. On the other hand, AFAICT, both
registries are being thoughtful and at least reasonably conservative
about the names they allow, making them in conformance with IDNA2008,
the requirement there that registries do that, and the clarifications
and requirements of the current I-D.
I did the following:
$ curl https://data.iana.org/TLD/tlds-alpha-by-domain.txt | wc -l
There were 1443 top-level domains as at 9 March 2025. There are less
registries as some of then may operate more than one top-level
domain. The sample is quite small, as you mentioned about. However,
Last Call comments are generally useful feedback.
It is not hard to identify registries that don't apply similar (or
any) standard of care, with an extreme example being one ccTLD
registry that allows (and actively promoted at one time and probably
still does) registration of labels containing code points not allowed
by IDNA2008. What, if anything, to do about that is an ICANN problem
and ICANN is still discussing what, if anything, should be done about
it seven years after the problem was clear. Again, not an IETF
problem without a direct line to the Protocol Police, but it seems to
be that we are required to be clear about what our standards do and
do not allow. In the latter context, the base IDNA2008 specs require
that registries (again, for zones at any level) apply a standard of
care that goes beyond the code point classifications and rules of
those specs. In that regard, all the current I-D does it to repeat
that, try to give examples of why it is important, and provide some
pointers if a registry concludes that some range of labels should be
acceptable in spite of their not having detailed knowledge of the
scripts or languages involved... pointing out, as IDNA2008 does, that
the optimal solution for most registries and high-quality identifiers
is to have precisely that knowledge and conservatively prohibit
everything else, but that they might have other considerations for
optimality.
It would be hard, from an economic perspective, to justify the cost
of having people who are proficient in the entire range of scripts or
languages involved. A registry would either have to find a middle
ground or take a conservative approach. Both options are generally
driven by economic factors.
As I implied above, I've now got some new ideas as to how to rewrite
parts of the document to possibly be more clear about the above and
possibly be less easily interpreted as criticizing, e.g., registry
business models. I don't know whether I/we should try that or not.
When this document came out of Last Call and IESG review in 2019,
there was, IIR, one DISCUSS comment that caused the IESG to send it
back asking for a new draft. In the time between then and sometime
in 2024, efforts to actually discuss the issue with the AD
responsible for the DISCUSS always failed for reasons that had
nothing to do with the content of the document (AFAICT, low priority
or just non-response). AFAICT, the two specific issues addressed by
that DISCUSS have long since been resolved; again AFAICT, nothing
came up in this IETF LC or IESG review that was equivalent to them.
So now we have a new set of reviews and comments, some of which
question, not the content of this document but the fundamental
strategy/methods of IDNA2008. Interestingly, questions were raised
in 2019 about the absence of one specific reference and about whether
the draft's claims that its suggestions had a long history. The
reference was added and the discussion of the history expanded, only
to have comments this time that suggest removing the reference and
most or all of the history (as well as raising new complaints).
There are probably other explanations, but those particular issues
are strongly suggestive of being run around in circles.
I read the 2019 "discuss". The Area Director who filed is no longer
an Area Director. I could not find the follow-up discussion. If I
recall correctly, there were two other Area Directors who stepped in
sequentially since then. This is where an author has to start over again.
It seems to me as author that there are three possible ways to
interpret the current situation. One is that things have changed,
that a serious discussion is possible within a reasonable amount of
time, and that the document will then move forward. The second is
that the document will be approved only if it is completely stripped
of key content. Comments that appear to be requests (or demands) to
remove the history, remove all of Section 4, and probably just leave
the errata fixes in Section 5 are in that category. So are comments
that would involve relitigating parts of the IDNA2008 documents.
And the third possibility is that the IESG just doesn't like the idea
of this document and that any attempt to reconcile the DISCUSSes and
generate a corresponding document will just result in a repeat: no
way to get a serious discussion, long delays, changes of ADs and
roles, and, if a new document is generated, there would be a new Last
Call and new demands to remove material that was added as the result
of the previous round of discussions.
Well, another Last Call would be like having a magic spell cast over
the document. Someone would have to figure out how to break that magic spell.
If either of the last two interpretations actually describes the
situation, then trying to move forward with the document -- even
getting further comments about it from you or others -- is a waste of
time. If those are the case, if we should be working on anything at
all in the IDNA space, perhaps it is deprecating IDNA2008 entirely or
at least removing some of its key requirements. I don't know how to
answer the question about moving forward without an answer from the
IESG that will start being seated in about a week and I don't even
know how to get that answer then. I am sure from the various Last
Call reviews that there are people in the community who would be
pleased if this I-D were dropped (or at least completely gutted) but
I don't know how much of this IESG, much less the next one, are
alighted with that position.
The options are to go through the IESG evaluation as that is the
usual path after a Last Call or send a request to drop the processing
of the document. There are some statements in RFC 4690 which might
be of use for Option 1.
Regards,
S. Moonesamy
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
