--On Tuesday, October 8, 2024 11:42 -0700 S Moonesamy
<sm+ietf@xxxxxxxxxxxx> wrote:
> 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.
That stays unless someone has strong feeling to the contrary and,
ideally, a suggestion.
>> 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.
As I said, largely off topic, but maybe a more general issue than the
particular language of this spec.
>...
>> 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?
Actually, examples abound. Most of them are security-related or
involve phishing or other misrepresentation attacks. I don't have
statistics on how many people were actually deceived and burned
versus how many times these things were tried. But the mixed Latin
and Cyrillic script combination that was used in the famous "paypal"
case is an example, as is the \u006F\u0337 versus \u00F8 example used
in some other IETF discussions. There are equally, or more, lurid
examples with other scripts, including the U+08A1 problem that was
part of the delay in producing what became RFC 9233, but they are
less likely to be comprehensible to typical RFC readers. _Any_
situation in which two labels that can occur in the same domain and
be easily confused with each other has potential for harm, especially
if the harm is intentional. That even includes all-ASCII cases like
the notorious g00gle.com.
But, is there a well-documented case where, e.g., a user fell into
one of those traps, was defrauded, and then sued the registry or
registrar for allowing the registration? I have no idea and am
fairly sure we wouldn't find it if it had happened. So it is not
clear to me how to make the document better in that area.
>> Again, suggestions about how to make any of that more clear would
>> be welcome.
>
> Thanks for being open to suggestions.
You are welcome but I think that should be much more the norm in the
IETF.
john
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
