Re: [DNSOP] More after onion? was Re: Some distinctions and a request
I hope you don't mind replying publicly to this, because I think you did a very good thing describing it as a one-act play. (Seriously.) Kinda like why we parody Harry Callahan at times. (That's Dirty Harry's name for those under the age of, oh 50.) On 7/1/15, 16:59, Warren Kumari war...@kumari.net wrote: (Applicant enters stage left) But what if the applicant's name is Godot (and never appears on stage)? [https://en.wikipedia.org/wiki/Waiting_for_Godot] Let's say someone does this. They squat on .foo. They never engage the IETF. Traffic is seen for .foo. A lot of DNS queries to 8.8.8.8 ask for foo. names and data, I mean. The operators of recursive servers have no idea what is generating the ever-growing queries for foo. and so, like other annoying queries, begin to filter them. One day someone else wants to launch a .FOO TLD. (Stay tuned for the sequel Universal Acceptance) The objective of a registry is to map object to entity for the sake of (among a few services) uniqueness. The latter part of that statement is often forgotten. The uniqueness is not just to protect the entity to which the object is mapped, but to protect all others from running into it. Collisions are not always hi-jacks, where the collider wants to tackle the object, sometime they are like tripping hazards where the collider just didn't see it or have a chance to see it. One red herring here is that there's a domain name market. There is. To the IETF that should simply mean that the likelihood of collisions is higher than it was without a market. And yes, ICANN has processes for dealing in that market. But that's not important here. There's one other factor in all of this, coming in out of the blue. I recall a talk at DNS-OAC in spring of 2013 where someone tracked down a source of query traffic that could be categorized as annoying. After much effort, the source was a music app using the DNS as a ping/keep-alive service, meaning the app, which had not reason to use DNS much, know that by repeatedly sending traffic it kept up tunnels, etc. The point is - the presenter went though a lot of trouble and only with luck, identified the source. This is part of the desire for a registry - so we can figure out where and why traffic is coming into servers. That talk - I just can't find it...I thought it would be here, but I don't see it: https://indico.dns-oarc.net/event/0/contributions Or maybe I'm making it all up. That's why I still think there's a need, even with an alt-TLD, for a process to register special use names, special in a technical way. smime.p7s Description: S/MIME cryptographic 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 On 07/02/2015 10:05 AM, Edward Lewis wrote: You're right. To underscore, it's because of the groups that don't engage, and have no responsibility to do so, that the IETF has to defend itself. It wouldn't take much work Keep in mind that the IETF isn't a thing, it's a collection of people volunteering time. What I mean to say, not much work, but it's like trying to jump out of the ocean back into a boat. I could not agree more with Str4d. Processes are not at fault: aren't we having a rough consensus about the Internet as an open society? For your information, draft-grothoff-iesg-special-use-p2p-names-00 was published on *November 14, 2013* [0]. It has been submitted to 4 revisions to date, without counting the newly split drafts at the request of DNSOP list members into a draft per system (.bit [1], .exit [2], GNS [3], and .i2p [4]). As a final comment to help you catch up with the process, the .alt draft [5] first appeared on June 06, 2015, and the original mention of .onion was removed from its fifth revision following my request to confirm that .onion was not covered by this draft (per the draft author.) I think you know this because your comments were also included in this version of the .alt draft. I am very surprised that you did not read the P2PNames draft, and hope you will now read the 5 drafts that came from it (I include .onion [6] to the 4 mentioned above). Regards, == hk P.S.: As Christian Grothoff mentioned, I was interested in making these 5 drafts leanier, following the .onion model, and bring the (common) details into an informational RFC instead. If you think 5 drafts are too much reading, that might help, especially as there's a lot of redundancy from one to the next. [0]: https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-nam es/00/ [1]: https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-bit / [2]: https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-exi t/ [3]: https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-gns / [4]: https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-i2p / [5]: https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/ [6]: https://datatracker.ietf.org/doc/draft-appelbaum-dnsop-onion-tld/ -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQJ8BAEBCgBmBQJVlUYyXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0 ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9zpIP/3QJF7Eni4RrzwAn5U3ITnqo vsv/cTcVYTm2EybW3mFaY/UeE868HyHrsF0mXOIxwm/B6lFCAKA47B5m+zvqhRwA I1euxD9L/KOoB/8//sE+JLzKffiwGPaI2MY6r3Wiqb5ivijy1sVVuwr8GV2QdvoD Nvflcnu+iXX3IQJpZTDxrrmKjYIdgXxCxKPKYquf4kE3cMWv/5sEolYvTH1eHlLV MBGzzKZntE487u0RGEiym0teE0xV3U09Ln7cpppMmKrrKs3UkcXfqFbB+fhKHP+N J54Pif+ndiMeBAcYuoj4/OXtT+x1r3rOR8PLgUvdlYfBsJpjOlREAVqDP/c9R1sW PWkSkrBmo1hTkQv5ZPt/EBc6Fiovq3k0ptnO3GXn4XOT1udXarlAXpZm7KvzY7Sc DG6Q2EXM8//w4jwfC3mBt+jFEskijEh6G2sNo0z8lBsgyU9EZuSkUGMtT3c1nLaX jnV0Qd90tpD9tP/dGk/U4S8V4Wg9fhBxlDbMYiEFRttaGdL4MGFXoSDcHLuqDTTX QAtDx2kvR/yhLJY5OHO1qGvTjixcfMz82COrRCEsczH4psjS/iRziT1DlGX2aMQr 6kSOPq0EtabdfYwsHSETfh4KC1DfzzIEVlvFen3hs9sIrj631HACoZfMLNYcjbmH vNO8NaLUMJsIIi9eniQ2 =0u6r -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
On 7/1/15, 18:37, DNSOP on behalf of str4d dnsop-boun...@ietf.org on behalf of st...@i2pmail.org wrote: 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. I don't read everything, and I'm not usually focusing on this. That's the trouble with volunteers. 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) That's fair. This is all volunteer. (That is why it's up to the IETF to define how to react.) I certainly don't dislike standards processes. Of course not - you are engaging with the process. What I _do_ dislike is inconsistency and poor documentation/education. Then you've come to the wrong place. ;) 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.) You're right. To underscore, it's because of the groups that don't engage, and have no responsibility to do so, that the IETF has to defend itself. It wouldn't take much work Keep in mind that the IETF isn't a thing, it's a collection of people volunteering time. What I mean to say, not much work, but it's like trying to jump out of the ocean back into a boat [kinda like this: http://www.bbc.com/sport/0/american-football/30744474]. smime.p7s Description: S/MIME cryptographic 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
On Wed, Jul 1, 2015 at 10:08 AM, Suzanne Woolf suzworldw...@gmail.com wrote: Ed, First-- apologies for the misunderstanding. On Jul 1, 2015, at 9:53 AM, Edward Lewis edward.le...@icann.org wrote: Trying to be more clear, I have in the past imagined that today someone is inventing a new communications technology, in 6 months will need to cobble an identifier space and in 2 years the IETF-connected crowd detects significant deployment of this and needs to decide whether to register a TLD to avoid name collisions. I've been told that this wouldn't happen because the IETF will have rules - which I am skeptical would prevent the situation from happening. I don't think we have rules or even guidelines now that have any chance of preventing it. I agree we'll never prevent it completely; it's the nature of the DNS and the internet that people can do things with names and they don't have to ask the IETF first. But I don't think it's impossible that we'll be able to provide guidance, such that developers who follow it are reasonably sure of avoiding the various types of collisions and ambiguities we're concerned about-- and such that there's a clear basis for saying You're doing something outside of the guidance we can provide about how names work in the internet, you're on your own. Warren points at ALT-TLD Yup, we will not be able to prevent people from using an identifier space that looks like a DNS name not rooted in the DNS, but we *can* provide them with guidance and a safe place to do this sort of thing, namely under the .alt TLD. To underscore - I am not against the innovation. I am urging that the processes put in place are future proof by being reactionary - reacting to the new names, not trying to fend off the situation. I.e., in agreement with the words below trying to apply RFC 6761 and finding that it remains subjective. This supports the initial suggestion that we need to get serious about a 6761bis, am I correct? I believe so, but instead of simply raising the bar to get a special use name (which will simply result in people squatting more), I think we need to provide solid, usable advice and an option for people... W thanks, Suzanne On 7/1/15, 9:05, Suzanne Woolf suzworldw...@gmail.com wrote: (no hats, for the moment) Ed, It seems to me that this is exactly the issue: we've already had multiple drafts requesting new entries in the special use names registry, and expect more. Your note sounds as if you're fairly sanguine about a stream of unpredictable requests; however, based on what we've seen so far, I admit I'm not. I'm still re-immersing in DNSOP after being entirely absorbed in other work the last couple of weeks, but I want to support us continuing this discussion, because it seems to me that the point Andrew started the thread to make is valid: we don't have a coherent view of how the relevant namespaces (based on DNS protocol, compatible with DNS protocol but intended for different protocol use, or otherwise) interact. The painful immediate consequence is that we're trying to apply RFC 6761 and finding that it remains subjective to do so, with an element of beauty contest in the deliberations that means outcomes are unpredictable. There's no meaningful guidance we can give developers on what names it's safe for them to use in new protocols, or even for specific uses in-protocol, and as Andrew and others have pointed out, there may even be ambiguity about what our own registries mean in protocol or operational terms. Longer term, this lack of clarity has implications for both architecture and policy for the DNS, including our ability to support innovation and to coordinate with other groups in the IETF and beyond. best, Suzanne On Jul 1, 2015, at 8:26 AM, Edward Lewis edward.le...@icann.org wrote: On 7/1/15, 1:47, DNSOP on behalf of str4d dnsop-boun...@ietf.org on behalf of 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. I'd been told that onion. was a one-time thing, that in the future conflicts wouldn't happen. What I read in the quoted message is that onion.'s request isn't a one-time thing but a sign of things to come. I'm sympathetic to the use the path of least resistance - e.g., use names that syntactically are DNS names - instead of building a separate application base. I expect innovation to be free-form and thus a stream of unpredictable requests to reserve names for special purposes, including DNS-like names. What DNSOP can comment on is how the DNS reacts to names, whether in protocol or operational convention, once they are known before they achieve some degree of widespread adoption. To what extent is an effort made (by whomever) to detect these budding namespaces, is this proactive?
Re: [DNSOP] More after onion? was Re: Some distinctions and a request
On Wed, Jul 1, 2015 at 2:23 PM, Warren Kumari war...@kumari.net wrote: On Wed, Jul 1, 2015 at 10:08 AM, Suzanne Woolf suzworldw...@gmail.com wrote: Ed, First-- apologies for the misunderstanding. On Jul 1, 2015, at 9:53 AM, Edward Lewis edward.le...@icann.org wrote: Trying to be more clear, I have in the past imagined that today someone is inventing a new communications technology, in 6 months will need to cobble an identifier space and in 2 years the IETF-connected crowd detects significant deployment of this and needs to decide whether to register a TLD to avoid name collisions. I've been told that this wouldn't happen because the IETF will have rules - which I am skeptical would prevent the situation from happening. I don't think we have rules or even guidelines now that have any chance of preventing it. I agree we'll never prevent it completely; it's the nature of the DNS and the internet that people can do things with names and they don't have to ask the IETF first. But I don't think it's impossible that we'll be able to provide guidance, such that developers who follow it are reasonably sure of avoiding the various types of collisions and ambiguities we're concerned about-- and such that there's a clear basis for saying You're doing something outside of the guidance we can provide about how names work in the internet, you're on your own. Warren points at ALT-TLD Yup, we will not be able to prevent people from using an identifier space that looks like a DNS name not rooted in the DNS, but we *can* provide them with guidance and a safe place to do this sort of thing, namely under the .alt TLD. To underscore - I am not against the innovation. I am urging that the processes put in place are future proof by being reactionary - reacting to the new names, not trying to fend off the situation. I.e., in agreement with the words below trying to apply RFC 6761 and finding that it remains subjective. This supports the initial suggestion that we need to get serious about a 6761bis, am I correct? I believe so, but instead of simply raising the bar to get a special use name (which will simply result in people squatting more), I think we need to provide solid, usable advice and an option for people... +many to what Warren says. 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. --Richard W thanks, Suzanne On 7/1/15, 9:05, Suzanne Woolf suzworldw...@gmail.com wrote: (no hats, for the moment) Ed, It seems to me that this is exactly the issue: we've already had multiple drafts requesting new entries in the special use names registry, and expect more. Your note sounds as if you're fairly sanguine about a stream of unpredictable requests; however, based on what we've seen so far, I admit I'm not. I'm still re-immersing in DNSOP after being entirely absorbed in other work the last couple of weeks, but I want to support us continuing this discussion, because it seems to me that the point Andrew started the thread to make is valid: we don't have a coherent view of how the relevant namespaces (based on DNS protocol, compatible with DNS protocol but intended for different protocol use, or otherwise) interact. The painful immediate consequence is that we're trying to apply RFC 6761 and finding that it remains subjective to do so, with an element of beauty contest in the deliberations that means outcomes are unpredictable. There's no meaningful guidance we can give developers on what names it's safe for them to use in new protocols, or even for specific uses in-protocol, and as Andrew and others have pointed out, there may even be ambiguity about what our own registries mean in protocol or operational terms. Longer term, this lack of clarity has implications for both architecture and policy for the DNS, including our ability to support innovation and to coordinate with other groups in the IETF and beyond. best, Suzanne On Jul 1, 2015, at 8:26 AM, Edward Lewis edward.le...@icann.org wrote: On 7/1/15, 1:47, DNSOP on behalf of str4d dnsop-boun...@ietf.org on behalf of 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. I'd been told that onion. was a one-time thing, that in the future conflicts wouldn't happen. What I read in the quoted message is that onion.'s request isn't a one-time thing but a sign of things to come. I'm sympathetic to the use the path of least resistance - e.g., use names that syntactically are DNS names - instead of building a separate application base. I expect innovation to be free-form and thus a stream of unpredictable requests to reserve names for special purposes, including DNS-like names. What DNSOP
Re: [DNSOP] More after onion? was Re: Some distinctions and a request
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'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. smime.p7s Description: S/MIME cryptographic 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
Ed, First-- apologies for the misunderstanding. On Jul 1, 2015, at 9:53 AM, Edward Lewis edward.le...@icann.org wrote: Trying to be more clear, I have in the past imagined that today someone is inventing a new communications technology, in 6 months will need to cobble an identifier space and in 2 years the IETF-connected crowd detects significant deployment of this and needs to decide whether to register a TLD to avoid name collisions. I've been told that this wouldn't happen because the IETF will have rules - which I am skeptical would prevent the situation from happening. I don't think we have rules or even guidelines now that have any chance of preventing it. I agree we'll never prevent it completely; it's the nature of the DNS and the internet that people can do things with names and they don't have to ask the IETF first. But I don't think it's impossible that we'll be able to provide guidance, such that developers who follow it are reasonably sure of avoiding the various types of collisions and ambiguities we're concerned about-- and such that there's a clear basis for saying You're doing something outside of the guidance we can provide about how names work in the internet, you're on your own. To underscore - I am not against the innovation. I am urging that the processes put in place are future proof by being reactionary - reacting to the new names, not trying to fend off the situation. I.e., in agreement with the words below trying to apply RFC 6761 and finding that it remains subjective. This supports the initial suggestion that we need to get serious about a 6761bis, am I correct? thanks, Suzanne On 7/1/15, 9:05, Suzanne Woolf suzworldw...@gmail.com wrote: (no hats, for the moment) Ed, It seems to me that this is exactly the issue: we've already had multiple drafts requesting new entries in the special use names registry, and expect more. Your note sounds as if you're fairly sanguine about a stream of unpredictable requests; however, based on what we've seen so far, I admit I'm not. I'm still re-immersing in DNSOP after being entirely absorbed in other work the last couple of weeks, but I want to support us continuing this discussion, because it seems to me that the point Andrew started the thread to make is valid: we don't have a coherent view of how the relevant namespaces (based on DNS protocol, compatible with DNS protocol but intended for different protocol use, or otherwise) interact. The painful immediate consequence is that we're trying to apply RFC 6761 and finding that it remains subjective to do so, with an element of beauty contest in the deliberations that means outcomes are unpredictable. There's no meaningful guidance we can give developers on what names it's safe for them to use in new protocols, or even for specific uses in-protocol, and as Andrew and others have pointed out, there may even be ambiguity about what our own registries mean in protocol or operational terms. Longer term, this lack of clarity has implications for both architecture and policy for the DNS, including our ability to support innovation and to coordinate with other groups in the IETF and beyond. best, Suzanne On Jul 1, 2015, at 8:26 AM, Edward Lewis edward.le...@icann.org wrote: On 7/1/15, 1:47, DNSOP on behalf of str4d dnsop-boun...@ietf.org on behalf of 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. I'd been told that onion. was a one-time thing, that in the future conflicts wouldn't happen. What I read in the quoted message is that onion.'s request isn't a one-time thing but a sign of things to come. I'm sympathetic to the use the path of least resistance - e.g., use names that syntactically are DNS names - instead of building a separate application base. I expect innovation to be free-form and thus a stream of unpredictable requests to reserve names for special purposes, including DNS-like names. What DNSOP can comment on is how the DNS reacts to names, whether in protocol or operational convention, once they are known before they achieve some degree of widespread adoption. To what extent is an effort made (by whomever) to detect these budding namespaces, is this proactive? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ 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
(no hats, for the moment) Ed, It seems to me that this is exactly the issue: we've already had multiple drafts requesting new entries in the special use names registry, and expect more. Your note sounds as if you're fairly sanguine about a stream of unpredictable requests; however, based on what we've seen so far, I admit I'm not. I'm still re-immersing in DNSOP after being entirely absorbed in other work the last couple of weeks, but I want to support us continuing this discussion, because it seems to me that the point Andrew started the thread to make is valid: we don't have a coherent view of how the relevant namespaces (based on DNS protocol, compatible with DNS protocol but intended for different protocol use, or otherwise) interact. The painful immediate consequence is that we're trying to apply RFC 6761 and finding that it remains subjective to do so, with an element of beauty contest in the deliberations that means outcomes are unpredictable. There's no meaningful guidance we can give developers on what names it's safe for them to use in new protocols, or even for specific uses in-protocol, and as Andrew and others have pointed out, there may even be ambiguity about what our own registries mean in protocol or operational terms. Longer term, this lack of clarity has implications for both architecture and policy for the DNS, including our ability to support innovation and to coordinate with other groups in the IETF and beyond. best, Suzanne On Jul 1, 2015, at 8:26 AM, Edward Lewis edward.le...@icann.org wrote: On 7/1/15, 1:47, DNSOP on behalf of str4d dnsop-boun...@ietf.org on behalf of 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. I'd been told that onion. was a one-time thing, that in the future conflicts wouldn't happen. What I read in the quoted message is that onion.'s request isn't a one-time thing but a sign of things to come. I'm sympathetic to the use the path of least resistance - e.g., use names that syntactically are DNS names - instead of building a separate application base. I expect innovation to be free-form and thus a stream of unpredictable requests to reserve names for special purposes, including DNS-like names. What DNSOP can comment on is how the DNS reacts to names, whether in protocol or operational convention, once they are known before they achieve some degree of widespread adoption. To what extent is an effort made (by whomever) to detect these budding namespaces, is this proactive? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ 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
On 7/1/15, 10:08, Suzanne Woolf suzworldw...@gmail.com wrote: But I don't think it's impossible that we'll be able to provide guidance, such that developers who follow it are reasonably sure of avoiding the various types of collisions and ambiguities we're concerned about-- and such that there's a clear basis for saying You're doing something outside of the guidance we can provide about how names work in the internet, you're on your own. (struct IETF *) We can always provide guidance. But processes cannot rely on applicants (tacit or not) to either be aware of the guidance or, more significantly, to heed it. Prepare for the best, expect the worst. (Or that conservative, liberal bon mot.) I certainly don't think it is right to *expect* that everyone will heed the guidance, so we need to build the process as if we didn't give the guidance in the first place. This supports the initial suggestion that we need to get serious about a 6761bis, am I correct? Yes. I'm not satisfied with the process in RFC 6761. smime.p7s Description: S/MIME cryptographic 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
On 1 Jul 2015, at 10:08, Suzanne Woolf wrote: First-- apologies for the misunderstanding. It seems appropriate for someone at this point to make a joke about onion leaving a bad taste in the mouth. But not me. I'm not that guy. Joe ___ 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
On Wed, Jul 1, 2015 at 2:54 PM, Edward Lewis edward.le...@icann.org 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'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. The thing that got .onion to the IETF is that they needed to be official. (So that they could get certificates for .onion names.) Until they get an RFC 6761 registration, they're in a grey zone of being neither officially DNS names nor officially not DNS names. ISTM that the benefit of .alt is that it creates a clearly-not-normal-DNS zone. We would have to check with the CAs, but I think that that would do a lot to prevent issues like what .onion ran into. My hope would be that that benefit would make it appealing enough for at least some of these other pseudo-TLDs to tolerate the switching cost. --Richard ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ 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
On Wed, Jul 1, 2015 at 3:05 PM, Richard Barnes r...@ipv.sx wrote: On Wed, Jul 1, 2015 at 2:54 PM, Edward Lewis edward.le...@icann.org 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'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. The thing that got .onion to the IETF is that they needed to be official. (So that they could get certificates for .onion names.) Until they get an RFC 6761 registration, they're in a grey zone of being neither officially DNS names nor officially not DNS names. ISTM that the benefit of .alt is that it creates a clearly-not-normal-DNS zone. We would have to check with the CAs, but I think that that would do a lot to prevent issues like what .onion ran into. My hope would be that that benefit would make it appealing enough for at least some of these other pseudo-TLDs to tolerate the switching cost. It also provides the ability for the IETF to push back more easily on some applications. Warning: The following is how this plays out in my mind. Many things in here are a little odd, but, hey, it's my imagination, not yours... Dramatis personae: Applicant: A young, eager developer. IETF (personification): Played by someone who looks like a cross between Spencer Dawkins and Scott Bradner. For some reason speaks with a strong Scottish accent... Without .alt: (Applicant enters stage left) Applicant: I'd like .foo added to the SUN registry please. I've developed a resolution service that maps from names of cartoon characters to IP addresses, and is use by many many people. It meets all the RFC6761 requirements IETF: You did a bad thing. You should not have simply squatted on a label. Anyway, a namespace made up of cartoon character names is silly... Applicant: But this meets all of the 6761 requirements, and I've got dozens of people using this. Anyway, I didn't really have an alternative, did I? How is anyone supposed to innovate in the namespace?! IETF: Well, erm you should have... e... um... ideally you would... err... Yeah, OK, we'll make .foo be a Special Use Name, but don't do it again, OK?! (Applicant skips off stage left, IETF plods off stage right, looking dejected) With .alt: (Applicant enters stage left) Applicant: I'd like .foo added to the SUN registry please. I've developed a resolution service that maps from names of cartoon characters to IP addresses, and is use by many many people. It meets all the RFC6761 requirements IETF: You did a bad thing. You should not have simply squatted on a label; we have a defined process and location for this sort of thing, it's called .alt IETF waves sheaf of papers Anyway, cartoon characters as a basis for a namespace? Really? Applicant: But I didn't know about .alt... and I've got dozens of users, dozens I tell you...shakes fist IETF: Sorry, ignorantia legis neminem excusat. Applicant: Fine (Applicant stomps off stage left in a bit of a huff, IETF looks remarkably smug, then exits stage right to further examine navel) [ Unfortunately the IETF ends up looking like a bit of an ass here, but redeems itself later by doing something helpful for the community, or, at least, entertaining... Hey, I did warn you that things in my brain are often a little, um, surreal... ] The IETF can still add things to the RFC6761 / RFC6761bis registries, but at least has: A: provided an alternative for people who /want/ to do the right thing and B: more of a leg to stand on if we need to push back on nuisance applications in the future. W --Richard ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ DNSOP mailing list DNSOP@ietf.org
Re: [DNSOP] More after onion? was Re: Some distinctions and a request
+many to what Warren says. 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. I agree. On the other hand, since we are not the tsars of the Internet, it is fairly likely that no matter what we do, someone will start using .ramp (a stronger version of .onion) rather than .ramp.alt and it will become widely enough used that it makes technical sense to keep it out of the DNS, like .onion and .home. That would not be a disaster. I don't even see it as a problem, so long as we have a process to weigh the pros and cons and decide whether to add it to the list of domain names that are excluded from the DNS. (It may cause gnashing of teeth at ICANN as it screws up someone's business plan, which is definitely not our problem.) I suppose that if we update RFC 6761 it would be polite to send a note to ICANN reminding them that anyone who wants to add a new TLD to the DNS should consider as one of the risks that it collides with a name that is excluded for technical reasons, but I see no reason to go farther than that. R's, John ___ 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
... and this was only intended to go to Richard and Ed, not waste the entire WGs time with my bizarre imaginings... W On Wed, Jul 1, 2015 at 4:59 PM, Warren Kumari war...@kumari.net wrote: On Wed, Jul 1, 2015 at 3:05 PM, Richard Barnes r...@ipv.sx wrote: On Wed, Jul 1, 2015 at 2:54 PM, Edward Lewis edward.le...@icann.org 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'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. The thing that got .onion to the IETF is that they needed to be official. (So that they could get certificates for .onion names.) Until they get an RFC 6761 registration, they're in a grey zone of being neither officially DNS names nor officially not DNS names. ISTM that the benefit of .alt is that it creates a clearly-not-normal-DNS zone. We would have to check with the CAs, but I think that that would do a lot to prevent issues like what .onion ran into. My hope would be that that benefit would make it appealing enough for at least some of these other pseudo-TLDs to tolerate the switching cost. It also provides the ability for the IETF to push back more easily on some applications. Warning: The following is how this plays out in my mind. Many things in here are a little odd, but, hey, it's my imagination, not yours... Dramatis personae: Applicant: A young, eager developer. IETF (personification): Played by someone who looks like a cross between Spencer Dawkins and Scott Bradner. For some reason speaks with a strong Scottish accent... Without .alt: (Applicant enters stage left) Applicant: I'd like .foo added to the SUN registry please. I've developed a resolution service that maps from names of cartoon characters to IP addresses, and is use by many many people. It meets all the RFC6761 requirements IETF: You did a bad thing. You should not have simply squatted on a label. Anyway, a namespace made up of cartoon character names is silly... Applicant: But this meets all of the 6761 requirements, and I've got dozens of people using this. Anyway, I didn't really have an alternative, did I? How is anyone supposed to innovate in the namespace?! IETF: Well, erm you should have... e... um... ideally you would... err... Yeah, OK, we'll make .foo be a Special Use Name, but don't do it again, OK?! (Applicant skips off stage left, IETF plods off stage right, looking dejected) With .alt: (Applicant enters stage left) Applicant: I'd like .foo added to the SUN registry please. I've developed a resolution service that maps from names of cartoon characters to IP addresses, and is use by many many people. It meets all the RFC6761 requirements IETF: You did a bad thing. You should not have simply squatted on a label; we have a defined process and location for this sort of thing, it's called .alt IETF waves sheaf of papers Anyway, cartoon characters as a basis for a namespace? Really? Applicant: But I didn't know about .alt... and I've got dozens of users, dozens I tell you...shakes fist IETF: Sorry, ignorantia legis neminem excusat. Applicant: Fine (Applicant stomps off stage left in a bit of a huff, IETF looks remarkably smug, then exits stage right to further examine navel) [ Unfortunately the IETF ends up looking like a bit of an ass here, but redeems itself later by doing something helpful for the community, or, at least, entertaining... Hey, I did warn you that things in my brain are often a little, um, surreal... ] The IETF can still add things to the RFC6761 / RFC6761bis registries, but at least has: A: provided an alternative for people who /want/ to do the right thing and B: more of a leg to stand on if we need to push back on nuisance applications in the future. W --Richard ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is
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] More after onion? was Re: Some distinctions and a request
Hi Ed, On Wed, Jul 01, 2015 at 12:26:43PM +, Edward Lewis wrote: I'm sympathetic to the use the path of least resistance - e.g., use names that syntactically are DNS names I note that the Subject: line of your note still contains a vestigial reference to the thread I started recently on this, and your message nevertheless returns to collapsing domain names and DNS names. I don't know whether I've simply failed to explain the distinction I'm trying to make, or whether you reject the premise. Could you please be clear about which it is? To me, the _point_ of onion. is that it is not a DNS name. You're right that it has the same syntax -- because it is a domain name, but not (intended to be) a DNS name. The registration of the name in the special use registry would achieve that end. You might object that this distinction is extremely hard, because there's nothing about the label itself to signal this namespace shift, and unaware clients will therefore automatically just treat such names as DNS names, not special-use domain names. I happen to agree with that, but we cannot hold back this tide: it was let loose once local. became an in-band protocol switch, without any registration, in Apple's widely-deployed Bonjour service. We might wish that people hadn't abused the namespace to turn it into protocol switches as well as everything else, but the history of SRV through Bonjour shows that this technique is popular and unlikely to go away. Commanding the tide to stay back when you are neck deep in water is not likely to work. Therefore, I claim, we need to make some clear distinctions and understand what has actually happened, and then adjust to the new reality. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
