From: owner-wg-c-digest@dnso.org (WG-C-DIGEST) To: wg-c-digest@dnso.org Subject: WG-C-DIGEST V1 #82 Reply-To: Sender: owner-wg-c-digest@dnso.org Errors-To: owner-wg-c-digest@dnso.org Precedence: bulk WG-C-DIGEST Tuesday, April 11 2000 Volume 01 : Number 082 ---------------------------------------------------------------------- Date: Tue, 11 Apr 2000 12:43:46 -0300 From: "Tony Linares" Subject: RE: [wg-c] CONSENSUS CALLS -- THIS IS IT PROPOSED ROUGH CONSENSUS ITEM NUMBER ONE: Yes PROPOSED ROUGH CONSENSUS ITEM NUMBER TWO: Yes PROPOSED ROUGH CONSENSUS ITEM NUMBER THREE: Yes This message is from: Gilbert Anthony Linares Travel Services, Inc. PO Box 16187 San Juan, PR 00908-6187 USA Tel. (787) 724-6281 Fax (787) 725-6245 www.destinationpr.com ------------------------------ Date: Tue, 11 Apr 2000 13:26:43 -0400 From: James Love Subject: Re: [wg-c] CONSENSUS CALLS -- THIS IS IT > PROPOSED ROUGH CONSENSUS ITEM NUMBER ONE > > The initial rollout should include a range of top level domains, from open > TLDs to restricted TLDs with more limited scope. YES > PROPOSED ROUGH CONSENSUS ITEM NUMBER TWO > > Criteria for assessing a gTLD application, subject to current technical > constraints and evolving technical opportunities, should be based on all of > the following principles : > > 1. Meaning: An application for a TLD should explain the significance of the > proposed TLD string, and how the applicant contemplates that the new TLD > will be perceived by the relevant population of net users. The application > may contemplate that the proposed TLD string will have its primary semantic > meaning in a language other than English. > > 2. Enforcement: An application for a TLD should explain the mechanism for > charter enforcement where relevant and desired. > > 3. Differentiation: The selection of a TLD string should not confuse net > users, and so TLDs should be clearly differentiated by the string and/or by > the marketing and functionality associated with the string. > > 4. Diversity: New TLDs are important to meet the needs of an expanding > Internet community. They should serve both commercial and non-commercial > goals. > > 5. Honesty: A TLD should not unnecessarily increase opportunities for > malicious or criminal elements who wish to defraud net users. > > 6. Competition: The authorization process for new TLDs should not be used > as a means of protecting existing service providers from competition. YES. And nice job working on this. > PROPOSED ROUGH CONSENSUS ITEM NUMBER THREE > > WG-C recommends that the Names Council charter a working group to develop > policy regarding internationalized domain names using non-ASCII characters. YES. ======================================================= James Love, Director | http://www.cptech.org Consumer Project on Technology | mailto:love@cptech.org P.O. Box 19367 | voice: 1.202.387.8030 Washington, DC 20036 | fax: 1.202.234.5176 ======================================================= ------------------------------ Date: Tue, 11 Apr 2000 10:25:40 -0700 From: "Christopher Ambler" Subject: Re: [wg-c] CONSENSUS CALLS -- THIS IS IT > > PROPOSED ROUGH CONSENSUS ITEM NUMBER ONE YES > > PROPOSED ROUGH CONSENSUS ITEM NUMBER TWO YES > > PROPOSED ROUGH CONSENSUS ITEM NUMBER THREE NO. This is policy, not technical management, by any means. Christopher ------------------------------ Date: Tue, 11 Apr 2000 10:49:13 -0700 From: "Mark C. Langston" Subject: Re: [wg-c] CONSENSUS CALLS -- THIS IS IT > PROPOSED ROUGH CONSENSUS ITEM NUMBER ONE > > The initial rollout should include a range of top level > domains, from open TLDs to restricted TLDs with more limited scope. I object to the form, but agree that the initial rollout should include both generic, non-chartered TLDs and chartered TLDs. If I may vote as to the substance, then my vote is YES. However, if I'm forced to adhere to the item as worded, I cannot assent to it. > PROPOSED ROUGH CONSENSUS ITEM NUMBER TWO > > Criteria for assessing a gTLD application, subject to current technical > constraints and evolving technical opportunities, should be based on all of > the following principles : I vote NO. I object to principles #1, #3, #5. > PROPOSED ROUGH CONSENSUS ITEM NUMBER THREE > > WG-C recommends that the Names Council charter a working group > to develop policy regarding internationalized domain names using > non-ASCII characters. I vote NO. This is beyond the scope of this WG, and should not be delegated to another WG as this is a technical, not policy, issue. Furthermore, I do not believe this belongs in ICANN's hands at all -- it is correctly handled by the IETF group already working on this issue. ICANN should be completely hands-off on this. - -- Mark C. Langston mark@bitshift.org Systems & Network Admin San Jose, CA ------------------------------ Date: Tue, 11 Apr 2000 14:06:37 -0400 From: Jeff Shrewsbury Info Avenue Subject: [wg-c] re: CONSENSUS CALLS -- THIS IS IT Info Avenue votes as follows: PROPOSED ROUGH CONSENSUS ITEM NUMBER ONE -- YES PROPOSED ROUGH CONSENSUS ITEM NUMBER TWO -- YES PROPOSED ROUGH CONSENSUS ITEM NUMBER THREE -- YES Thanks, Jon. js ------------------------------ Date: Tue, 11 Apr 2000 11:14:11 -0700 (PDT) From: "William X. Walsh" Subject: Re: [wg-c] Pre-sold TLDs - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11-Apr-2000 John Charles Broomfield wrote: > Also, how do you guarantee that registrars are not privately > creating their queues ANYWAY? > > It would be nice to say "let's all be good boys, and treat day 0 as any > normal day" but the reality is that there WILL be a fl It's easy. You tell the registry (if it is not a shared registry) that if they are accepting pre registrations they will be in material violation of their contract and could lose their registry, and if it is a shared registry, then you tell the registrars that if they accept preregistrations or have material interest in any company that accepts preregistrations or queues registrations, that they will lose thier accreditation. Give it some bite. - - -- William X. Walsh http://userfriendly.com/ GPG/PGP Key at http://userfriendly.com/wwalsh.gpg - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1c (Mandrake Linux) Comment: Userfriendly Networks http://www.userfriendly.com/ iD8DBQE482tz8zLmV94Pz+IRAuJiAKCzpdbw7FL4chJsdY+4K2R6muYbuQCfWi3U Nx+K8KXywVQGTQOnuYGIYCU= =FXZn - -----END PGP SIGNATURE----- ------------------------------ Date: Tue, 11 Apr 2000 11:16:31 -0700 From: Dave Crocker Subject: [wg-c] "It Won't Work" This note raises a question about Working Group C process. As such, I am requesting a formal response. For development efforts, there are two kinds of disagreements: One is "I don't like the idea" or "I prefer some other idea". That is an argument along the lines of engineering preference. Hence, consensus is a reasonable way to break a deadlock, although it does raise a question about relative qualifications for choosing. The other type of objection is "It won't work". In other words, it is a claim that people's preferences are irrelevant, since the proposed mechanism simply does not function as desired. To deal with this concern, there needs to be an analysis that shows that the mechanism DOES work, or else the mechanism/proposal needs to be fixed. A number of us have raised concerns about the list of "criteria", pointing out that there is no objective way to apply them. As such, they will become yet-another source for subjective debate. In other words, the concern about the criteria is that They Won't Work. What is significant is that there has been no substantive response to this concern. Hence my raising a process challenge. In other words, the current consensus call is irrelevant until basic concerns over the ability to apply these -- or any other -- "criteria" are resolved. Jonathan, please deal with these concerns explicitly, since they concern the ability to USE the "criteria". If there is no clear and reasonable basis for applying the "criteria" then development of them is just an academic exercise. d/ =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 675 Spruce Drive, Sunnyvale, CA 94086 USA ------------------------------ Date: Tue, 11 Apr 2000 14:45:46 -0400 From: "Timothy Denton" Subject: RE: [wg-c] CONSENSUS CALLS -- THIS IS IT This is a multi-part message in MIME format. - ------=_NextPart_000_0000_01BFA3C4.9F655900 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit In order, I vote as follows #1. Yes #2. No #3. Yes PROPOSED ROUGH CONSENSUS ITEM NUMBER ONE The initial rollout should include a range of top level domains, from open TLDs to restricted TLDs with more limited scope. Yes to Item Number One PROPOSED ROUGH CONSENSUS ITEM NUMBER TWO Criteria for assessing a gTLD application, subject to current technical constraints and evolving technical opportunities, should be based on all of the following principles : 1. Meaning: An application for a TLD should explain the significance of the proposed TLD string, and how the applicant contemplates that the new TLD will be perceived by the relevant population of net users. The application may contemplate that the proposed TLD string will have its primary semantic meaning in a language other than English. 2. Enforcement: An application for a TLD should explain the mechanism for charter enforcement where relevant and desired. 3. Differentiation: The selection of a TLD string should not confuse net users, and so TLDs should be clearly differentiated by the string and/or by the marketing and functionality associated with the string. 4. Diversity: New TLDs are important to meet the needs of an expanding Internet community. They should serve both commercial and non-commercial goals. 5. Honesty: A TLD should not unnecessarily increase opportunities for malicious or criminal elements who wish to defraud net users. 6. Competition: The authorization process for new TLDs should not be used as a means of protecting existing service providers from competition. No to Item Number 2 PROPOSED ROUGH CONSENSUS ITEM NUMBER THREE WG-C recommends that the Names Council charter a working group to develop policy regarding internationalized domain names using non-ASCII characters. Yes to Item Number 3 Timothy Denton, BA, BCL tmdenton.com Telecom and Internet Law and Policy 37 Heney Street, Ottawa, Ontario, Canada, K1N 5V6 phone: 1-613-789-5397 tmdenton@magma.ca fax: 789-5398 www.tmdenton.com - ------=_NextPart_000_0000_01BFA3C4.9F655900 Content-Type: text/x-vcard; name="Timothy M. Denton.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Timothy M. Denton.vcf" BEGIN:VCARD VERSION:2.1 N:Denton;Timothy;M. FN:Timothy M. Denton ORG:tmdenton.com TITLE:principal TEL;WORK;VOICE:1-613-789-5397 TEL;HOME;VOICE:1-613-789=3D-5397 TEL;WORK;FAX:1-613-789-5398 TEL;HOME;FAX:1-613-789-5398 ADR;WORK:;;37 Heney Street;Ottawa;Ontario;K1N 5V6;Canada LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:37 Heney Street=3D0D=3D0AOttawa, = Ontario K1N 5V6=3D0D=3D0ACanada ADR;HOME:;;37 Heney Street;Ottawa;Ontario;K1N 5V6;Canada LABEL;HOME;ENCODING=3DQUOTED-PRINTABLE:37 Heney Street=3D0D=3D0AOttawa, = Ontario K1N 5V6=3D0D=3D0ACanada URL: URL:http://www.tmdenton.com EMAIL;PREF;INTERNET:tmdenton@magma.ca REV:20000410T212421Z END:VCARD - ------=_NextPart_000_0000_01BFA3C4.9F655900-- ------------------------------ Date: Tue, 11 Apr 100 14:28:35 -0400 (AST) From: John Charles Broomfield Subject: Re: [wg-c] Pre-sold TLDs And with this proposal you just move the problem one rung down. How do you stop someone from creating a list that will bombard the webpages or email addresses of registrars and selling "preregistrations" in that list? It might work as far as the "feel good" factor is concerned, but as far as effectiveness, it is zilch. Imagine you stopped all registrations right NOW for ".com", scrubbed the database clean, and announced that ".com" will start from 0 on May 1st at 00:00 hours. The scripts that people use TODAY to try and fight for those domains that become available on a quasi-daily basis would be used ad-infinitum with everyone fighting like crazy for a couple of thousand (or more) domain names. Each person would be machine-gunning their requests at as many per minute/second as their personal bandwidth allows, repeating until they got confirmation one way or another. If all requests coming BEFORE the "going-live" date go to the bit-bucket, you can count that from about 30 minutes BEFORE that date until who knows when afterwards, the system processing for each registrar would be effectively DOWN. Look at what happened to that new registrar that gives free domains for an hour each month when he went live. Bombarded into oblivion. How would you avoid that? This is a possible (personally I think quite likely, but in any case it is NOT farfetched) scenario. As I said (and as POC came to the conclusion a few years back), you can't STOP this behaviour, nor curtail it significantly. In fact, if you DO legislate it, you'll only be hurting those that DO comply, and giving an advantage to those that work around it (in a fashion similar to the way given above). You can stop certain people from creating or maintaining queues, but you can't stop EVERYONE from generating any which way they want a queue and writing a program to feed that queue through any (or indeed ALL) registrar. See the problem? Yours, John. William Walsh wrote: > On 11-Apr-2000 John Charles Broomfield wrote: > > Also, how do you guarantee that registrars are not privately > > creating their queues ANYWAY? > > > > It would be nice to say "let's all be good boys, and treat day 0 as any > > normal day" but the reality is that there WILL be a fl > > It's easy. You tell the registry (if it is not a shared registry) that if they > are accepting pre registrations they will be in material violation of their > contract and could lose their registry, and if it is a shared registry, then > you tell the registrars that if they accept preregistrations or have material > interest in any company that accepts preregistrations or queues registrations, > that they will lose thier accreditation. > > Give it some bite. ------------------------------ Date: Tue, 11 Apr 2000 20:55:22 +0200 From: Harald Tveit Alvestrand Subject: Re: [wg-c] CONSENSUS CALLS -- THIS IS IT At 11:29 11.04.2000 -0400, Jonathan Weinberg wrote: >PROPOSED ROUGH CONSENSUS ITEM NUMBER ONE > > The initial rollout should include a range of top level domains, > from open >TLDs to restricted TLDs with more limited scope. Yes. >PROPOSED ROUGH CONSENSUS ITEM NUMBER TWO > > Criteria for assessing a gTLD application, subject to current > technical >constraints and evolving technical opportunities, should be based on all of >the following principles : > >1. Meaning: An application for a TLD should explain the significance of the >proposed TLD string, and how the applicant contemplates that the new TLD >will be perceived by the relevant population of net users. The application >may contemplate that the proposed TLD string will have its primary semantic >meaning in a language other than English. > >2. Enforcement: An application for a TLD should explain the mechanism for >charter enforcement where relevant and desired. > >3. Differentiation: The selection of a TLD string should not confuse net >users, and so TLDs should be clearly differentiated by the string and/or by >the marketing and functionality associated with the string. > >4. Diversity: New TLDs are important to meet the needs of an expanding >Internet community. They should serve both commercial and non-commercial >goals. > >5. Honesty: A TLD should not unnecessarily increase opportunities for >malicious or criminal elements who wish to defraud net users. > >6. Competition: The authorization process for new TLDs should not be used >as a means of protecting existing service providers from competition. Yes. (I have doubts about whether #3 and #6 can be achieved at the same time, but this may be as good as it gets) >PROPOSED ROUGH CONSENSUS ITEM NUMBER THREE > > WG-C recommends that the Names Council charter a working group to > develop policy regarding internationalized domain names using non-ASCII > characters. No. As technical advisor to the IETF IDN working group, I feel that the technical issues with regard to internationalized domain names are not worked out to a degree where we can make sensible policy - we do not yet know the technical constraints such a policy has to conform to. NOTE: This is "No, not at this time", not "No, not ever". Harald - -- Harald Tveit Alvestrand, EDB Maxware, Norway Harald.Alvestrand@edb.maxware.no ------------------------------ Date: Tue, 11 Apr 2000 12:33:19 -0700 (PDT) From: "William X. Walsh" Subject: Re: [wg-c] Pre-sold TLDs - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11-Apr-2000 John Charles Broomfield wrote: > And with this proposal you just move the problem one rung down. How do you > stop someone from creating a list that will bombard the webpages or email > addresses of registrars and selling "preregistrations" in that list? First come first served. What people do independent of the Registry or Registrar is not our concern. Our concern is preventing this unsavory practice from being conducted by those who are under contract to ICANN. Bottom line. The fact remains that building a system to do what you say does require a certain level of expertise. And if the technical specs for filling out the web based forms for registration are kept confidential by the registrars until launch, it will go a long way towards preventing this, or delaying it significantly. There are also many technical means to impede the creation of those systems. I would be happy to expand on those privately, so as not to give lead time to those on this list who would be responsible for creating systems to circumvent it (yes there are domain speculators in our midst :). - - -- William X. Walsh http://userfriendly.com/ GPG/PGP Key at http://userfriendly.com/wwalsh.gpg - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1c (Mandrake Linux) Comment: Userfriendly Networks http://www.userfriendly.com/ iD8DBQE4833+8zLmV94Pz+IRAvRCAJ9K/e49KomgmQ8kAZJHRPNzPu3lVgCfR+Vk r9CdJVC02hHvhNLXkpVBclE= =eWx7 - -----END PGP SIGNATURE----- ------------------------------ Date: Tue, 11 Apr 100 15:20:01 -0400 (AST) From: John Charles Broomfield Subject: Re: [wg-c] CONSENSUS CALLS -- THIS IS IT Hi, I don't know if the idea is to slowly seek consensus inch by inch, which may mean slow but sure advance... in any case: WRT item 1: (initial rollout including generic AND chartered TLDs) answer: Abstain/no-vote/don't care (choose which one suits better base on explanation) -Having chartered TLDs or not in the initial rollout doesn't bother me. I think that what most of us are pursuing (Eric Brunner is in the minority here) are GENERIC TLDs. Personally I am sceptical about enforcement of a charter, or who exactly you hand control of a chartered TLD to, think it would create more hassle than what it should resolve, and will only be workable/enforceable in a very small amount of cases. If it is deemed (how, by whom?) that the community of museums is happy with delegating a ".museum" to a given entity, then it's up to them... The group has to be large enough so as not to just become a way to avoid registration in generic TLDs, and there has to be good reasoning behind that. As you can see, AFAIK, these are VERY fuzzy concepts, which is why (as I say) I am sceptical of the idea. If a group comes forward and presents something that is credible, has consensus behind it, and looks as if it can work, then fine... Hence, I'm not bothered against introduction or not of chartered TLDs *IF* it's (relatively) painless. I give this explanation so as to show that if this item passes or fails on just 3 people voting for or against, then that's ok by me. I have no problem with it one way or another. Clear? :-) WRT item 2: answer: YES to consensus on the item. Problem: the concepts are far too vague to be useful IMHO. I feel that we might aswell gain consensus that "the internet is used to transmit data" or that "the sky is blue". WRT item 3: answer: YES if necessary. Problem: isn't this a technical problem with the current DNS? If so, why are we dealing with it? If the item is just to avoid confusion as to our role, then fine, let's formally say that it is beyond our scope. Just puzzled about this. Resume: If this is all we can do, then we're not doing much unfortunately. Yours, John Broomfield. > As promised, here is a set of three consensus calls. Please note that > these are *three separate items*, and that you need to vote on them > *separately*. That is, it won't work to send in a response that says "I > vote yes," or "I vote no." Rather, you need to vote yes or no on *each* of > the three items. The deadline for voting is Monday, April 17 at 4 pm UTC > (6 pm in Brussels, noon in New York, 9 am in Los Angeles, 1 am the > following day in Tokyo). > > I want to urge *everyone* in the WG to weigh in on these three items. If > you like ‘em, vote yes. If you don't, vote no. There's nothing wrong with > a proposed consensus item failing if the members of the WG, having decided > that it's a bad idea, vote against it. But there's something very wrong > with an item failing because too few of the WG members bother to cast a > vote at all. > > Here are the three items. > > PROPOSED ROUGH CONSENSUS ITEM NUMBER ONE > > The initial rollout should include a range of top level domains, from open > TLDs to restricted TLDs with more limited scope. > > > PROPOSED ROUGH CONSENSUS ITEM NUMBER TWO > > Criteria for assessing a gTLD application, subject to current technical > constraints and evolving technical opportunities, should be based on all of > the following principles : > > 1. Meaning: An application for a TLD should explain the significance of the > proposed TLD string, and how the applicant contemplates that the new TLD > will be perceived by the relevant population of net users. The application > may contemplate that the proposed TLD string will have its primary semantic > meaning in a language other than English. > > 2. Enforcement: An application for a TLD should explain the mechanism for > charter enforcement where relevant and desired. > > 3. Differentiation: The selection of a TLD string should not confuse net > users, and so TLDs should be clearly differentiated by the string and/or by > the marketing and functionality associated with the string. > > 4. Diversity: New TLDs are important to meet the needs of an expanding > Internet community. They should serve both commercial and non-commercial > goals. > > 5. Honesty: A TLD should not unnecessarily increase opportunities for > malicious or criminal elements who wish to defraud net users. > > 6. Competition: The authorization process for new TLDs should not be used > as a means of protecting existing service providers from competition. > > PROPOSED ROUGH CONSENSUS ITEM NUMBER THREE > > WG-C recommends that the Names Council charter a working group to develop > policy regarding internationalized domain names using non-ASCII characters. > > Jon > ------------------------------ Date: Tue, 11 Apr 2000 16:33:17 -0400 From: Eric Brunner Subject: Re: [wg-c] CONSENSUS CALLS -- THIS IS IT #1: to seek a range of registry-specific policy and/or jurisdiction models YES. Note that the question is not about business models. I hope I'd answer the same even if the only charter example available was for HIV, or museums. We should find out what something other than the NSI monster looks like and make friends with it sooner rather than later.. #2: S/K NO. 1 is contrary to competition, 2 is without reference to the capacity of the TLD delegatee to exercise an enforcement policy, 3 is daft, 4 is redundant, 5 is underspecified and 6 is denial of the present condition. Mind I could "consens" to anything that didn't actually say "shoot the indians", but volunteering to be the DNS village idiot is extravagant. #3: i18n-in-libns NO. Like Harald I know what this is, and the answer is "eventually, but not today, and not in today's DNS Wars carnival". Cheerfully, consensually, etc., Eric ------------------------------ Date: Tue, 11 Apr 2000 16:47:28 -0400 From: Jonathan Weinberg Subject: Re: [wg-c] CONSENSUS CALLS -- THIS IS IT At 08:55 PM 4/11/00 +0200, Harald Tveit Alvestrand wrote: >[snip] >>PROPOSED ROUGH CONSENSUS ITEM NUMBER THREE >> >> WG-C recommends that the Names Council charter a working group to >> develop policy regarding internationalized domain names using non-ASCII >> characters. > >No. > >As technical advisor to the IETF IDN working group, I feel that the >technical issues with regard to internationalized domain names are not >worked out to a degree where we can make sensible policy - we do not yet >know the technical constraints such a policy has to conform to. > >NOTE: This is "No, not at this time", not "No, not ever". James Seng, who's the co-chair of the IETF IDN WG, wrote to me that in his view the WG is on track to finish its work by July. If we suggest a DNSO WG now, as a practical matter the NC won't act on it until the Yokohama meeting (that is, July). So I've been figuring that the technical work *will* precede the policy work. That said, Harald knows infinitely more about this topic than I do. Jon ------------------------------ Date: Tue, 11 Apr 2000 13:52:36 -0700 From: "Christopher Ambler" Subject: Re: [wg-c] CONSENSUS CALLS -- THIS IS IT You are proposing a WG on a *policy* matter. ICANN's very own mandate says that they oversee TECHNICAL COORDINATION of the Internet. How do you justify this? - -- Christopher Ambler chris@the.web - ----- Original Message ----- From: "Jonathan Weinberg" To: "Harald Tveit Alvestrand" ; Sent: Tuesday, April 11, 2000 1:47 PM Subject: Re: [wg-c] CONSENSUS CALLS -- THIS IS IT > At 08:55 PM 4/11/00 +0200, Harald Tveit Alvestrand wrote: > >[snip] > >>PROPOSED ROUGH CONSENSUS ITEM NUMBER THREE > >> > >> WG-C recommends that the Names Council charter a working group to > >> develop policy regarding internationalized domain names using non-ASCII > >> characters. > > > >No. > > > >As technical advisor to the IETF IDN working group, I feel that the > >technical issues with regard to internationalized domain names are not > >worked out to a degree where we can make sensible policy - we do not yet > >know the technical constraints such a policy has to conform to. > > > >NOTE: This is "No, not at this time", not "No, not ever". > > James Seng, who's the co-chair of the IETF IDN WG, wrote to me that in > his view the WG is on track to finish its work by July. If we suggest a > DNSO WG now, as a practical matter the NC won't act on it until the > Yokohama meeting (that is, July). So I've been figuring that the technical > work *will* precede the policy work. > > That said, Harald knows infinitely more about this topic than I do. > > Jon ------------------------------ Date: Tue, 11 Apr 2000 14:04:42 -0700 From: Dave Crocker Subject: Re: [wg-c] CONSENSUS CALLS -- THIS IS IT At 04:47 PM 4/11/00 -0400, Jonathan Weinberg wrote: > James Seng, who's the co-chair of the IETF IDN WG, wrote to me > that in >his view the WG is on track to finish its work by July. If we suggest a The working group meeting in Adelaide, two weeks ago, had useful exchange. However it was very clear that the group does not have a ready technical solution that it will all rally around. Hence the process is likely to be longer than July, which is only 5 months away. Based on the history of similar groups, my own guess is that they will do very well to get a solid START by July. d/ =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 675 Spruce Drive, Sunnyvale, CA 94086 USA ------------------------------ Date: Tue, 11 Apr 2000 17:18:43 -0400 From: Jonathan Weinberg Subject: Re: [wg-c] "It Won't Work" At 11:16 AM 4/11/00 -0700, Dave Crocker wrote: >This note raises a question about Working Group C process. As such, I am >requesting a formal response. > >For development efforts, there are two kinds of disagreements: One is "I >don't like the idea" or "I prefer some other idea". That is an argument >along the lines of engineering preference. Hence, consensus is a >reasonable way to break a deadlock, although it does raise a question about >relative qualifications for choosing. > >The other type of objection is "It won't work". In other words, it is a >claim that people's preferences are irrelevant, since the proposed >mechanism simply does not function as desired. To deal with this concern, >there needs to be an analysis that shows that the mechanism DOES work, or >else the mechanism/proposal needs to be fixed. > >A number of us have raised concerns about the list of "criteria", pointing >out that there is no objective way to apply them. As such, they will >become yet-another source for subjective debate. > >In other words, the concern about the criteria is that They Won't Work. > >What is significant is that there has been no substantive response to this >concern. > >Hence my raising a process challenge. > >In other words, the current consensus call is irrelevant until basic >concerns over the ability to apply these -- or any other -- "criteria" are >resolved. > >Jonathan, please deal with these concerns explicitly, since they concern >the ability to USE the "criteria". If there is no clear and reasonable >basis for applying the "criteria" then development of them is just an >academic exercise. The gist of the response as I understand it (and in my own words) is this: Any set of substantive standards, offered up to guide a decision-maker, is going to fall somewhere on a spectrum between 1.00 (totally constraining: the decision-maker applies the criteria in an entirely mechanical way, and that process generates unambiguous instructions about what to do), and 0.00 (totally irrelevant: the decision-maker, after attempting to apply the criteria, has absolutely no more guidance about what to do than he had before he started). I understand the proponents of the S/K principles to argue that the S/K standards fall in between: that they will offer some useful policy guidance to ICANN even though they're not totally constraining. (Philip has recently suggested that later in the decision-making process, an ICANN body may wish to take the general policy guidance embodied in S/K and embody it in a more specific implementation document.) Notwithstanding that the S/K principles will not themselves generate a mechanical, objective (>.75 on the scale?) process, proponents argue, the policy guidance they provide is still valuable. Each member of the WG, natch, has to decide whether that response satisfies them. In order to conclude that the principles will "work," as Dave puts it, one has to conclude [1] that the principles do provide *some* (>0.00) policy guidance, rather than being totally irrelevant to actual decisionmaking; [2] that the policy guidance they provide is desirable (that is, that they move in the substantively correct direction); and [3] that the advantages of the policy guidance they provide aren't outweighed by any disadvantages they may have (e.g., providing another hook for lawyerly types to try to tie the process up in knots). But all this is stuff we've been talking about, and I assume that people will vote "yes" or "no" depending on their understanding of those issues. Jon ------------------------------ Date: Tue, 11 Apr 2000 14:27:43 -0700 (PDT) From: "William X. Walsh" Subject: Re: [wg-c] CONSENSUS CALLS -- THIS IS IT - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11-Apr-2000 Christopher Ambler wrote: > You are proposing a WG on a *policy* matter. Not unlike everything else this and every other workgroup has done. > ICANN's very own mandate says that they oversee TECHNICAL > COORDINATION of the Internet. > > How do you justify this? That this mandate is nothing more than an illusion. - - -- William X. Walsh http://userfriendly.com/ GPG/PGP Key at http://userfriendly.com/wwalsh.gpg - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1c (Mandrake Linux) Comment: Userfriendly Networks http://www.userfriendly.com/ iD8DBQE485jP8zLmV94Pz+IRAlbwAKCxANSEJ2ySRMfMsc7TIfQG2C5QaQCfSTmA /RgxU14qK5cbfAbQd3n86m4= =tU88 - -----END PGP SIGNATURE----- ------------------------------ Date: Tue, 11 Apr 2000 14:31:04 -0700 From: "Bret A. Fausett" Subject: Re: [wg-c] CONSENSUS CALLS -- THIS IS IT Jonathan Weinberg wrote: > Here are the three items. > > PROPOSED ROUGH CONSENSUS ITEM NUMBER ONE > > The initial rollout should include a range of top level domains, from open > TLDs to restricted TLDs with more limited scope. Yes. > PROPOSED ROUGH CONSENSUS ITEM NUMBER TWO > > Criteria for assessing a gTLD application, subject to current technical > constraints and evolving technical opportunities, should be based on all of > the following principles : .... Yes. > PROPOSED ROUGH CONSENSUS ITEM NUMBER THREE > > WG-C recommends that the Names Council charter a working group to develop > policy regarding internationalized domain names using non-ASCII characters. No opinion / Abstain -- Bret ------------------------------ Date: Tue, 11 Apr 2000 14:33:07 -0700 From: "Christopher Ambler" Subject: Re: [wg-c] CONSENSUS CALLS -- THIS IS IT At least your honest about it. - -- Christopher Ambler chris@the.web - ----- Original Message ----- From: "William X. Walsh" To: Sent: Tuesday, April 11, 2000 2:27 PM Subject: Re: [wg-c] CONSENSUS CALLS -- THIS IS IT > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On 11-Apr-2000 Christopher Ambler wrote: > > You are proposing a WG on a *policy* matter. > > Not unlike everything else this and every other workgroup has done. > > > ICANN's very own mandate says that they oversee TECHNICAL > > COORDINATION of the Internet. > > > > How do you justify this? > > That this mandate is nothing more than an illusion. > > - -- > William X. Walsh > http://userfriendly.com/ > GPG/PGP Key at http://userfriendly.com/wwalsh.gpg > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.1c (Mandrake Linux) > Comment: Userfriendly Networks http://www.userfriendly.com/ > > iD8DBQE485jP8zLmV94Pz+IRAlbwAKCxANSEJ2ySRMfMsc7TIfQG2C5QaQCfSTmA > /RgxU14qK5cbfAbQd3n86m4= > =tU88 > -----END PGP SIGNATURE----- ------------------------------ End of WG-C-DIGEST V1 #82 *************************