Re: [DNSOP] [Ext] Re: Ed's comment s on Re: WGLC for draft-ietf-dnsop-sutld-ps
On 02/17/2017 06:48 AM, Edward Lewis wrote:
> On 2/16/17, 12:23, "Suzanne Woolf" <suzworldw...@gmail.com> wrote:
> On Feb 16, 2017, at 11:46 AM, Russ Housley <hous...@vigilsec.com> wrote:
> Ed:
>>>> It would be good to provide a list of requests for new special use names.
>>>> Especially for a problem statement, this provides a way to estimate the
>>>> "size and shape" of the problem and the urgency.
> (Russ:)
>>> No matter how you count, the volume will remain small if this is done
>>> properly. However, the special name requests can still be
>>> important and urgent.
> (Suzanne:)
>> I also note it’s fairly difficult to estimate.
>>
>> ... .home/.corp/.mail ... .onion ... .alt ... .homenet
>
> There is also a use of .id by Blockstack? as opposed to the ccTLD for
> Indonesia. (This one just jumps to mind.)
>
> I did some looking and despite thinking there was once a backlog of a dozen,
> I haven't come across it in the mailing list. (I could be wrong.) What
> about .belkin, often cited as a string seen but not allocated?
You missed the ones that started all the drama ;P
- .gnu
- .zkey
- .exit
- .i2p
- .bit
>
> My goal is to see the problem statement document get more detailed so we can
> know when we've solved the problem. ("The problem" is meant to be general,
> not necessarily the problem at hand.)
>
>> All of the drafts besides those for .onion, .alt, and .homenet have expired,
>> which tells us nothing about whether or how they might come back.
>
> I don't think liveness of drafts is a sufficient measure of activity,
> considering the problem statement talks about uses from folks not engaging in
> the IETF process. (If I'm hungry and in line at a restaurant, then walk away
> because the wait is too long, I'm still hungry.)
+1. I have a vested interest in the outcome of this discussion (being
involved in a relevant project), and offered to participate in the
problem statement design process. But with the significant general
headwind around the former, and never hearing back about the latter, I
decided my time was better spent on other things.
Also note that for at least some of these drafts, their inactivity and
expiry likely 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
Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01
On 02/04/16 08:53, George Michaelson wrote: > Whats your reaction going to be, to a closed 6761 because if you come > to the microphone with a "but we built to the userbase, we have > millions" and make bambi eyes, I feel a bit like saying "you were > warned" When and where? In this discussion? As has been stated long ago in this discussion, I2P has been using .i2p since 2005 (long before my time), for exactly the same reasons as Tor used .onion. Using the current discussion as an attempt to retroactively alter how the IETF has done outreach regarding TLDs in the past is disingenuous. > > ie, squatting a domain, is squatting a domain, no matter how much you > believe in your own process. If you populate code to the label, a > specific label, you're in moral hazard. As I have also stated long ago in this discussion, I did in fact look into an alternate avenue which would be a much better technical fit: defining an AF_I2P. I could find *no way* to achieve this without requiring patches to the kernels of every OS that we wanted to release on. So given the choice between "impossible or indefinitely-blocked solution" and "solution that works", is it surprising that the Tor and I2P developers went the way they did? > > You cannot predict what label (if any) you will get. You need to code > agile, to a label being in another space (eg .alt) which is also > unknown. it has to be in a .conf or other runtime option, not hard > coded. If that's the case, why can't everyone using .home or .mail or .corp also switch? Answer: legacy software. We have tens of thousands of I2P routers out there, in use right now. We do have some level of control over *some* of them via updates (but only if the 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 certificates. str4d > > forever. > > -G > > On Fri, Apr 1, 2016 at 7:40 AM, str4d <st...@i2pmail.org> wrote: >> On 29/03/16 07:53, John Levine wrote: >>> Finally, no matter what we do, at some point someone will come by with >>> .GARLIC which is like .ONION but stronger and they will say (with some >>> justification) that it's used by a zillion people around the world. >>> "You should have used GARLIC.ALT." "Yeah, I guess so, but we didn't, >>> sorry." Then we'll have to deal with it one way or the other. I hope >>> that .alt will push that day off farther into the future but it's >>> unlikely to push it to infinity. >> >> Injecting a little levity: I2P does in fact use a variant 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 >> >> >> ___ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> > signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01
On 29/03/16 07:53, John Levine wrote: > Finally, no matter what we do, at some point someone will come by with > .GARLIC which is like .ONION but stronger and they will say (with some > justification) that it's used by a zillion people around the world. > "You should have used GARLIC.ALT." "Yeah, I guess so, but we didn't, > sorry." Then we'll have to deal with it one way or the other. I hope > that .alt will push that day off farther into the future but it's > unlikely to push it to infinity. Injecting a little levity: I2P does in fact use a variant 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Some thoughts on special-use names, from an application standpoint
ed Java process? And when the alternative was to simply use an HTTP proxy that listens for .i2p addresses, which 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. If I am wrong, and it *is* possible to define a 'struct sockaddr_i2p' with *less* work, I eagerly look forward to you explaining how :) str4d -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJWW1ibAAoJEBO17ljAn7PgnNMQAI1oOdD0GNmzKHlN1xnAhXGy mPcQxhhh/cGGhmyvZjqliSYWQVWbNjCv8SXm2AXNKquCzScGcEsBjufzCY6lUb/k +MVabEGBtxxxQ4PZBBA2YsKjMR8HucMR/Q3wbF7QL9BcHXX6ZYpee9SPJh8kQ95b b7BLp7b/LmKpmebhlZoLWYXRev8NO5k2yOLuU5MzLpAAhnsQQSwd+TqtlEW7VmVD 8Tu/6MZ7IQgcvXrqYXQSnTa38GKGLjdZHj3a25qeiChxJWn8fvWdx0fLi9SaJWs0 P3dlOfmiE0zqkvt1tGFgxsdI4GeKNC2Mmjcmi3ljKUu/j9rR3nK1b7uz7kGdxowj 1svipDspOPAawlNEkVw8aO9Qf9ko1BR4UPsOERA5Emj/0ypP2gzZgCqRVv9NSaOK LZOFKjxkWx+hr17LFpJczUp2IkV8a38fFlXTEtYscX5eviPp494cVT/H0otVvNgT KErg4deCkyrmwycuMq/ZSop0K2EyyUaC4mp0Svfr0X84jWEk/XlH9Zfo4QZR0IsK 1yl1lqNINjJ2YFRIrN3rIRYIu4rCZ6HKcaclwO0lNV6hjsImpFwGwIUNtO6Dd+rM mCoQCNh35NWWldyZo/49MqCPRXOcpBMHByweXspOqjrJ+JMwAPBO54Az2JR2BbUG 96ViHcgL5GM/cnWYiOTZ =QOba -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Requesting WGLC of draft-grothoff-iesg-special-use-p2p-*
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Christian Grothoff wrote:
> Dear DNSOP / chairs,
>
> The same applies to the various P2P drafts:
>
> https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-
>
>
bit/
Section 5, paragraph 3 - The example uses .onion, which I assume is
leftover from the original single document. It should be changed to
.bit in this document.
> https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-g
ns/
>
>
https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-i2p
/
Section 5, 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 would like the IETF to follow the same process it applied to
> .onion, especially given that the origin of these drafts pre-dates
> the .onion submission and they are equally technically justified,
> except of course that the urgency of the IAB .onion certification
> did not apply.
>
> Naturally, we're also happy to receive constructive comments, but
> maybe 2 years of energetic discussions will finally suffice?
>
>
> Thanks!
>
> Christian
>
> On 09/13/2015 10:15 PM, Warren Kumari wrote:
>> Dear DNSOP / chairs,
>>
>> We were requested to hold off on this document until the .onion
>> document had completed it's process. As this has now been
>> approved, and lies with the RFC Editor, we are requesting WGLC
>> of draft-ietf-dnsop-alt-tld ("The ALT Special Use Top Level
>> Domain")
>>
>> W
>>
>
> ___ DNSOP mailing list
> DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
>
-BEGIN PGP SIGNATURE-
iQIcBAEBCgAGBQJWDhcTAAoJEBO17ljAn7PgGjUP/0oc1eIAuz4kBuUpPWaQkmLW
XhIAmOaIOMI1hOCoI23PnhWC4BAuWwHGweIavTpz4/y7wJPxZL9BjR3QLe08K7Yp
Ghc5O+gIwVFCeqC3z2679kQwGxvJ0KgeuELplPjhLIailXFYla4wI78fZNKFBcTL
sB+wG39dyfcXblOo/RbJUo93scRQCo27FgqIkBUYp8Nc/1j7cI28P8QoXFnIqgXT
dUlkCHZbg0KCCFAOlct0r5mz9qv8hB1VwWhYOVsmkfEofl3rEOt7LJeUB6yrp0op
r0IutByaZq9BShACjOHeXP/r5Vy+1RfGHxe0a2p4rlUHtBIumSgKkrnw9RhtcCg2
ut9trpbrYfn2vve8HFNOlVpMwNaoh8W3CPwQW7gVb1bdzKePXcpEHD0iv4FP4UTw
z6R8tED93ZurX0ILJIjWFMzpF0/h4FjrmNcehCYh3nNnAHrgFBiZVb0zr73kkYuT
FZf+e/9DibsGDzOOwcnIrYe+OnIUnyPN2k7yXhz0AUrts75xbY9mMVQmNGuiaDOl
9WfrFSoJpu1is2/flC5v4zqT6MXCovVtiv2bWiaC2lwgq+NjuyVcaTgONwkXNFqz
fLTEqGLW/Fes7z99iqZG2vepZLUYvzURcoYoku6EEVC0NBZ7aD2VRTaXrx1JA4D6
onInpRb/tUsgkqxG2zhX
=Vt/A
-END PGP SIGNATURE-
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Jari Arkko's No Record on draft-ietf-dnsop-onion-tld-00: (with COMMENT)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Joel Halpern wrote: > I was talking about a reference to a document in a version > repository (a github repository). The comment had nothing to do > with the corporation "github". The issue is that the content of > the reference is not stable. As Tor evolves, the content of that > document changes. For many purposes, that is a good thing. For > informative references, this is also fine. For normative > references, that is references which must be understood to fully > understand the document, they must reference stable content. (URIs > are allowed if there is reasonable expectation that the content is > stable.) If the problem is solely the stability of the reference, then here's an idea I don't think has been floated yet: include the Git revision in the normative reference. It's functionally identical to e.g. including a DOI - as long as you have a copy of the repository that is newer than the date of the referencing RFC, then you can obtain a stable copy of the documents at that time. That is IMHO a far easier reference to look up than many non-RFC normative references, because the git repository is distributed far and wide, and any mirror/copy of it can provide an authentic stable copy of the documents. This is because the Git revision is essentially a hash of the entire repository and its history at that point in time, and can be considered a unique identifier (at least until 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. This judgment > belongs to the IESG, not to me. I reviewed based on my > understanding. If the assignment to Tor of .onion is for any use > that Tor chooses, then indeed the references are informative. If > the assignment is for use for some specific problem and behavior, > then the references are normative. The wording of the draft led me > to believe it was the latter. In either case, the draft should be > clear about what it is doing. > > Yours, Joel > > -Original Message- From: Alec Muffett [mailto:al...@fb.com] > Sent: Thursday, September 03, 2015 11:32 AM To: Joe Abley Cc: > hellekin; tjw.i...@gmail.com; Brian Haberman; > dnsop-cha...@ietf.org; draft-ietf-dnsop-onion-...@ietf.org; > dnsop@ietf.org; draft-ietf-dnsop-onion-tld...@ietf.org; > draft-ietf-dnsop-onion-tld.sheph...@ietf.org; Jari Arkko; The IESG; > Joel Halpern Subject: Re: [DNSOP] Jari Arkko's No Record on > draft-ietf-dnsop-onion-tld-00: (with COMMENT) > > Hi Joe! > > >> On Sep 3, 2015, at 4:02 PM, Joe Abley <jab...@hopcount.ca> >> wrote: Pretty sure Joel was just referring to where the current >> documentation is stored, not poking sticks at corporations. > > Just in order to fight potential confusion at any point where it > might flare up, lest other folk jump into this discussion and try > running with it: > > * The Tor specifications and code are on a Git repository owned by > the Tor project, not at Github. A simple DNS lookup will confirm > this: > > $ dig gitweb.torproject.org ; <<>> DiG 9.8.3-P1 <<>> > gitweb.torproject.org […] ;; ANSWER SECTION: gitweb.torproject.org. > 3600 IN CNAME vineale.torproject.org. vineale.torproject.org. 3600 > INA 154.35.132.68 > > - so, any arguments which involve Github (Incorporated) are poorly > grounded. > > Continuing: > > >> There's nothing in 6761 section 5 that demands a reference to a >> stable specification. The fact that there's any reference at all >> is a courtesy. > > > Per my previous e-mail, I would be happy to pluck out > specifications, especially if they are blocking progress, because I > see their inclusion as irrelevant to the matter of registering the > special use domain name. > > -a > > > > — Alec Muffett Security Infrastructure Facebook Engineering London > > > ___ DNSOP mailing list > DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop > -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJV6OwOAAoJEBO17ljAn7PgWJsP/3gcWIUMKPayC43SmnRqjZ54 Q8H+h/Ma5a5KGdbdZd/DVW2FELLW3CS7mccbymEfoxfiDY09+FqjU/vsxSV5Ucub XnUJUjmEP89FWUBL8VTUl6bXOpijtUq1Luw9hbE7eKsGqjHTFhESf1/H1NQsqLW7 7Z6q13yMgPx6X41+ls2i8yrf7hZth/aRo8e+GByecGkYC8Eti2FbX7ye8jWemWno 2F+pDzfUVWoVnAwpmL+UzEzfWKHxI6p1W9xC6K0/iy+qXmqN63crTMtMLFojDVoK lUhjeQGw8l9SqBHTL+KmROZVK/0MdHPeHum+PRfgZA39XSkORdjnfwvGxsjryocH m1EysD/YuPdBdZMoe4m5UUafVifvfhdaWKxZ6rkKRnG5DoU309VxtpTCdsjW8X7s 1OSU8NPctAKYs7VGk
Re: [DNSOP] Some distinctions and a request
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Andrew Sullivan wrote: On Tue, Jun 30, 2015 at 11:43:42AM +, Edward Lewis wrote: I'm not aware of the rule that declares Onion names as part of the domain name space. Not an argument, just a data point. I've always heard, and have been running on this, that Onion names are not part of the DNS name space. You're conflating DNS name space and domain name space again. I didn't say they're part of the DNS name space; and given what the top-level label onion. does, they can't possibly be. At the beginning, I claimed that the domain name space was all the logically possible domain names, not all the ones in fact possibly in the DNS. Under this definition, local. is part of the domain name space and not part of the DNS name space (because of local. being registered in the special use names registry). When I asked about this before, one of the onion proponents told me that onion names have to conform to DNS (and, he claimed, LDH) rules right now, though that is a possibly temporary convention. .onion and .i2p (and to my knowledge, the other proposed P2P-Names TLDs too) have to conform to DNS rules in order to be usable in legacy applications that expect domain names. In some future where the percentage of apps requiring this is much lower (by most apps natively supporting Tor/I2P/etc), the restriction could be removed. But while domain names are the de-facto standard, I don't see it changing. Alain Durrand and I talked about this a few weeks back. He made the point that you can distinguish the namespace of an identifier on the right or on the left imaging the use of names in URLs. I.e., there could be a http-tor://tor-name.onion/path and use http-onion to tag this as a Tor identifier or http://tor-name.onion/path; and assume it's Tor because of the onion where I'd expect(*) a domain name to be. I think this is a terrible confusion of URI schemes vs. name-space switches. It's true that if you treat the URI as an unformatted string you can parse it this way; but there are already rules for that. But I think anyway that's a distraction. We don't need uri-schemes to creep into this. +1. Besides the confusion, this would require native app support, because URI schemes are generally handled separately to name resolution - you couldn't just use a SOCKS/HTTP/DNS proxy 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/0xpTx2FPg02aNWyeroS32nX5Lo TCx4YgVxBdQYKjXzg9t57+5t+CgcNVu9/YBVuJfEj+Isu/GZHr4ElstVtVrv50zq 1U3UycHA9HWdTjKU1zE6f3IrZXIzNpQGDXwjdhYySpGK1nKwTVRBEJFDsz2JDtyc fu8gVsMPvvmqDwDYOJCqxvB5Ko/bF2PehtdtGY82qJBdtE5w+/Rbtu5mdZeupcU3 Ps74fZk6zHEZzzbbJjvwDHHG4oE/AmhLRZp9fylhzabCCElGNZ8Uuc4Fz7ZuXFsn ngg+9ANVl10JFv+RkKjKEbyyoUKDvd69d7TxAv11wR+OIhnchCFFRyU3YVlEuuK5 g5WMCQyhb010Wa5QasoQH2OAlhKQPsDtN2WbLoljqyptmIJ4TU2dej/EJSYSvX1M kbkj005GFm0jv4rVRja7dgkmrErxH9tJq0HwcIsQPe+KaIHWmeR2BwTbxXiQtjBr gb6bGc5EO1GakxARefvHSLjag/iFuOjJ8M6kU8IKb2gemzXpOPA4ocfF3GwajcXi +uWyxB0slKYUiBUNxFzw =67PO -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] More after onion? was Re: Some distinctions and a request
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Edward Lewis wrote: On 7/1/15, 14:26, Richard Barnes r...@ipv.sx wrote: We do our best work when we do engineering, not rule-making. Let's engineer a solution here that's more appealing than squatting. For my money, alt-TLD looks about right. How does that help this: On 7/1/15, 1:47, st...@i2pmail.org wrote: .onion and .i2p (and to my knowledge, the other proposed P2P-Names TLDs too) have to conform to DNS rules in order to be usable in legacy applications that expect domain names. Having a alt-TLD is fine. But what if names are proposed, experimented and deployed outside the sphere of influence of the IETF and/or working group? Writing this as someone who is unfamiliar with other proposed P2P-Names efforts and whether they want to engage with standards bodies before deploying. I admit to being highly surprised that you are unfamiliar with the P2P-Names draft[0], given that it pre-dates the later .onion-only draft. To save you trawling through the archives, the P2P-Names draft was proposed to bring the TLDs contained within onto the SUN registry under RFC 6761. However, neither I2P nor Tor (I cannot speak for the others) engaged with any standards body before deploying, because (IMHO, I was not around at the time) a) there was no clear indication that the floodgates would (or could) be opened for TLDs, and therefore no obvious reason for concern, and b) RFC 6761 did not exist at the time. I2P deployed .i2p in 2003[1], and Tor deployed .onion in 2004[2]; RFC 6761 was published in 2013. I've gotten the impression that members of those efforts dislike standards processes - I may be wrong but that's the impression I've gotten from the discussion on this list. I certainly don't dislike standards processes. What I _do_ dislike is inconsistency and poor documentation/education. If DNSOP / IETF wants to ensure that future applications root their name spaces in .alt or wherever else instead of choosing a .TLD to add to the SUN registry, then developers _need to know about it_. I personally agree with Richard that .alt is far more appealing than the struggle to get a .TLD added to the SUN registry, but the longer it took me to discover .alt, the harder it would be to justify switching. (It's for this reason that .i2p is as unlikely as .onion to be moved into .alt, with well over a decade of use, and .alt not even in existence yet.) Having it stated in an RFC is definitely better than the status quo, but IMHO it would be much better to have an FAQ page that clearly outlines the IETF's / working group's position, itself backed by references to RFCs. Then use SEO to get it near 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/meetings/059 [2] https://en.wikipedia.org/wiki/Tor_%28anonymity_network%29#cite_ref-or-lo cating_85-0 -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVlGuMAAoJEBO17ljAn7PgOesQAKjnyUJAceWnEgPTKWzb/LXU LkcJ1cZPQsRAilfM1h3GNJ6tg7ZYDZcr16nwNzfbSfYhI/LQpLOhGm1VxM7vVjB0 01hBaOZnJoehlTmSO/6H+lPfwE2GnMrtM3LMbytPIFSYKtnTqU6pgZcA2StvPr0P eoXpNofJ8hMX31FB117D7glzOycuUqm3GN/aurKj13B1uXjLGQxFAYwQxyfc1JB5 VYD2q7WtacJSJPGC7orgBu+LI6GYg9Cjb7+Bj6BLjT+NZ/6c46kvZ2KOnoFI/7Hg jgtM9Z1FmWGEnbKwsb3LdctOWU1FtWrSeepp2f4Sg3NVJM0FdYTE5N2zyKWP0nPc EMosnJRDOLsCL324sbj5HIZ1vL46OO+HWZWur3gRGgDBUmqjIBfONfu3qnXmL7UG 3JRtdM83FLht2xI+iYdbY059LQsU9t3LR5BUJnv9IVuz6ELHi1i5pEF1bTY2AvGl taZax7lhB+jhQgcfITIzx3rlxOMv8wdsSq0L/ynJqm9afqGTU/G5S9k1vJaXunnU IULAvouQ4iERufzrUwKHh94Vd/HhbrOF/Oc5z7ObtTPSjBvmLPIRoxYl2c8xV7WR 73+K3L6rxifqP1ITMo8MiFO4+sr70c7oyqS+gRSdWLRoh2xkNTNIAXoahyegSk8F WdHJBvBnvbByyyatoHu5 =/8p1 -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Interim DNSOP WG meeting on Special Use Names: some reading material
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Ted Lemon wrote: George, I didn't get into your game theory because I think it's irrelevant. The IETF process is not a fast process. If parasitical organizations decide to try to get the calories they need from us rather than from ICANN, I am pretty sure they will quickly learn that this is futile. It might briefly suck for us while they learn that it won't work, but I don't think so. We already know how to deal with useless proposals. So with that in mind, I think we really are free to do the technically right thing without concern that it will encourage badness in the future. As to the topic of fairness, that is inherently political, and we should steer well clear of it. There is no way we can reach consensus on it, and whether you want to admit it or not, by advancing the argument you are advancing, that is what you are asking us to do. What you are saying is a really good argument against us reserving names simply because they have been squatted on. I agree we should not use that as a reason to reserve a special use name. ICANN already has a process for thatIf we want to reserve a special use name, we should have a technical argument in favor of doing so. But in the case of .onion, .corp and .home, we _do_ have such a reason. So there is no need to resort to the argument that these names should be documented in the special use registry because they were squatted on. If .onion were being proposed today, and had no previous implementation, its proponents would rightly be arguing for .onion, not for .onion.alt, because how names read _matters_, and it makes sense for .onion to be a special use TLD, as it does for .corp and .home. In the virtual meeting, I stated that if I was developing an app like I2P *now* that needed a non-DNS TLD, and .alt existed, I would use it. I should clarify that I would certainly prefer .TLD over .TLD.alt, because I agree with Ted that how a name reads matters. But, if there was an _easy_ process for securing .TLD.alt, _and I knew about it_, I would probably opt for that. It isn't as pretty, but it's not much harder to educate users that .TLD.alt is the special identifier for this new app that it was to educate users back in 2003 that .i2p is the special identifier for I2P addresses. DNS has had a long run as the only name database that is taken seriously on the Internet, and so we no longer think of names as being something that has an existence independent of the DNS hierarchy, but that is not an inherent truth of domain names. It is just the status quo. I would not want to have to use a different name hierarchy designator in order to use mDNS, and that being the case, I don't think you can make the argument that .onion is qualitatively different from .local. +1. The domain name is a concept that pervades all internet-using applications now, and any alternative non-DNS naming system that wants to maintain interoperability with existing apps is forced to use it. That is the primary reason why I2P chose .i2p and (IMHO) Tor chose .onion. The biggest barrier to the rise of hidden services like what I2P and Tor provide is content availability. If the I2P and Tor devs had needed to re-implement _every_ client application they wanted to work over their networks, neither network would be as large as they are today. That doesn't mean that new application developers should not write network-aware applications, or that existing applications can be used without any potential for privacy-compromising leaks. There are definite technical and usability benefits to an application setting up its own I2P tunnel. But it is much easier to e.g. run TZ=UTC git, or point an I2P server tunnel at Apache and configure vhosts, than it is to implement network-level support. Moreover, supporting a non-domain name system would very likely require extensive, expensive modifications throughout the app to e.g. remove any and all dependencies on gethostbyname(). The Tor Browser bundle is IMHO testament to this - its developers have added a slew of privacy-enhancing patches, but the browser still 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 ODDeQbIJDvqTl7DpK9mV+z8ViCjS4+gtw0oYvtB7v3Ig2Pg/jfCS6q0Xbx784fuJ gkHTe4rAkfKHKyA6ozCeSf7rY4FXR6hSc9IoxEKixm33gSiXRmfvLDcF4YOJLrKU GIraly6of0zPIC5NQVO0oXRceMwsn8Mlk2p+N1pDauhu0b54OzBht/7P/XtfIMD1 rbDVHUPcLE6zQNYFklGv3VGV3LkZbR9GwUMsyQ7Jmor9Sfj8llF37OnTJpjsI7Lm ofQgjOXwYFni3k6rOWbPObh2HtDeKAaHu3HdNHcCb5Sm8PXzrYHL9DpWZcO7VAhd 4Z2kuwEIO/7nM/B2yg1XclXvJBzc5G8Egs1plcmWu79lR7UxdHVCoWSjd+Xj1FZP SkFYPTEjt2y02ZfOGG/83rdN1XVkrqts7hIAD+mHk2sMLebcTykP2IAN3KLz5ME1
Re: [DNSOP] Post-Interim considering the 4 proposals
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hugo Maxwell Connery wrote: Hi, I include below the last of the 8 sections which are included in the attached piece. I offer this to the DNSOP list for consideration in the existing 4 proposals for special names registration. I hope that people will read the full text, though you will be bored by (and possibly complain about) the first section. Thank you for this nice summary. I welcome all comments/complaints. My only complaint is regarding my previous comments at the meeting and on the ML. I feel this text is starting to deviate in essence from what I was trying to say (although I was probably not eloquent enough at the time). For the record, I shall restate my positions clearly below . The entirety is 1172 / 200 / 3 (words / lines / pages). Regards, -- Hugo Connery, Head of IT, DTU Environment, http://www.env.dtu.dk -- last section -- More Commentary and Even More Personal Opinion I believe that the grothoff and appelbaum drafts are the first cases of testing the mechanism for the use of the special names registry. I also assume that the registry was created to be used for more than its initial propulation with things like .local and .invalid. Additionally, I agree with some members of the DNSOP community that names matter. my-product.invalid is not a good way to start a venture. Should .alt be available my-product.alt is far preferrable as confirmed by a member 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 writing a new I2P-like application requiring a non-DNS .TLD _after_ .alt had been accepted and publicized as the accepted way of establishing non-DNS domain structures, then I would use .TLD.alt instead of .TLD, because it would be far less hassle (to get it reserved, as I expect having .alt would enable IETF to more easily evaluate and accept reservations under it) for not much additional work educating users. I would of course _prefer_ to use .TLD on its own, but as an app developer I would take the path of least resistance. Right now, that is to register .TLD under RFC 6761. If .alt is accepted, it would be that. Indeed, that person claims that .alt would have been used if it was both available and understood. I said that I2P would _probably_ have used it, had .alt existed at the time as the accepted way of establishing non-DNS domain structures. However, I want to ensure that these two points are abundantly clear: * I am not one of the original developers of I2P. I was not involved with I2P until years after .i2p had already been chosen and established, so I cannot speak for what they would actually have done. * Even if .alt does become available, I2P will not be transitioning to it. (This has already been thoroughly discussed previously on this ML around the P2PNames draft in general, and the .onion and .i2p TLDs in particular.) str4d I have little concern for the corp request, but it gains weight by having potential operational impacts in the DNS space. As mentioned I could not find a draft and thus have no knowledge of its technical nature. I think that the key decision is appelbaum. It meets all criteria which I list above. If this request cannot be processed effectively, that lack of efficacy throws into question the entire nature of RFC6761. As stated, I assume that RFC6761 was well considered and that the registry was intended to be ammended. IMHO, the appelbaum (.onion) proposal meets all possible standards for approval. Finally, I wish to support the .alt proposal. I believe that it is wise to create a reading neutral space for the creation/testing/deployment of alternate name space communications technologies, and in this regard I will quote Bruce Schneier from his presentation at IETF 88: Second, target dispersal. We were safer when our email was at 10,000 ISPs than when it's at ten. Fundamentally, it makes it easier for the NSA and others to collect. So anything to disperse targets makes sense. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVVhVMAAoJEBO17ljAn7PgRLAP/jsLKzodu4r5VISB+pMojs9G fpC7QKQc16DRiOrsGu9U93an/BIxP7s4kzfpKPCsCveEWH+QK5UBHqoOllf5MMib nq703szES505e0RsfjDEWOwPW/lKPp91xYQZv1lOSPA76/0wBsWXka2ogDLUROnL d87e3sgO2p/L2NkH/qtd8GE5d2Ns/DsiCEAcvcy0ldqS8yRf33yaUnZQ1Uvxu8Qn ymIW356WoWsdKsinGluwtxOoZoVh3hbpcUjUvRZOCZJwVAmzgycE9kLTNIbEjvKq D/YgS9TmzFuxkMJalQHL2yBykESAyt/Zb33zZl2yeQWmZsj3/ec1tUlwdK9eXKSi eg6kWTdENVHLp8lDM4pDH8J2G3Bjxakm+pNo/pcI7KynsFWznaeEAOKaqUJbh0ro VsuKEClyGkKGDjZ7PArNAf2hyiGrerBmfV4aCq8sEIa/VU1FtThFgB+7Y+5ZlHk5
Re: [DNSOP] Interim Meeting on Special Names and RFC 6761
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Tim Wicinski wrote: All, As we announced in Dallas, we’ve decided to have a separate meeting on Special Names and RFC 6761 topics. We're planning on scheduling this the week of April 13th; with Thursday, April 16th as an initial choice. Thanks for planning this :) As someone who has an interest in this particular meeting but has never watched or participated in IETF or DNSOP meetings before, how will this meeting be conducted? How do people choose to watch or participate? The only information I can find that might be related is about IEFT interim meetings [0], but there is no scheduled interim meeting for this topic [1]. Is there another mailing list or website I should be following for more information? [0] https://www.ietf.org/meeting/interim-meetings.html [1] https://www.ietf.org/meeting/interim.html If folks have any preference for a date, or conflicts with this one, please let us know. We plan on having the meeting at 2pm UTC, which would translate to 4pm CEST, 10am EST, 7am PST, and 11pm JST. Other suggestions are also welcome-- no time is perfect for everyone but we’re trying to accommodate the widest range of participants that we can. I haven't seen any further communication (on this ML) about the meeting, so I assume the specified date and time is still the case? Friday would work better for me than Thursday (which I can't do at 2pm UTC), but I'm just one person. We’re working 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVJehTAAoJEBO17ljAn7PgHiUP+wUdnGPa4R8mn/h1q5Uea28O xJChFJBvgvcKv63MAgx9DzuAgSIFokSV+RPtOrJU7j7n3+nidLEnR81Fn44Nu7H4 wZeXht2ig/DmtIhBYEw5yy3G7vmQF1b+t8c4ev53JzkeOmYefaRVgDQN97MLy49u aRBiEOSRY83ax5B9C/10o7MIcB5K5JIRKhy5tHUirc28RimruuiHYh/j8fURtk8a qsyGxGLIRT9j64E6PXXLw4o8f90KoX4DWnmdweVnQRaEVxnRoz5btt8PR/9YHLpK S+A0aMM0YvphECataGb+xOT6lhE7ObScyPA7UY0Wgra8/Y4JqSja3wBQBfjivnAm vd/7qtkFMtRJwd6IJjyL2hzsBd+iIrbrUi8GG5vJXMZzpdg0umte8z0Siq4AeGkw 2I9X6a4+Dg/Xbwx5Ar/hC81IxPRNSVwHZ3SFjnEvL2WHofsUF1HchnblvwLVOW/e rV/ypgfx/Ii8we0FtgBrqJm25f8JKJVdcfW8K790pE+RI+wUAFjmhYyY2ken6GC3 1nwfEJyxoqJZOtHQRP2yXaOosGTFa4nndH5NvlmyVgL3iX/xCFKNnfDD/QhkUPr4 jAN+j3WlLElRTKLGUGxrrf8hXrFHMw7sARTXgTniant3/pMbrr6LRzYyqaTM8uwL 7jEpFZ7Hc6w4O4vILK2b =qwv/ -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
