Hi John,
At 08:46 AM 08-10-2024, John C Klensin wrote:
I bear full responsibility for that sentence -- don't blame Asmus.
The sentence became controversial in the IESG review after the prior
Last Call and is, I believe, factually correct. I have thought about
less forceful (more wimpy?) language but the underlying issue goes
back to language of BCP 14.
Wimpy text does not make any difference. Spelling things out clearly
could make a difference. I'll leave it to you to choose.
I can't explain without going off-topic but, because this came up the
last time, maybe it is worth doing so. In most standards bodies (and
with other makers of rules), the language is, more or less, "do it
this way or you do not conform", i.e., you violate the specification.
In BCP 14-speak, that is the "absolute requirement" described as
"MUST do this" or "MUST NOT do that". But SHOULD is unusual and is
far more fuzzy with "may exist valid reasons in particular
circumstances to ignore ..., but the full implications must be
understood and carefully weighed before choosing a different course".
We have never required that a specification supplement "SHOULD do X"
with a discussion of what the circumstances might be that would
justify not doing that, nor that they include an "if you are going to
ignore that, you SHOULD (or MUST) do Y. There are many reasons for
not requiring such an explanation but we have never prohibited it (or
either part of it) either. Now, suppose a document says "you SHOULD
do X but, if you conclude that circumstances require that you don't,
best do Y" (or even "...don't, you MUST do Y" or "...don't, you
SHOULD do Y"). That is the situation to which the sentence partially
quoted above refers and it is true: we rarely give such advice, but
it is certainly not unprecedented.
Now, I (and several others with whom it was discussed in 2017- 2019)
decided a forceful word was needed, and I therefore selected
"violate". Maybe I've mellowed or gotten jaded during the last five
years but, if there is agreement that section of the document is
problematic with "violate" but would be ok with "disregard",
"ignore", or some other term, then let's agree on which term, change
the word in the I-D, and move on. And, maybe, if BCP 14 is ever
updated again, we should have a discussion of whether a specification
that uses SHOULD ought to provide an explanation of conditions for
violating (sic) a SHOULD and/or what should be done instead if those
conditions and alternatives are known.
Thanks for explaining the above.
I would have stated that differently, starting with replacing
"likely" with "SHOULD be" and some words about appropriate context,
but yes.
Ok.
Let me say that differently and hope we agree. If the core policy
for the domain is to serve a community, or set of communities, that
are homogeneous with regard to a relatively small number of languages
or scripts, then tuning requirements to reflect those languages,
scripts, and local usage (and any possible interactions among them
including homograph issues) is appropriate. The necessary specific
knowledge should fall with the range of knowledge readily available
to the policy makers and policy development should be fairly easy.
On the other hand, if the core policy for the domain is, e.g., to
register as many names as possible for whatever reason -- even to
accommodate an extremely diverse collection of registrants and names
whether the reasons for that are economic or not (although I can't
think of other compelling reasons) -- then the implications of
registering names without regard to global language or script issues
should at least be understood.
To prohibit such decisions or to declare that the risks and tradeoffs
be evaluated in one particular way, lies outside the IETF's scope.
If we pushed that boundary, we would rapidly find ourselves in the
space between "voluntary standards" and frequent appeals to the
Protocol Police. However, it seems reasonable and appropriate for
us to say something equivalent to "down that path lie dragons and you
SHOULD understand the possible consequences of your decisions" and to
do so as explanation and general guidance, not by altering the core
IDNA2008 specifications or their application.
Ok.
I don't understand what you are suggesting. The policies themselves
fall under ICANN's umbrella (at least for the root, maybe for the
second level (or first level below a "public domain"), less further
down in the tree. Beyond "know what you are doing and what problems
it might lead into", avoiding the assumption that allowing any string
to be registered that conforms narrowly to the IDNA2008 specs is
appropriate for registration, and suggesting that, if the registry
for a particular zone has made decisions that preempt actually
knowing what it is doing, that it is appropriate and desirable to
look elsewhere for at least partial guidance is what this document is
all about.
There is the following text in the fifth paragraph of Section 4:
"In such situations, restrictions are unlikely to be applied
unless they meet
at least one of two criteria:
(i) they are easy to apply and can be applied algorithmically
or otherwise
automatically and/or
(ii) there is clear evidence that the particular label would cause harm.
The first bullet can be implemented. In practice, that is what the
software does. The second bullet gets us into a discussion of how to
read "cause harm". Are there cases where a particular label caused a
security issue? If so, would it help the reader if there is a
reference to one or more of those cases?
Again, suggestions about how to make any of that more clear would be
welcome.
Thanks for being open to suggestions.
Regards,
S. Moonesamy
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
