|
Navigation
|
||||||||||||||||||||||
|
|
See
Also
|
||||||||||||||||||||
|
||||||||||||||||||||
|
The Archives
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
All the news that's... whatever. Welcome to Random Bytes...
|
|
And i would just perhaps invite perhaps the chairs of that task force or chair to give a very quick summary of __ i think really what's happened since the transfers task force report has been presented, and perhaps just a summary of the discussions over the last two or three days. so marilyn, go ahead. Marilyn Cade: I just wanted to note for the record that there was a presentation earlier in a public forum jointly supported by the ga, several of the constituencies, and i think __ and chaired by Denise Michel. I think it's particularly important, and of course all of the names council representatives were invited to participate in that, either because they were actually participating or they were invited to be in the audience. For the record, we note that invitation was extended, so with the purpose of not having to repeat that full presentation, most of the audience here today was also in that session. the transfers task force over the recent weeks has taken the draft set of recommendations, reviewed at our last presentation to the names council, taken it further, undertaken further comment, and posted it as the interim __ as part of the interim report of the task force. it is open for comment until november the 8th, available at www.icann.org, click on announcements or www.dnso.org. it is a very robust set of procedures and recommendations that rely on a determination of who has the authority to authorize a transfer and recommending a standard set of processes. it relies on if there is an authorization code that is given to the registrant by the registrar, it relies on that code. if there is, for some reason, an environment where often both codes are not available because they have not been implemented by everyone, then we identify who we recommend to be recognized as the authorized individual. it also assumes that there is a standard set of days during which recovery or certain other things could __ or if there's an exception or a problem, there's a standard set of days that would be observed. so we are recommending sort of a standard set of approaches that would be adopted and agreed to. the community of registrars who originally contributed to the drafting of this document did take a vote within the registrar constituency and strongly supported the use of auth codes, auto nac, meaning the request for transfer would be automatically granted if they had one of these particular forms of identification. it does presign areas where an auto nac, a denial of the automatic transfer could be legitimate and that could be because there's reasons to be suspicious or a concern. it also prescribes those conditions under which a registrar legitimately can deny or could not deny. it assumes there needs to be an appeals process and discusses that it's possible that the registry involved could provide an appeals process. it assumes there could be a need for a third_party appeals process, and that there would need to be a cost recovery mechanism in either case. in recent days __ let me make clear that from the beginning even though this was a process developed within the registrar community it was never a process although it was prodly supported. in recent days, a few of the registrars who have understood it was extremely important to document their objection and have submitted a letter to the task force calling the attention to the concerns that they have and supporting auto nac, which would be in complete contradiction to the recommendation __ the interim recommendation of the task force. we did undertake an open discussion with the registrars and registries here in shanghai on sunday afternoon and had a very helpful and useful discussion and received, i believe from my notes, an agreement and pledge that the registrars are interested in continued close interaction with the task force. we will be setting up further mechanisms, including requesting the six or so registrars who signed the letter to have an exchange via conference call with the task force so that we can make sure that we understand their concerns. we've advised everyone that it is absolutely critical they document their support or objection, and they need to be specific about what their concerns are, submitting line_item changes or other recommendations. the consensus policy process that was clarified by the general council of icann makes it very clear that for document consensus policy, the task force is charged with reasoned support and opposition. failing to receive reasoned opposition, it would be impossible for the task force to so document. i think that point has been well understood. that's really significant progress. we did have the public forum and got some additional comments underway today and received a support from several members of the registrars in the audience that they would welcome another chance to talk to the task force while we're here on ground. would any of the constituencies like to comment on what they've heard from their members on transfers over the last couple of days? roger, chun. go ahead, roger. and jordyn. Roger Cochetti: thank you. the gtld registry constituency has commented on the earlier transfer task force papers, and what i'm about to do today really reiterates comments that we made previously, but they are nonetheless important. probably the most important commodity that the council has is its credibility. and when the council acts in a manner that is arbitrary or goes beyond its competence, it undermines the credibility, which is the most important thing we have to offer. the gtld registry constituency has attempted to point out to the task force that whereas the responsibility of the names council is to coordinate policy and to operate at the policy level, the task force has addressed quite a large number of questions which go well beyond the level of policy. the icann general council has been helpful in documenting the 20 specific recommendations that the task force has put forward in its most current draft or its interim report. and these range from such items as registrars would be obligated to issue auto info codes to registrants within 72 hours of a request, and subject __ and subject to no more authentication than required for contact or name server information changes. if you read the list of 20 fairly detailed recommendations that the transfer task force has developed, it is, i believe, impossible to conclude that these are all policy recommendations. that comment is irrelevant to whether the recommendations are good, bad or indifferent, whether they are helpful or unhelpful. the issue is the competence of the names council and the task force and what their mission is. so the gtld registry constituents, having looked at the current version of the task force report, continues to conclude that the task force has operated outside of its proper scope in putting forward a series of recommendations which may or may not be helpful or constructive in and of themselves, but really are beyond the policy mandate and authority of the names council and its task forces. so we really reiterate the comments we've made to previous (inaudible) report. thank you. what's an example of policy recommendation and what's an example of something that shouldn't be a policy recommendation? Roger Cochetti: well, i guess everyone could have their own judgment, but just glancing at the list here, it says gaining registrars will be required to produce a copy of the authorization to the losing registrar within three business days upon request. now, i gather the task force believes that the selection of three business days is a policy, not an administrative detail; that if two registrars felt that they could accomplish the same task in one business day that they are violating a policy or if they felt they could do it in five business days, they're violating a policy. this is a detail, not a policy. so that the mandate of the names council is to coordinate policy and the work of its task forces should be focused at the policy level, not at the level of administration details or specific practices of registries and registrars. so if you'd like, i'd be happy to ask the constituency to examine this and identify all of the recommendations that sink below the level of policy down to the level of administrative detail. but there are quite a few, and only glancing at the list of 20 recommendations outlined by the general counsel. do you see the names council would generate a policy and then the icann staff would work on the detail? there does need to be detail there somewhere. Roger Cochetti: yeah, i think the development of administrative detail is a matter of negotiation between the registry or registrar involved and icann management, which is responsible for implementing policy or to the extent the icann board would get involved on administrative details that i suppose they might get involved as well. so exactly what that limit is would be determined by negotiation. is that __ Roger Cochetti: you're using a specific example in this case, but i think the principle is that's correct. the council should focus its attention on what it is competent to do, and that is address policy, not administrative details. and this report is replete with administrative details, providing very specific definitions for registries and registrars on how they must change their detailed practices. so i think the counsel's __ the general counsel's note on this of __ i think it's the 20th of october, says as much, that this would require massive renegotiations of registry and registrar contracts into very detailed new activities. just one other comment on this, i guess, is perhaps, i guess, then, what you're suggesting is a task force should break down what it is considering to be policy recommendations from, perhaps, advice. and i sort of say that, i guess, in the whois report as well. but it's just a comment. i've got chun and jordyn in the queue, but would people just like to respond to roger? i've got j. scott and philip. go ahead, j. scott. J. Scott Evans: i would like to point out first of all that this is an interim report and these recommendations are just possible recommendations that have been put out to spur additional discussion, which we have had. secondly, and the last point, roger, is i understand the general counsel's letter.
he didn't make any indication that it would require, as i understood. he said that your group and the registrar group felt like it did that and that was the reason that he was responding to that. that wasn't his opinion; it was his reaction to your __ i think he said aghast or something to that extent. he used very emotional language for louis. one of the things i want to say is one of the things this task force has been challenged with is they have been faced with finding a solution, whether that solution be an overall broad principle or minutia, however you which to view it, in which constantly the problems are occurring because there are those that are participating in the system, that are gaining the system to the disadvantage of those players that wish to play by the business practices that we would all endorse openly and it is also frustrating the users because they feel like they're being taken advantage of. and i think sometimes the level of detail you see is because when you have vague policies without any detail and it's left to some vagueness, the gaming continues to occur. and we find ourselves with a broad set of principles that don't really solve the solution; they simply sort of give a nod to the solution. so that's the point i wanted to make. one, that these are not recommendations; they are possible recommendations that will hopefully bring more people to the table that do have experiences that they can bring so that then that can be crafted into final draft recommendations that would then be put out again for public comment before recommendations to the council, then to the board. now, philip you had a comment on roger's comments? Philip Sheppard: yes. Philip Sheppard: i think it's a surprise, the comment roger made, and endorse strongly the comment we just heard from j. scott. i think first of all, on process, the process should be, i think, those comments that we just heard should be made in writing to the transfer task force. they're very much part of the input. indeed, this has been a process going on for some time. feedback via the constituency should forewarn the constituency and not get to us now. that is disappointing at the very least. secondly, the board position is very clear one of practicality. if not here, if not in the dnso, then where should those minutia, which are the essence of solving the problem, where should they be sorted out? do we negotiate with every registrar on the planet or try to do it centrally? practicality dictates we must do it centrally. unless we come to some pattern as we have in a moment of these details and getting these things worked out at the grievance level. Chun Eung Hwi: basically, i think the urgency of this kind of policy is very clear to all of us. in other words, i'd like to say we should underline the other aspect of this issue. i think basically the urgency __ the (inaudible) for decision_making process, but simultaneously, i think our other concern, specifically for the interest of general users, should be (inaudible) focused up to now. so my comment is very specific. it is concerned with the language issue in this transfer process. fortunately this morning in general assembly session, this point has already been raised up by registrar constituency. although this is very significant for most users in asia_pacific region, as even in other regions, including non_english speaking countries, as you know, the confirmation of process of registry regarding the willingness of registrant for transfer is being done only in english. so such a notification could make some troubles and make non_english speaking users be confused, and finally to losing their own registered names. this is very headache. so i think this concern should be underlined and hopefully to be documented in final report. for, i think, possibly throughout task force discussions, and even in public comment process, this concern has not been legitimately taken up. i don't know how and where this concern could be effectively reflected in this document, but this concern is not just a notification issue but also in appeal and dispute resolution process. this language should be seriously taken into account. that's it. jordyn, you were next. Jordyn Buchanan: yes, thank you. i think, first of all, this is going to sound, to a certain extent, like some more conversation on the topic that roger raised, but i think i want to express some of the thoughts slightly differently, and i want to thank both j. scott and philip for clarifying these are to encourage discussion. because i think there are some circumstances in which we find they make a perfectly large amount of sense 80 or 90% of the time but as we try to map them onto specific registries or registrar interactions that they become difficult in certain limited circumstances. let me toss out a couple of examples of that to demonstrate the point. one is there's a requirement that transfers can be authorized by the admin contact or the registrant and i think most of the time that makes perfect sense and we understand the motivation behind that. in the case of .pro, the registry i work for, our intent is to issue a digital credential to one of those two contacts, and to perhaps require that digital credential to be used in order to authorize it, but not necessarily both of them will have it. so in that particular case, we might see only the registrant or the admin contact to authorize the transfer. so i think as a general guideline the policy recommendation makes perfect sense but in terms of mapping it as a sort of internet_wide requirement, it's more difficult. and i think the second point i would make is the requirement of the auth info code makes perfect sense. i think three days is a good guideline except that the way that __ i actually worked quite closely with scott hollenbeck in the formation of auth info, and it's something we thought about at the time that it already has been changed significantly from the way it was originally conceived in that the idea was registrants were suppose to choose their own auth info code in the first place, not the registrar. so in that case there would be no need to provide them the auth info code at all because they would have selected it themselves at the time they registered the domain name. so does three days make sense in that context? maybe, maybe not. these are guidelines that make sense the vast majority of the time, but i think it's best for now at least to think about these as guidelines as opposed to specific policy requirements because they do, i think, in some circumstances potentially create some problems if mapped that way. and i think that just by adopting them as guidelines they allow us as registries to go and perhaps start to have some basis to enforce our contract with registrars as opposed to the vague language that exists now. and it seems like they're a very good starting point for that and i want to thank the task force for that work. : can you hear me? grant, go ahead. and i (inaudible) talk about (inaudible) negotiated by icann staff and council that i think the registries and registrars (inaudible) there may be different implementation. (inaudible) of a mind that (inaudible) registrars would end up with (inaudible) so that (inaudible) and no expectation with regards to dealing with (inaudible). do you want to respond? Roger Cochetti: i think i did understand the question. and let me answer it, because i think there are different levels in responding to grant's question. first, i think we should all recognize that there is a broad category of administrative trivia where there is no benefit to uniform practice. it is quite possible that two registrars may have different practices for what holidays they give their employees. it is quite possible that two registrars or registries may point their buildings different colors. there is no benefit to regulating every aspect of the administrative practices of registrars. so there is a level of this in which it should simply be left to the administrative mechanisms of the individual registrar or registry. above that, there may be an area where uniformity is useful or constructive, but that falls below the policy level. and i guess that's where i would take issue with the terminology of grant's question. his question was, well, how do you bring about uniform policy? would you just let the policy be developed in negotiation between registries and registrars and wouldn't that result in different policies? and it may be that we're using the word "policy" differently here. i would describe that as __ i would describe the broad category, by large part of the category, what i think was implicit in grant's question, as practice, as administrative practices where it may be useful for them to be uniform. but that's not a matter for the names council to address. uniform administrative practices are not the competence of the names council, no matter how smart we think we are, no matter how much we think we can contribute, no matter how brilliant our ideas, we can't wish the competence for the mandate of the names council to be other than policy. policy is that highest level which is the policy, the direction, the objective you're trying to accomplish. so i would say you may have uniformity at the middle layer of administrative practice or you may not have uniformity of administrative practice if it drops to the bottom layer where practices vary between operators. so i don't know if that answers the question, but i certainly would not say that policy would be determined in negotiation by icann management and a registry operator. that's administrative practice. yes. thank you for clarifying that, roger. because (inaudible) further concerned. because i think it's very important that we use this, and this is what is effective in the policy, that their users and the community generally, which i think includes registrars and registries, where the community sees benefit in consistency, for consistency, we have tried to place in our recommendation. and you will notice in other recommendations, you have noted a variety of options open to registries and registrars and have suggested that the option left to registry or registrar in the (inaudible). so i think it is important. and mostly the importance is reflected in the recommendation, particularly from a user's point of view, as consistency. and i think this is one of the main problems that we have identified in the current environment regarding (inaudible). (inaudible) unscrupulous practices can be performed where had an understanding as to common practice, those practices can be more readily seen for what they are. and it would concern me if (inaudible) to be championed that policies should be left simply at the principal level and not to be able to be translated into consistent policies. i think that's what is reflected properly in the recommendations in the report. but just as you might have a policy that cars must have brakes, you don't have to specify whether they're disk brakes or drum brakes. but you still have a policy that the cars have brakes because that protects the consumer. so you get a balance there and identify the reason why this issue is being looked at at all is because there is a problem and because the current contracts are too general. and i think we need to take that perspective as well. marilyn, you are next in the queue. Marilyn Cade: i'm going to respond to the illustration you gave and roger's statement. you might specify that the car, in fact, have brakes, but you might specify they have to be effective so you don't kill people. Marilyn Cade: bruce, i think that this particular debate on this particular point probably is not the most useful approach to solving the problem, although i appreciate the illustration. i'm going to make an appeal here. first of all, i'm going to say to the chair of the task force, i'm confused. and it's usually a bit hard to confuse me, but perhaps this is the time. i believe, if my member serves me correctly, that there have been two members of the registry constituency on the task force since its beginning. recently, when an employee of register.com, who was the second (inaudible) the other representative is an employee of verisign registry, when the register.com employee changed positions, we were fortunate enough to get the chair of the registry constituency to join us and welcomed that, since that would be clear that we would have a broader input. so we've had the benefit and contribution of two members of the registry constituency, which has been a terrific asset to the work of the task force. the document that we're talking about has been published for some time and has gone through 50 iterations. we've killed a lot of trees. we've taken up a lot of bandwidth. we've made this available very broadly. on sunday, i heard, as the chair and the other members of the task force here heard, in detail expressions of significant concern about the delay and the harm that failing to address this problem is causing to their businesses and, through them, to their customers. we have heard as a task force from registrants themselves the harm, the risk, and the disenchantment and anger that they feel. the trust they're losing in the competitive registration process. the fact that they are writing letters of complaint to elected officials, the fact that they are appealing to regulatory agencies. i think that this is all indicative of our need to take this seriously and to address if perhaps the registry constituency elected representatives have not had a chance to respond in detail or weren't able to attend the session this morning from 10:30 to 12:30 where we made an appeal for written comments on the document, i want to remind everybody this document is open. the purpose of having representation on the task force is to provide input and comment along the way. but there's an open comment process. written comments are not only welcome, but maybe we need to get a pledge here that we're going to get written comments. that's what we need. and i think that that's one thing we should address and make a priority. i would just make one other appeal. roger indicated that he was speaking for the gtld constituency. jordyn gave, as he said, a slightly different perspective and some helpful suggestions. i think if we __ if you're speaking for your constituency, that's fine. the task force welcomes knowing that. if you're speaking as an individual but from the constituency, that would be helpful to know as well. in either case, the task force needs comments. those comments could be of the nature that roger expressed. but i would urge you to try to give detailed comments as well. J. Scott Evans: i do want to come to roger's defense. and no one drop dead. i just want to say that i believe it's incumbent to note in the public record that simply because there are representatives __ and i understand your frustration, marilyn __ from certain constituencies on task forces that look at issues, that should in no way inhibit or discourage members of constituencies or constituencies as a whole coming forward with critiques or criticisms or disagreements with any task force report, because when you serve __ and i have served as a member of a task force __ you are doing your best to craft a document that you're not sure whether, despite your group's disagreement, would still be accepted, because as we've talked with louis, consensus does not mean that there will not be disagreement within the community, and dissent. so you're trying to the best to craft a policy that would be palatable even if there is your dissent. but that doesn't mean that you shouldn't, if given the opportunity in a comment period, strongly dissent. and the fact that you have members serving on the task force that positively contributed to the document, that shouldn't hold or be held against you or be shown as __ i just wanted to make that for the public record. Marilyn Cade: j. scott, i think i respond. i hope i made this clear. that's what this comment period is for. i didn't expect those earlier comments to have been made in writing. but we really need them in writing now. Jordyn Buchanan: yeah. first of all __ excuse me. Ellen Shankman has joined the call. Ellen Shankman: hi. can you hear me? jordyn. Jordyn Buchanan: thanks, bruce. first of all, just with my oci hat on, i do want to note that the registry constituency representative to the transfers task force was actually an employee of registrypro, not register.com. Marilyn Cade: sorry. Jordyn Buchanan: as a broader point, i'll note that just as j. scott just pointed out, i think the registry constituency has always taken the position within the task force that although, as individuals and contributors to the task force are representatives do their best to represent the interests of the task force, at times, they don't have specific instructions. they have to sort of do their best and represent what they think the constituency will think. but the work still does have to go back to the constituency and be vetted by the constituency as a whole and looked at by the constituency as a whole. and i think to that end, we as a constituency will be putting together a formal statement in writing that will, i think, represent the statement of the entire constituency. we have not done that yet. and i think that it would be premature for me or anyone else to make a statement on behalf of the constituency today. Marilyn Cade: thanks. roger again. Roger Cochetti: just to respond to a couple points. first, i want to emphasize that if i heard the exchange between j. scott and jordyn correctly, i agree with everything that jordyn said. j. indicated that many of the items in here were not statements of mandatory policy; they were illustrations of how a policy might be implemented, and that there was some confusion in the language because the language made it appear that these were statements of mandatory policy, which is what i was reacting to, when, in fact, the intent was that they were examples of how a mandatory policy might be implemented. and i thought i heard jordyn say that if that's the case, some of these are very useful illustrations of how a policy might be implemented. so __ and i would agree with that. and i express no substantive view, and i don't think the constituencies expressed a substantive view on the examples cited in here other than the language should be clear that these are not statements of policy. finally, i would just say again to the comments that were made by several people that the fact that we are bound and limited to coordinating policy does not mean that practice is unimportant, nor does it mean that we can, by will, wishful thinking, hopeful thinking, change our responsibility or mandate. we are created to coordinate at the policy level. we are competent to coordinate at the policy level. we are not competent to address administrative practices, no matter how important and what brilliant ideas we may have as a names council on administrative practices, that's not our mandate, it's not our competence. i think, as jordyn said, there are many constructive ideas for administrative practice in this report. thank you. J. Scott Evans: i want to be clear here that i don't agree that having a time period set for some sort of action within a policy is an administrative detail. if so, the entire redemption grace period is an administrative detail. so i think that that is a false distinction that's made in order to not have to adhere to the requirements of the policy that the stakeholder community, my clients, who are frustrated when they try to transfer a domain name, have come to me begging for a solution for. and they want a clearly_defined solution that has teeth in it and clearly tells the participants that are involved in transferring this domain name what their responsibilities are, and then has in it some sort of __ some sort of punishment or consequence for a party that abuses the guidelines, the policy, the time limit that's been set forth by a reasoned group of stakeholders that have decided this is a problem that has to have a solution. is there a __ we'll probably move on to the next topic. but if someone else that hasn't already spoken would like to comment? ellen on the phone, did you have any comment on the transfers policy? Ellen Shankman: (inaudible) i'm concerned that one (inaudible). Ellen Shankman: hello? Ellen Shankman: yes, i'm sorry. (inaudible) it would be important looking for a policy that's going to work. i think, from my perspective, just as chair and as a policy perspective, marilyn, i think the transfers task force does need to review the document it does have, because i have heard feedback from other parties as well that in some parts of the document it can be overly prescriptive. and we need to sort of get the balance between the policy side of it perhaps right out front, and particular examples, perhaps, of possible implementations of that policy. so i thought as an issue. Marilyn Cade: bruce, i also want to respond with a suggestion to all of us. louis wrote the document that he wrote largely at my request, as he has acknowledged. and the request came to him quite some time ago. i ask him to clarify for the task force uses, generally task forces, what it would take to implement consensus policy that impacted contracts, and to make sure that besides just the registries and registrars, other participants who are involved in task forces would have a better understanding of that. in the press of time, it took a bit longer to get that document out than he and i had both thought, but he did get it out. he did include a list of items in __ from both the whois task force and the transfers task force of areas where consensus policy might be required. again, i am sort of amazed that i am hearing an expression from my fellow names council members that they weren't aware that this is an interim report, because we made such a big deal of that within the task forces. it's an interim report; it's not a final draft report. interim report means out for comment, needs a lot of change and comment before it can go to final draft report. so let's take that all optimistically and get the comments in. and that may include, as we said today, in the open forum, that we spent so much time on, we could have a completely different set of recommendations based on the feedback we receive. but it's important we __ that we pursue an outcome. but i'd suggest it might be helpful to the names council to invest the time that both task forces invested by having louis come, the general counsel come, and speak with us in detail and let us ask questions about his memo and what it means. but that change would require the agreement, as roger's pointed out, between the contracted parties involved, which is icann registries and registrars. so there is certainly that element there. okay. i'd like to move on to the next topic, which is whois. and, again, invite the chairs of the whois task force, which i believe is marilyn and also tony. J. Scott Evans: bruce, can i ask if you request __ see if louis can join us for our next conference call on november 14th to explain that and just put that __ just note that down? if he's available? |
© Copyright 2003 Ross Wm. Rader. The opinions expressed in this weblog are solely those of the respective authors.
Last update: 1/27/2003; 11:22:42 PM.