y stems from the very loud "We are freezing the 6761 process
indefinitely" announcement. I doubt anyone outside of the existing IEFT
community would be willing to spend time working on a 6761-dependent
draft without knowing whether it will even exist in future.
Cheers,
str4d
signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
users accept the
update), but we have zero control over all the client software that has
been written over the last decade that expects to see a .i2p address. At
this point, switching .tld is not an option, which leaves us blocked in
the same position as Tor was regarding non-self-signed SSL certifi
nt of onion
routing called garlic routing! But we are already in the 6761 process
for .I2P, and have absolutely no desire to take garlic any further than
a technical metaphor :)
str4d
signature.asc
Description: OpenPGP digital signature
__
required very little work, was compatible with anything that supported
HTTP proxies, and was functional for users immediately?
I believe that without the backing of a major business or organization
it would not happen now, and it certainly would never have happened
back then.
I
paragraph 3 - The example uses .onion, it should be changed
to .i2p in this document.
> https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-e
xit/
Section
>
5, paragraph 3 - The example uses .onion, it should be changed
to .exit in this document.
str4d
>
> We woul
til an SHA-1 preimage is
found, but even that would only allow a malicious adversary to fake
their own copy of the repository, not alter anyone else's).
str4d
>
> Which means that the real question is whether the references need
> to be understood to understand the registration. T
to handle
legacy applications, like Tor/I2P/GNUnet do now.
str4d
Best regards,
A
-BEGIN PGP SIGNATURE-
iQIcBAEBCgAGBQJVk371AAoJEBO17ljAn7PgmpgP/RXlwq9LVkKCkY8Ldk/QMo2z
zFc2P1E7mO2JmNrkt4d77l+mzWNz3Ne0LMRen5mnJMvl+LitsF62kM3DJ+J9P0EZ
9MFt+WkpkYa+Jz1pMvTaR18Z5uZg8MAJB/qui
the top of any related
search query. It wouldn't take much work, and the IETF's / working
group's sphere of influence would be far wider as a result. Developers
love bullet points :P
str4d
[0]
https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-nam
es/
[1] https://geti2p.net/en
handles domain
names in the same way as upstream Firefox does.
str4d
___ DNSOP mailing list
DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
-BEGIN PGP SIGNATURE-
iQIcBAEBCgAGBQJVVS8SAAoJEBO17ljAn7PgLvcP/3HPo38zZNGsQ1Hl+fbhOq0S
of the I2P community both at
the Interim meeting and in later mailing list communication
(str4d).
You are right in saying that .TLD.alt is preferable to .TLD.invalid
from a user's perspective. But that does not automatically imply that
.TLD.alt is preferable to .TLD.
What I said was, if I were
on a detailed agenda but the initial plan is to
attempt to address both specific drafts and some of the
larger-scale issues we’re seeing around the administration of the
special-use domain names registry.
Sounds good. I look forward to seeing these issues nailed down.
str4d
thanks Tim/Suzanne
11 matches
Mail list logo
