A re-ordering of the previous message happens here: On 7/9/15, 13:45, "DNSOP on behalf of hellekin" <[email protected] on behalf of [email protected]> wrote:
> *** Should IETF use social media to expand their reach? (@ietf?
>@dnsopwg?)
Oddly enough, ICANN does this, an in fact the ICANN staff includes a
Communications Team whose job is to engage as many peoples as possible
(and my peoples I an stretching that beyond cultures to, umm,
classifications like government workers, etc., i.e., non-cultural
divides). This is also why ICANN makes a point of holding meetings and
events in places where the IETF is reluctant to go.
There's a double point here. One, yes, this is a necessary component that
the IETF has not taken on as a role. And two, the IETF doesn't employ a
communications team trained and equipped to do this. I'm not saying the
IETF is deficient, I mean "it is what it is."
>So, to summarize, when considering Special-Use Domain Names candidates*,
>I'm for:
>- - rejecting based on current use in DNS (to avoid name conflicts)
>- - rejecting based on proximity of an existing name when it can lead to
> confusion and pose a security risk
>- - recommending rejection when the word is threatening or contrary to
> cooperative and humanistic values (e.g., UNDHR)
>- - suggesting rejection when the word can be considered offensive
>
>* I guess IANA could tell better about how that fits their own process
>for TLDs.
The first I don't completely understand, if it's in the DNS, then the ship
has sailed. I'm missing that point.
The other categories are fine. It's the implementation that has me
concerned.
In another thread, you'd asked about " [less] ambiguous and simpler" (I
inserted less because I think you meant to include that) in a critique
about RFC 6761. You'd also mentioned that, and I can't find the quote so
forgive me for paraphrasing your thought, that it wasn't what RFC 6761
asked that was a problem, it was the answers submitted - with the problem
being "ambiguity."
Unless I have mis-paraphrased you, and recognizing John Levine's comment
that the IETF is better at technology than processes, RFC 6761('s
potential replacement) could do with a lot more determinism. RFC 6761 has
it's heart in the right direction, recognizing there's a difference
between impacts on code paths in applications, in DNS servers, DNS
resolution, and registration activity. (I don't get the first item on
6761's list, do humans know the name to be special, but that's another
matter unimportant here.) What RFC 6761 doesn't do well enough is give
any guidance of how to evaluate the responses.
There are only 6 sets of successful justifications in the registry
representing, if I counted right, 31 domain names, in 9 TLDs [net has
example.net], representing just 5 TLDs [local]. Looking the Users:
responses, all are "free to use" with the exception of the justification
of example as meaning "only for documentation." (Most documentation of
DNS configurations comes from running it through a server, so...I mention
to this to mean I really don't get the "Users:" consideration section of
the RFC 6761 application.)
Throw in that 5 of the successful justifications are in the same RFC that
defines the registry, the 6th is in the next (numerical) RFC and by the
same authors. Section 5 does give guidance on what to put in the
justifications but there's no guidance of what is important or necessary
to gain approval. That's not a lot to go on, given that there aren't many
criteria listed anywhere. And that there's no expectation that the review
of the application will be taken on by outside-the-IETF interested parties.
The IETF often uses refers to deciding something with the appropriate
expertise involved. By that metric, I see the process described in RFC
6761 not being sufficient, it doesn't ensure that the appropriate experts
are involved. Yes, the IETF has expertise when it comes to whether a name
is special in engineering - and I think that is missing from RFC 6761 -
especially having deterministic criteria defined. One thing I'll mention
in the sense of being "blue sky" - there are IAB liaisons to ICANN board
that could be a means for coordination, perhaps there is a way for an
"expert review" to happen.
BTW, stumbled across in preparing this message, perhaps of interest:
https://datatracker.ietf.org/liaison/1351/
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA512
>
>On 07/08/2015 02:33 PM, Edward Lewis wrote:
>>
>> But I keep coming to this, decidedly non-engineering, question: What
>> if someone uses RFC 6761 to get an offensive name registered as a
>> special-use domain name?
>>
>
>TL;DR: you cannot avoid subjectivity, you have to embrace it.
>
>Your entire post is very interesting and thoughtful, Edward, but I
>wanted to follow-up on my response to Suzanne and focus on your mention
>of subjectivity and engineering.
>
>There's no way we cut subjectivity out of the process, because decisions
>are made by humans, on objective criteria (e.g., my previous response:
>"registered or not"), and on subjective criteria (e.g., your examples of
>visual similarity, offensiveness, and more generally meaning--in the
>previous conversations regarding P2PNames usability issues came up
>between, e.g., .onion, and .onion.alt)
>
>When "domain" names are meant to be used primarily by humans, coming
>from various backgrounds, cultures, languages, avoiding offensiveness
>certainly is an impossible challenge to meet--if the dirty word does not
>exist in a language you know, it might still make people smile or frown
>in another culture. It's mostly a matter of perspective, and that is
>irreducibly subjective.
>
>I think it's quite important indeed to keep in mind that humans will
>judge whether an application is valid or not, and no, that's probably
>not an engineering question. But it can be established that
>applications matching a visually-similar, confusing, or otherwise
>threatening name can be rejected on security considerations; similarly,
>a name obviously offensive to humanity, life, or the values promoted by
>the Internet culture of planetary cooperation should be discouraged.
>
>This is certainly a mind-blowing perspective to an engineer, and a
>seemingly intractable issue to put skin on dead cold technology, but in
>the end humans create, and humans decide what technology should do or
>not. In order to avoid the inevitable conflict of the limits of
>morality and ethics (e.g., who decides that .fsck is not available),
>this ultimate consideration should be left to the community, and not to
>arbitrary rules: if it's easy to find an objection to an illustrative
>.con special-use wannabe for its (English) meaning and its proximity to
>.com, it's less easy to grasp its dirty meaning in French; this example
>could certainly be rejected on the ground that it may confuse users
>(especially as typing n instead of m on many keyboards is an easy
>mistake) and pose a security risk; but rejecting it, or another similar
>example, on the grounds it can be taken as an insult or refer to usually
>intimate parts of someone is a cultural and moral call that should not
>be written but tacit.
>
>So, to summarize, when considering Special-Use Domain Names candidates*,
>I'm for:
>
>- - rejecting based on current use in DNS (to avoid name conflicts)
>- - rejecting based on proximity of an existing name when it can lead to
> confusion and pose a security risk
>- - recommending rejection when the word is threatening or contrary to
> cooperative and humanistic values (e.g., UNDHR)
>- - suggesting rejection when the word can be considered offensive
>
>* I guess IANA could tell better about how that fits their own process
>for TLDs.
>
>>
>> Last calls are only heard by those that are subscribed to the lists.
>>
>*** Should IETF use social media to expand their reach? (@ietf? @dnsopwg
>?)
>
>==
>hk
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v2
>
>iQJ8BAEBCgBmBQJVnrMyXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
>ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
>ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9JokP/jIYL2mtSgh2UPx5mogX+f9H
>HR55z/bzX81pB1RUXyTXXRghVHHCmIPz+luKBkeA9+USAuQ/h3qQsrTpLtWHTo18
>PgPl0nsG90IUDVtlx9Q0tIPR1zYtLIsLLEpqCY+GKdp7y7llAHhh7ASJkpC1nOSl
>DXiPjG3TX2WLGglfLd8o9bDbm2DF/CEAOmalFZjh+FsOuKaT6m07CtdFsdasIeAN
>f/qie61Hzny36kDxmTWmhhXW9we/B6PURScAEcpusukJXlT3ViBeozgVQCnvSr2L
>mfHvFAmWY32yk6Oe8Ss5fN8D6r1hlSlkiatofzPY/A659T/fUBAIVuA7luA17lQI
>jD9hH6mm0W0djJKLjRnKzmcM6/37kH7sdrX1vei13jovwc6IwjFptiTu31s8QUwV
>Tm9v6E3xm4pJJlwJ03BKCLQg8vpJbrllS/U/E3mRpsip02hljvmem6fRZJolu3LG
>Vw8Ocs7nN20ibiZt1iepPJXYfW3wMGFR8QBNoI4BMjSWJcuqIefMx4N9+Eute9jQ
>Jnb0iTRT1xCV8B/dr/OoXB4mJVtiu/zbAOHlTn/wqFVr4ZZYTdeRvgCgmXkXql3a
>o8LhHL98zzC9OkyKloNiRLI7QeMHCyHDamp0vvD3OwOX7yJK16s1LFwJk0DglzOI
>oEw/EV2ELKtxfleyZXek
>=R5oG
>-----END PGP SIGNATURE-----
>
>_______________________________________________
>DNSOP mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/dnsop
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
