Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01
On 3/28/16 9:08 PM, George Michaelson wrote: > On Tue, Mar 29, 2016 at 1:36 PM, Andrew Sullivan > wrote: >> That's in effect an argument that the special-names registrations are not >> special. I >> do not agree with that claim. > >>From an extreme point of view (which clearly, contextually, I hold) > thats exactly what I think I fundamentally agree with, in what Alain > is saying: The special-names are claiming technological override on > process which ignores the central unity of all name-strings: It doesn't ignore it, it assumes the unity of namespace. otherwise what would be the point? you'd just go off and do your own thing... > for > ICANN, for the namespace, these are labels like all the others. indeed. > They're asking for a joker-card permit, which I have major issues > with. That aside, they're just like all the others. The qualities they > have in the zone, the records which do or do not exist are in another > plane, orthoginal. > > -G > > ___ > 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 Tue, Mar 29, 2016 at 1:36 PM, Andrew Sullivan wrote: > That's in effect an argument that the special-names registrations are not > special. I > do not agree with that claim. >From an extreme point of view (which clearly, contextually, I hold) thats exactly what I think I fundamentally agree with, in what Alain is saying: The special-names are claiming technological override on process which ignores the central unity of all name-strings: for ICANN, for the namespace, these are labels like all the others. They're asking for a joker-card permit, which I have major issues with. That aside, they're just like all the others. The qualities they have in the zone, the records which do or do not exist are in another plane, orthoginal. -G ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01
George, On Mar 28, 2016, at 6:58 PM, George Michaelson wrote: > Whats the process to understand how, and why a name gets added to the > list? Thats not an IETF question, understandably, but it would be nice > to understand it, even only in outline. As Suzanne mentioned, there is no process as the new gTLD program (for the last round) has been shut down. If/when a new round is created, there will be a new process (one undoubtedly based on the previous process but with enough changes to keep things interesting). As that process does not yet exist, it is difficult to outline it. One might view this as an encouragement for folks within the technical community (and the IETF in particular) to be less reticent to participate in ICANN processes than in the past, despite how excruciatingly painful that might be, but that's just crazy talk. Regards, -drc signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01
On 3/28/16 8:49 PM, David Conrad wrote: > Andrew, > > On Mar 28, 2016, at 8:36 PM, Andrew Sullivan > wrote: >> But I think you're smuggling into your argument a claim that >> they're potentially subject to the IPR and socio-economic issues >> that have been a problem in the DNS root and TLD zones. That's in >> effect an argument that the special-names registrations are not >> special. I do not agree with that claim. > > Just to be clear, you believe that the IESG putting a name onto the > special names registry means that it will then be immune from IPR and > socio-economic issues? What IETF activity is immune to IPR or sociology-econmic issues? > Thanks, -drc > > > > ___ 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
Andrew, On Mar 28, 2016, at 8:36 PM, Andrew Sullivan wrote: > But I think you're smuggling into your argument a claim that > they're potentially subject to the IPR and socio-economic issues that > have been a problem in the DNS root and TLD zones. That's in effect > an argument that the special-names registrations are not special. I > do not agree with that claim. Just to be clear, you believe that the IESG putting a name onto the special names registry means that it will then be immune from IPR and socio-economic issues? Thanks, -drc signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01
> FAQ #22 says CORP, HOME, and MAIL have been deferred indefinitely, Yep. The report on name collisions that ICANN commissioned had the following recommendation (recommendation #1 as a matter of fact, see https://www.icann.org/en/system/files/files/name-collision-mitigation-final-28oct15-en.pdf, top of page 5): "The TLDs .corp, .home, and .mail be referred to the Internet Engineering Task Force (IETF) for potential RFC 1918-like protection/treatment." Unfortunately, the IETF decided agains this treatment, so those strings remain "deferred indefinitely." > but along with the four remaining applications for MAIL, there are 5 for CORP > and 10 for HOME, and they haven't given back the $3.5 million in application > fees, either. I might be wrong, but I believe that is because the applicants have, to date, refused to terminate their applications for those strings. Hard to give back money if people refuse to accept it, no? Regards, -drc (speaking only for myself) signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01
On Tue, Mar 29, 2016 at 02:14:43AM +, Alain Durand wrote: > All strings, regardless of the intend to be placed on the 6761 registry or in > the DNS root zone, are potentially subjects to IPR & socio-economic issues. > > There is nothing circular here. Do you agree or not with that statement? If I knew what "potentially subject to IPR & socio-economic issues", I might. But I think you're smuggling into your argument a claim that they're potentially subject to the IPR and socio-economic issues that have been a problem in the DNS root and TLD zones. That's in effect an argument that the special-names registrations are not special. I do not agree with that claim. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01
On Mar 28, 2016, at 10:16 PM, "John Levine" wrote: > In article > you > write: >> Whats the process to understand how, and why a name gets added to the >> list? Thats not an IETF question, understandably, but it would be nice >> to understand it, even only in outline. > > The reserved names are in the ICANN application guidebook. There was > a multi-year process of breathtaking complexity to come up with the > rules in the guidebook. It's also worth noting that since the recent new gTLD round is closed, with no new applications being accepted, it's not clear that there's a current process. The assorted committees and working groups and advisory committees are gearing up to provide their input to policy and process for the presumed next round of new gTLDs. I won't venture to predict the contents of that future Applicant Guidebook. Suzanne ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01
In article you write: >Whats the process to understand how, and why a name gets added to the >list? Thats not an IETF question, understandably, but it would be nice >to understand it, even only in outline. The reserved names are in the ICANN application guidebook. There was a multi-year process of breathtaking complexity to come up with the rules in the guidebook. The de-facto reservation of COMP, HOME, and MAIL was later when it became apparent that despite the complex process they'd neglected to consider collisions with existing informal name uses. The collision mitigation framework is described here: https://www.icann.org/en/system/files/files/name-collision-framework-30jul14-en.pdf R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01
> On Mar 28, 2016, at 10:05 PM, Andrew Sullivan wrote: > > On Mon, Mar 28, 2016 at 10:32:41PM +, Alain Durand wrote: > >> My perspective is that, at the end of the day, a name is a name is a >> name. > > Your argument is now circular. You cannot use a premise that no names > are special as a premise to draw your conclusion that no names are > special. I’m sorry my point remains unclear. Let me try again: All strings, regardless of the intend to be placed on the 6761 registry or in the DNS root zone, are potentially subjects to IPR & socio-economic issues. There is nothing circular here. Do you agree or not with that statement? Alain. smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01
On Mon, Mar 28, 2016 at 10:32:41PM +, Alain Durand wrote: > My perspective is that, at the end of the day, a name is a name is a > name. Your argument is now circular. You cannot use a premise that no names are special as a premise to draw your conclusion that no names are special. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01
AFRINIC IANA-SERVERS NRO ALAC ICANN RFC-EDITOR APNIC IESG RIPE ARIN IETF ROOT-SERVERS ASO INTERNIC RSSAC CCNSO INVALID SSAC EXAMPLE IRTF TEST GAC ISTF TLD NSO LACNIC WHOIS GTLD-SERVERS LOCAL WWW IAB LOCALHOST IANA NIC plus "test" or "example" translated into other languages. They also reserved OLYMPIC and REDCROSS in about a dozen languages but said those might change. Wasn't MAIL added to that list a little later on? Nope, look at the ICANN new gTLD web site. There were six applications for MAIL. Two, from 1&1 and Afilias, have been withdrawn. The other four, from Amazon, Google, Donuts, and whitepages.com, are all on hold. https://www.icann.org/resources/pages/name-collision-ro-faqs-2014-08-01-en FAQ #22 says CORP, HOME, and MAIL have been deferred indefinitely, but along with the four remaining applications for MAIL, there are 5 for CORP and 10 for HOME, and they haven't given back the $3.5 million in application fees, either. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01
Whats the process to understand how, and why a name gets added to the list? Thats not an IETF question, understandably, but it would be nice to understand it, even only in outline. -George On Tue, Mar 29, 2016 at 11:30 AM, Paul Wouters wrote: > On Mon, 29 Mar 2016, John Levine wrote: > >> ICANN has its own list of reserved names that you can't apply for. >> In the recent round it was all of these: >> >> AFRINIC IANA-SERVERS NRO ALAC ICANN RFC-EDITOR APNIC IESG RIPE ARIN >> IETF ROOT-SERVERS ASO INTERNIC RSSAC CCNSO INVALID SSAC EXAMPLE IRTF >> TEST GAC ISTF TLD NSO LACNIC WHOIS GTLD-SERVERS LOCAL WWW IAB >> LOCALHOST IANA NIC >> >> plus "test" or "example" translated into other languages. They also >> reserved OLYMPIC and REDCROSS in about a dozen languages but said >> those might change. > > > Wasn't MAIL added to that list a little later on? > > Paul > > > ___ > 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] draft-adpkja-dnsop-special-names-problem-01
On Mon, 29 Mar 2016, John Levine wrote: ICANN has its own list of reserved names that you can't apply for. In the recent round it was all of these: AFRINIC IANA-SERVERS NRO ALAC ICANN RFC-EDITOR APNIC IESG RIPE ARIN IETF ROOT-SERVERS ASO INTERNIC RSSAC CCNSO INVALID SSAC EXAMPLE IRTF TEST GAC ISTF TLD NSO LACNIC WHOIS GTLD-SERVERS LOCAL WWW IAB LOCALHOST IANA NIC plus "test" or "example" translated into other languages. They also reserved OLYMPIC and REDCROSS in about a dozen languages but said those might change. Wasn't MAIL added to that list a little later on? Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01
>What do you mean by "reserved in the previous ICANN gTLD round"? ICANN has its own list of reserved names that you can't apply for. In the recent round it was all of these: AFRINIC IANA-SERVERS NRO ALAC ICANN RFC-EDITOR APNIC IESG RIPE ARIN IETF ROOT-SERVERS ASO INTERNIC RSSAC CCNSO INVALID SSAC EXAMPLE IRTF TEST GAC ISTF TLD NSO LACNIC WHOIS GTLD-SERVERS LOCAL WWW IAB LOCALHOST IANA NIC plus "test" or "example" translated into other languages. They also reserved OLYMPIC and REDCROSS in about a dozen languages but said those might change. Presumably if there's another round, there will be a similar list. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01
I'm sorry if my point was not clear. My perspective is that, at the end of the day, a name is a name is a name. Being on the 6761 registry or in the DNS root zone is fundamentally irrelevant when it comes to IPR and other related socio-political issues. The same concerns apply. Alain, speaking solely for myself. > On Mar 28, 2016, at 5:54 PM, Ralph Droms wrote: > > >> On Mar 28, 2016, at 5:41 PM 3/28/16, Alain Durand >> wrote: >> >> Andrew, >> >> This is the very registration in 6761 that makes (or would make) those names >> special, i.e. not ordinary. Those name could as well have been reserved in >> the previous ICANN gTLD round or in the next one for regular DNS purpose. >> The is nothing "non-ordinary" about the strings themselves... > > Let me make the point again that the document that records the Standards > Action or IESG approval is what designates a name as a special-use name. > Therefore, any designation as a special-use name will have IETF consensus. > RFC 6761 only documents the process for recording that designation in the > Special-Use Names registry. > > What do you mean by "reserved in the previous ICANN gTLD round"? Do you mean > "assigned to some entity", in which case it's highly unlikely the IETF would > come to consensus about designating such a name as a special-use name. Once > a name has been designated as a special-use name, it is no longer part of the > DNS namespace available for assignment by ICANN. > > But, I may be misunderstanding your point... > > - Ralph > >> >> Alain, speaking solely for myself. >> >>> On Mar 28, 2016, at 3:23 PM, Andrew Sullivan >>> wrote: >>> >>> Hi, >>> >>> I think I've answered these questions before, but in case not, here's >>> what I think: >>> On Mon, Mar 28, 2016 at 12:15:15PM -0700, David Conrad wrote: In what way is ONION not "ordinary"? >>> >>> The label "onion" indicates that an alternative resolution path is >>> intended. Moreover, an additional underlying networking protocol is >>> expected to be in use. >>> In what way are GNU, ZKEY, BIT, EXIT, I2P, etc., "ordinary" or not "ordinary" >>> >>> An alternative (to DNS) resolution protocol is similarly expected. In >>> some cases, additional underlying network protocols are expected. In >>> other cases, it is merely an indication of alternative resolution, >>> with no alternative underlying network technology. (Part of the >>> reason I wanted the different cases separated is because I think it's >>> an open question whether a different naming protocol with _no_ >>> difference in the underlying technology is a legitimate use of 6761.) >>> Are HOME, CORP, and MAIL "ordinary"? >>> >>> Yes. They're expected to resolve in ordinary DNS contexts, though not >>> necessarily the global one. My own view is that these ought to be >>> outside the 6761 registry unless some ICANN-based PDP were to >>> determine that they should be permanently reserved and that the >>> reservation ought to be sought in the 6761 registry. >>> >>> Best regards, >>> >>> A (as usual, for myself) >>> >>> -- >>> Andrew Sullivan >>> a...@anvilwalrusden.com >>> >>> ___ >>> 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 > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01
> On Mar 28, 2016, at 5:41 PM 3/28/16, Alain Durand > wrote: > > Andrew, > > This is the very registration in 6761 that makes (or would make) those names > special, i.e. not ordinary. Those name could as well have been reserved in > the previous ICANN gTLD round or in the next one for regular DNS purpose. The > is nothing "non-ordinary" about the strings themselves... Let me make the point again that the document that records the Standards Action or IESG approval is what designates a name as a special-use name. Therefore, any designation as a special-use name will have IETF consensus. RFC 6761 only documents the process for recording that designation in the Special-Use Names registry. What do you mean by "reserved in the previous ICANN gTLD round"? Do you mean "assigned to some entity", in which case it's highly unlikely the IETF would come to consensus about designating such a name as a special-use name. Once a name has been designated as a special-use name, it is no longer part of the DNS namespace available for assignment by ICANN. But, I may be misunderstanding your point... - Ralph > > Alain, speaking solely for myself. > >> On Mar 28, 2016, at 3:23 PM, Andrew Sullivan wrote: >> >> Hi, >> >> I think I've answered these questions before, but in case not, here's >> what I think: >> >>> On Mon, Mar 28, 2016 at 12:15:15PM -0700, David Conrad wrote: >>> In what way is ONION not "ordinary"? >> >> The label "onion" indicates that an alternative resolution path is >> intended. Moreover, an additional underlying networking protocol is >> expected to be in use. >> >>> In what way are GNU, ZKEY, BIT, EXIT, I2P, etc., "ordinary" or not >>> "ordinary" >> >> An alternative (to DNS) resolution protocol is similarly expected. In >> some cases, additional underlying network protocols are expected. In >> other cases, it is merely an indication of alternative resolution, >> with no alternative underlying network technology. (Part of the >> reason I wanted the different cases separated is because I think it's >> an open question whether a different naming protocol with _no_ >> difference in the underlying technology is a legitimate use of 6761.) >> >>> Are HOME, CORP, and MAIL "ordinary"? >> >> Yes. They're expected to resolve in ordinary DNS contexts, though not >> necessarily the global one. My own view is that these ought to be >> outside the 6761 registry unless some ICANN-based PDP were to >> determine that they should be permanently reserved and that the >> reservation ought to be sought in the 6761 registry. >> >> Best regards, >> >> A (as usual, for myself) >> >> -- >> Andrew Sullivan >> a...@anvilwalrusden.com >> >> ___ >> 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 signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01
Andrew, This is the very registration in 6761 that makes (or would make) those names special, i.e. not ordinary. Those name could as well have been reserved in the previous ICANN gTLD round or in the next one for regular DNS purpose. The is nothing "non-ordinary" about the strings themselves... Alain, speaking solely for myself. > On Mar 28, 2016, at 3:23 PM, Andrew Sullivan wrote: > > Hi, > > I think I've answered these questions before, but in case not, here's > what I think: > >> On Mon, Mar 28, 2016 at 12:15:15PM -0700, David Conrad wrote: >> In what way is ONION not "ordinary"? > > The label "onion" indicates that an alternative resolution path is > intended. Moreover, an additional underlying networking protocol is > expected to be in use. > >> In what way are GNU, ZKEY, BIT, EXIT, I2P, etc., "ordinary" or not "ordinary" > > An alternative (to DNS) resolution protocol is similarly expected. In > some cases, additional underlying network protocols are expected. In > other cases, it is merely an indication of alternative resolution, > with no alternative underlying network technology. (Part of the > reason I wanted the different cases separated is because I think it's > an open question whether a different naming protocol with _no_ > difference in the underlying technology is a legitimate use of 6761.) > >> Are HOME, CORP, and MAIL "ordinary"? > > Yes. They're expected to resolve in ordinary DNS contexts, though not > necessarily the global one. My own view is that these ought to be > outside the 6761 registry unless some ICANN-based PDP were to > determine that they should be permanently reserved and that the > reservation ought to be sought in the 6761 registry. > > Best regards, > > A (as usual, for myself) > > -- > Andrew Sullivan > a...@anvilwalrusden.com > > ___ > 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
[DNSOP] WG last calls on dnssd WG drafts of interest to dnsop
The dnssd WG is currently conducting two WG last calls of interest to dnsop WG participants: draft-ietf-dnssd-mdns-dns-interop-02 draft-ietf-dnssd-hybrid-03 Both of these last calls are scheduled to conclude on March 31. The dnssd WG chairs would greatly appreciate review and feedback on these documents, posted to dn...@ietf.org Results of the WG last calls will be reviewed at the dnssd WG meeting in Buenos Aires. - Ralph and Tim signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01
Hi, I think I've answered these questions before, but in case not, here's what I think: On Mon, Mar 28, 2016 at 12:15:15PM -0700, David Conrad wrote: > In what way is ONION not "ordinary"? The label "onion" indicates that an alternative resolution path is intended. Moreover, an additional underlying networking protocol is expected to be in use. > In what way are GNU, ZKEY, BIT, EXIT, I2P, etc., "ordinary" or not "ordinary" An alternative (to DNS) resolution protocol is similarly expected. In some cases, additional underlying network protocols are expected. In other cases, it is merely an indication of alternative resolution, with no alternative underlying network technology. (Part of the reason I wanted the different cases separated is because I think it's an open question whether a different naming protocol with _no_ difference in the underlying technology is a legitimate use of 6761.) > Are HOME, CORP, and MAIL "ordinary"? Yes. They're expected to resolve in ordinary DNS contexts, though not necessarily the global one. My own view is that these ought to be outside the 6761 registry unless some ICANN-based PDP were to determine that they should be permanently reserved and that the reservation ought to be sought in the 6761 registry. Best regards, A (as usual, for myself) -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01
Andrew, On Mar 28, 2016, at 11:33 AM, Andrew Sullivan wrote: > I am pretty sure that > whatever could get registered under RFC 6761, it would not be an > ordinary name in the DNS. What do you mean by "ordinary"? In what way is ONION not "ordinary"? In what way are GNU, ZKEY, BIT, EXIT, I2P, etc., "ordinary" or not "ordinary" Are HOME, CORP, and MAIL "ordinary"? Thanks, -drc signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01
Ralph, On Mar 28, 2016, at 6:43 AM, Ralph Droms wrote: > First, I'll emphasize that the process of designating a name as "special use" > is separate from the mechanical process of actually adding a new name to the > Special-Use Names registry. Agreed. > RFC 6761 explicitly defines the latter process, and implicitly requires open > IETF review for the former process. In my opinion, we can focus on the > former process, of deciding whether a name should be designated as having a > special use. This process may have, as you point out, issues regarding > trademarks, association of names with organizations, and many others. > > I'm not trying to wish those issues away, and I don't think Andrew is either. > Rather, speaking only for myself, I believe that our open process of > community review and consensus is an appropriate starting point for > discussion. In my limited experience, the IETF process is great for (a subset of) technical matters. It has perhaps been less than great in social/political/economic matters and I thought there was a general reluctance for the IETF to go that direction. I am a bit surprised there appears to be a desire, implicit or not, to apply the IETF process in these non-technical areas, particularly as many assume that part of the reason for 2860 was specifically because the IETF wasn't, at least historically, particularly well suited to or interested in dealing with these kinds of non-technical issues. I am a bit curious as to the rationale behind the change of heart. Regards, -drc (Speaking only for myself) signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01
>any domain names you want, but the safe choice for avoiding operational and >policy collisions with >DNS protocol and namespace is to root your chosen domain name space under >.alt"? > >Which technical issues would persist? I can think of two, plus one non-technical one. The first technical one is whether there is a registry for .alt names and if so how it'd operate. From prior discussion, some people think it should be FCFS to prevent ambiguity. I think that would be utterly counterproductive since it'd lead to a squatter rush, and anyway there's no way to enforce that people use names they've registered. FCFS with unlimited name collisions would be OK, to help people figure out where to get the code to implement various name things they've come across. The other, which is a can of worms, is whether we want to define protocol switches. At this point, there's an implicit switch used for .local at the DNS level, where you give it a name and it returns an IP address that might have come from an A or record or might have come from somewhere else. And there's another higher level one at the socket level used for .onion, where you give it a name and it gives you back an open socket that might be a TCP or UDP connection to an addresss found in an A or record, or it might be something else. If there's to be any hope that people could use more than one of these hacks at a time, a protocol switch would be a big help. 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. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] The right alt string (was Re: draft-adpkja-dnsop-special-names-problem-01)
On Mon, Mar 28, 2016 at 06:31:57PM -, John Levine wrote: > The URI definition in RFC 3986 says the host is a > "reg-name" which refers to section 2.1 of RFC 1123 which says a > hostname is letters, digits, and hyphens Duh. Now that you mention this, I realise that I actually had this idea once before and chased that set of references and drew the same conclusion. So much for relying on my memory, but thank you for hitting me again with the clue-by-four. Maybe 3d time will be a charm. A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01
Hi, On Mon, Mar 28, 2016 at 01:11:56PM +, Alain Durand wrote: > ICANN history has shown us that anything that has a name attached to it is > a potentially candidate for such a dispute. I am not sure I accept this premise. It seems to me that ICANN's history is bound up with names in the DNS. I am pretty sure that whatever could get registered under RFC 6761, it would not be an ordinary name in the DNS. It seems to me for your argument to work, you need to show that registrations of names that cannot be resolved as part of the normal DNS resolution mechanism would also be subject to such a dispute. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] The right alt string (was Re: draft-adpkja-dnsop-special-names-problem-01)
>_alt or even _ would be better labels for this purpose. Part of the >goal has been to make these strings usable in applications (in "domain >name slots", as 5890 calls them). Would "_" work? Would "_alt"? I >have doubts, but I thought I'd ask. I don't think so. The URI definition in RFC 3986 says the host is a "reg-name" which refers to section 2.1 of RFC 1123 which says a hostname is letters, digits, and hyphens. So underscores won't work in names in web browsers which are, as far as I can tell, the main place people are likely to use these names-that-are-not-names. Nice thought, though. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01
Sent from my iPhone > On Mar 28, 2016, at 1:31 PM, Suzanne Woolf wrote: > > As a practical focus: sometime ago, DNSOP adopted and then parked > https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/. This draft > proposes a special use names registry entry that would be expected to > function as the rightmost label in names intended for resolution outside of > the DNS protocol: something of a meta-protocol switch. Such a solution as the clear benefit to get the IETF out of the name evaluation quagmire. The more I look into it, the more I'm drawn to a solution that would look like this: apply 6761 one last time to create .alt (or ._ or whatever) and *then* close the registry. Alain, speaking solely for myself. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] The right alt string (was Re: draft-adpkja-dnsop-special-names-problem-01)
On Mon, Mar 28, 2016 at 01:32:29PM -0400, Suzanne Woolf wrote: > > As a practical focus: sometime ago, DNSOP adopted and then parked > https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/. This draft > proposes a special use names registry entry that would be expected to > function as the rightmost label in names intended for resolution outside of > the DNS protocol: something of a meta-protocol switch. > One of the possibly amusing things that struck me lately is that marking out the string even more clearly for this purpose might take some of the venom from the sting. In that context, let me ask whether _alt or even _ would be better labels for this purpose. Part of the goal has been to make these strings usable in applications (in "domain name slots", as 5890 calls them). Would "_" work? Would "_alt"? I have doubts, but I thought I'd ask. A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01
Dear colleagues, Thanks to John for this input, and all who've commented so far; but I'd like to use John's comment to slightly re-focus this conversation. It has seemed to me from the beginning of this discussion, and even the establishment of the special use names registry, that it's fairly easy to get caught up in this aspect of the discussion, which focuses on the implications of using specific strings in specific contexts. In particular, we tend to focus on possible collisions between the special use names registry and the registry representing the public DNS root zone, and on hand-wringing over the fact those registries are operated by different parties. While it's true there's potential for such collisions, and easy to argue that the potential needs attention in forming any solutions, potential collision between those registries is not necessarily the only or the biggest issue we have to address. So I think it would be good to consider the broader issues, which are not specific to which strings are used in which context. It seems to me that "the bigger picture" needs to consider that the use of domain names is diverging in certain ways from practices and procedures for allocating names for use in other contexts, including but not limited to the DNS protocol context. This is leading to various complications, including possible (and even actual) collisions among domain names as used in different contexts; uncertainty around whether a given name can or can't be instantiated in a given context; the interaction between IETF registries and what's essentially protocol development taking place outside of IETF process; and some other architectural and operational issues arising from the fact people find domain names useful outside of DNS protocol (and indeed, they always have). I'd like very much to see us separate issues that depend on *which* strings are used, such as whether anyone's process includes a provision for avoiding a specific type of collision, from issues we'd have even if we've set aside a subset of the namespace structured to avoid policy issues arising from the use of the domain name space in the DNS root. As a practical focus: sometime ago, DNSOP adopted and then parked https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/. This draft proposes a special use names registry entry that would be expected to function as the rightmost label in names intended for resolution outside of the DNS protocol: something of a meta-protocol switch. Assuming we understand the problems a bit better now than we did before, particularly given the experience of .onion, which of the problems we've seen would be solved by telling people "You can use any domain names you want, but the safe choice for avoiding operational and policy collisions with DNS protocol and namespace is to root your chosen domain name space under .alt"? Which technical issues would persist? If, as some people have argued, the only problem we really have here is separating domain names that might be used in the DNS from domain names available for use in other resolution contexts, it may be that ".alt" is both necessary and sufficient to support future experiment and development in the use of domain names. Will that do it? If not, why not? The question of how to think about name resolution context in the internet in general-- even separately from domain names-- is the departure point for the ARCING BoF. But the concerns addressed in the special-names-problem draft, regarding how domain names are used by DNS and possibly other name resolution protocols, seem to be still within scope for DNSOP. thanks, Suzanne On Mar 28, 2016, at 12:35 PM, John Levine wrote: >> I understand Andrew's point to be that the decision process regarding >> trademark, etc., disputes will >> take place as part of the review process inherent in meeting the >> requirements for publishing 'an IETF >> "Standards Action" or "IESG Approval" specification', which is required in >> RFC 6761 for adding a name >> to the registry. > > I read it somewhat differently: trademark issues are not technical and > insofar as they're anyone's problem, they're ICANN's. There's lots of > other non-technical arguments about who gets to put names where, such > as the endless argument about .AFRICA which is now taking a detour > through U.S. courts. > > One of the things to consider in a 6761 evaluation is whether it's > really a technical proposal or whether someone's trying to make an end > around the ICANN process. If it's really a trademark dispute or > something else that isn't technically different from the DNS, it's not > our problem. > > R's, > John > > > > ___ > 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] draft-adpkja-dnsop-special-names-problem-01
>I understand Andrew's point to be that the decision process regarding >trademark, etc., disputes will >take place as part of the review process inherent in meeting the requirements >for publishing 'an IETF >"Standards Action" or "IESG Approval" specification', which is required in RFC >6761 for adding a name >to the registry. I read it somewhat differently: trademark issues are not technical and insofar as they're anyone's problem, they're ICANN's. There's lots of other non-technical arguments about who gets to put names where, such as the endless argument about .AFRICA which is now taking a detour through U.S. courts. One of the things to consider in a 6761 evaluation is whether it's really a technical proposal or whether someone's trying to make an end around the ICANN process. If it's really a trademark dispute or something else that isn't technically different from the DNS, it's not our problem. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Document Action: 'Client Subnet in DNS Queries' to Informational RFC (draft-ietf-dnsop-edns-client-subnet-07.txt)
The IESG has approved the following document: - 'Client Subnet in DNS Queries' (draft-ietf-dnsop-edns-client-subnet-07.txt) as Informational RFC This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Benoit Claise and Joel Jaeggli. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-client-subnet/ Technical Summary This draft defines an EDNS0 extension to carry information about the network that originated a DNS query, and the network for which the subsequent response can be cached. Working Group Summary This draft originally showed up in dnsext working group and was highly criticized and eventually dropped. Since then, dnsext closed down, the ability to get EDNS option codes because a simple expert review process and not Internet Standard, and the scope of this document was changed to document what *currently* exists in the world, and how it behaves. The extensive security writeup, several notes about privacy, and a number of implementation and operational notes included in the text were key in getting consensus support to publish the document. Document Quality There are security issues with this version, as raised by various people. They are correct, and the intent is not to correct the security flaws with this document, but to describe how this option behaves currently. It is suggested a new version will be worked on in a year which addresses the security issues, and addresses other issues about this option. Personnel Document Shepherd: Suzanne Woolf Area Director: Joel Jaggeli ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01
> On Mar 28, 2016, at 9:11 AM 3/28/16, Alain Durand > wrote: > > On 3/26/16, 11:30 PM, "DNSOP on behalf of Andrew Sullivan" > wrote: > >> I guess my point was merely that your examples seemed only to be >> arguing from this or that trade or service mark to some conclusion >> that the IETF had an obvious problem to contemplate. But the >> registrations in 6761 are, not going to be part of such disputes; or, >> if they are, it is a problem the IETF will have confronted in its >> evaluation. Waving around possible trademark cases as things one >> ought to worry about seems to me not to help the discussion. > > > Andrew, > > This is the crux of the issue. I have a hard time to believe the statement > you are making above > that future RFC6761 registrations will not be the object of trademark & co > disputes. I understand Andrew's point to be that the decision process regarding trademark, etc., disputes will take place as part of the review process inherent in meeting the requirements for publishing 'an IETF "Standards Action" or "IESG Approval" specification', which is required in RFC 6761 for adding a name to the registry. > ICANN history has shown us that anything that has a name attached to it is > a potentially candidate for such a dispute. > It may or may not have been the case for Onion or Local, but we have no > guarantees it will not > be the case for the following ones. > > Now, your second statement that the IETF will confront such potential > claims during evaluation > is where I personally express serious reservations. As I mentioned in a > previous email, > I do not believe the IETF is well equipped to deal with that. Wishing > those issues away > is, IMHO, the very thing that is not helping in this discussion. I trust > this community > to make good technical decisions, but I¹m not ready to sign a blank check > on its ability > to make good decisions in the trademark/name policy arena. First, I'll emphasize that the process of designating a name as "special use" is separate from the mechanical process of actually adding a new name to the Special-Use Names registry. RFC 6761 explicitly defines the latter process, and implicitly requires open IETF review for the former process. In my opinion, we can focus on the former process, of deciding whether a name should be designated as having a special use. This process may have, as you point out, issues regarding trademarks, association of names with organizations, and many others. I'm not trying to wish those issues away, and I don't think Andrew is either. Rather, speaking only for myself, I believe that our open process of community review and consensus is an appropriate starting point for discussion. - Ralph > > > Alain, speaking for myself. > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01
On 3/26/16, 11:30 PM, "DNSOP on behalf of Andrew Sullivan" wrote: >I guess my point was merely that your examples seemed only to be >arguing from this or that trade or service mark to some conclusion >that the IETF had an obvious problem to contemplate. But the >registrations in 6761 are, not going to be part of such disputes; or, >if they are, it is a problem the IETF will have confronted in its >evaluation. Waving around possible trademark cases as things one >ought to worry about seems to me not to help the discussion. Andrew, This is the crux of the issue. I have a hard time to believe the statement you are making above that future RFC6761 registrations will not be the object of trademark & co disputes. ICANN history has shown us that anything that has a name attached to it is a potentially candidate for such a dispute. It may or may not have been the case for Onion or Local, but we have no guarantees it will not be the case for the following ones. Now, your second statement that the IETF will confront such potential claims during evaluation is where I personally express serious reservations. As I mentioned in a previous email, I do not believe the IETF is well equipped to deal with that. Wishing those issues away is, IMHO, the very thing that is not helping in this discussion. I trust this community to make good technical decisions, but I¹m not ready to sign a blank check on its ability to make good decisions in the trademark/name policy arena. Alain, speaking for myself. smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop