RE: [ga] Ignoring the Rules

[Joanna Lane <jo-uk@rcn.com>]

Danny Younger wrote:-
<snip> .... and nothing in the proposal which forces a
> registrar to clearly state the conditions for a successful transfer either
on their websites or in their terms of service contracts.>

Ross Rader wrote:-
<snip>  <If you are serious with this remark, might I recommend that you
ensure that it is
tabled with the TF?>

- It's already in the TF record. You may have forgotten that during a
teleconference to which individual registrants were invited, a discussion
took place on this exact point and it was generally agreed that Registrants
need a clear explanation in documentary form of transfer processes. Exactly
how that information is to be passed was left to the TF to work out after
the call, which group has clearly dropped the ball, but included in the
suggestions made was an FAQ page on each Registrar website, or a page on
ICANN's website to which the Registrant would be pointed *at the time of an
initial domain name registration*. There may be other suggestions in the
transcripts as well.


Ross wrote:-
<I don't see support for the proposition coming from the
Registrar or Registry constituency, but if the user voice is united on these
points, we may have to reconsider our respective positions.>

I find it very difficult to believe that any user would vote for remaining
ignorant. Name me one user who does not support access to knowledge about
how to transfer an essential service from a poor, expensive provider to an
efficient, cheap one. Common sense dictates there is no need for a debate
here. Added to which there were no objections to this proposal during the
teleconference from the Registrar or Registry constituency or any other
group.

<My preference is
to allow Registrars and Registries to provide shitty service. The market
will eventually separate the wheat from the chaff. Also note that the task
force has discussed this specific point at length.>

Ignorant registrants are not an asset to the industry, especially with
respect to the transfer process, which they are driving. Most registrants, I
would guess, don't have a great deal of experience to judge the quality of
domain name transfer service they receive, so in practical terms, the chaff
can only be weeded from the market after a significant group of users have
first suffered a fairly long period of abuse. The user does not need this
kind of policy to be promoted by the Registrar/ Registry community, which
serves only to prolong the adverse effects they are already suffering.

A better policy for the user is to inform registrants at the time of domain
name registration of their rights to transfer that newly acquired domain to
a competitive registrar, easily and at any time, as well as a step by step
guide about to how to accomplish the task. It would be very easy for ICANN
to host an explanatory document on its website, and to ensure that the
public interest is protected in the process, by insisting that every ICANN
accredited Registrar is required to hyperlink to that explanatory page,
against which the registrant may judge the quality of service they receive,
also to embed the URL into whatever email confirmation the Registrar would
normally send to the domain name registrant at the time of purchase.

This is a reasonable request, since the only right it confers on the user is
the right to know what is going on in the Transfer process. Of course, I
would be most interested to know why the proposal was rejected by the TF
after having consulted with individuals who advocated strongly in support.

Regards,
Joanna

> -----Original Message-----
> From: owner-ga@dnso.org [mailto:owner-ga@dnso.org]On Behalf Of Ross Wm.
> Rader
> Sent: Friday, November 08, 2002 1:05 AM
> To: DannyYounger@cs.com; Jeff.Neuman@neustar.us; ga@dnso.org
> Cc: mcade@att.com
> Subject: Re: [ga] Ignoring the Rules
>
>
> > all this time, the task force only considered a single proposal that
> > represented the thinking of the numeric majority of the registrar
> > constituency without affording due consideration to those within the
> > constituency that held differing views (even though those others
> collectively
> > account for more than 60% of all the registrations in the gTLD
> namespace).
>
> The group you refer to has yet to present a salient proposal to the Task
> Force. They have provided their comments to the group and they
> are currently
> being considered. What is difficult with this bunch is determining what
> aspects of their comments will move the ball forward and what is simply
> rhetoric. The recommendations have evolved over time, but their resistance
> has not - its tough being a mind reader.
>
> Regardless, all proposals will be considered, small or large. The
> Task Force
> is in the process of digesting a number that were received through the
> public comment process thus far.
>
> > To date, the task force has still not fully or reasonably addressed the
> > concerns raised by the VeriSign registrar.  Neither has the task force
>
> That is patently incorrect. Read on...
>
> Requirement #1 - Clear definitions.
>
> > "In addition, as we have stated in the past, this document should also
> > address the thorny issues of setting clear definitions for many
> aspects of
> > registrar transfers.
>
> These are well covered under the definitions appendix of the report.
>
>
> Requirement #2 - Define Apparent Authority.
>
> > registrar transfers.  For example, we need to clearly define apparent
> > authority,
>
> The Task Force is recommending that the concept of AA be ditched and that
> only the Registrant or Administrative Contact can authorize a transfer. AA
> no longer exists, therefore the concern is moot.
>
> Requirement #3 - The role of third parties.
>
> > authority, as well as how a third party could validate transfers.
>
> The recommendations are clear that only a registrar can authenticate a
> transfer request.
>
> Requirement #4 - The role of third parties as agents of the registrant.
>
> > contract, and how/whether an ISP/reseller can act as an agent
> on behalf of
> > the registrant, since they are not a party to the registrar/registrant
> > contract (a facet of the apparent authority definition that is needed).
>
> Registrants can appoint agents to act on their behalf and grant them
> Administrative Contact privileges which will allow the agent to
> request/approve/deny a transfer. Clearly covered under the
> recommendations.
>
> Requirement #5 - Consultation with Registrants
>
> > Finally, it is very important that we understand that
> non-registrars need
> to
> > participate in the policy-formation process for the result to have
> > credibility.  Most importantly, we need to consult with
> registrants (i.e.,
> > consumers), who are the very important other half of this equation."
>
> The task force has specifically consulted with the needs of the user
> community through a variety of outreach efforts. Complete details
> will be in
> our final report, but suffice to say that they consisted of several open
> conference calls, constituency representation, input through
> registrars and
> registries (such as the extensive list you document in your recent
> submission to the TF) and so on.
>
> > To date, the task force has still not fully or reasonably addressed the
> > concerns raised by the VeriSign registrar.
>
> I substantially disagree. I would like to hear more from you on this point
> however because despite the Task Force taking great pains to
> ensure that the
> concerns presented by the dissenting voices were taken into account by the
> TF recommendations, they still continue to oppose our work. Do you see a
> pattern here? Verisign has opposed every single transfer proposal made to
> date. Over half of all outbound transfers *today* come from Verisign to
> another registrar. Might it be that supporting a rational
> portability policy
> isn't in their economic interests? Well, neither is ICANN and much of the
> work that we do here, but given the mandate we have surrounding
> competition,
> we shouldn't let that stop us now. Reasoned objections are one thing,
> irrational holdouts are another.
>
> > concerns raised by the VeriSign registrar.  Neither has the task force
> > considered or evaluated the proposals put forth by participants such as
> > register.com which covered authentication/notarization issues
> and topics,
> > among others, such as the use/appropriateness of Registrar Lock (see
>
> Incorrect. In fact, even though the communication that you reference
> predates the existence of the task force, the proposal initially
> tabled with
> the task force specifically included a flag of these points for further
> consideration and they were substantially analysed through the development
> of the recommendations...specifically...
>
> Requirement #1 - Clear definition of AA
>
> "1)	Definition of individual who has the apparent authority to
> legally bind
> the Registered Name holder."
>
> See above. Dealt with by report.
>
> Requirement #2 - Allow third parties to initiate transfer requests
>
> "2)	Process for Transfers initiated by Indirect Partners of Gaining
> Registrars."
>
> Clearly covered by report - I'll let you look this one up, but its
> specifically in there.
>
> Requirement #3 - Repatriation of domain names
>
> "3)	Gaining Registrar transferring domain names back to the
> Losing Registrar
> in a case where it has been demonstrated that the Gaining
> Registrar did not
> act in accordance with the practices and processes contemplated by this
> document.  Gaining Registrar's indemnification of the Losing Registrar
> against legal recourse in such cases.
>
> Covered by the report through the complaint and appeals process. Further
> consultation on this point has uncovered that we also need a technical
> "undo" function. Undo has not been contemplated by the Task Force at this
> point, however this functionality requirement was only uncovered
> through the
> PC process.
>
> Requirement #4 - Describing when and where registrar_lock should
> and should
> not be employed by registrars.
>
> "4)	Appropriateness of Registrar Lock."
>
> Recommendations concerning this registry feature are peppered
> throughout the
> report.
>
> Requirement #5 - Notarizing physical documents obtained by the Gaining
> Registrar.
>
> "5)	A requirement to authenticate or notarize some, or all, of
> the transfer
> ocumentation procured by the Gaining Registrar."
>
> Rejected by the Task Force as being to localized to the US, unwieldy for
> registrants and users. This was generally not viewed as being practical by
> the user communities. The complete analysis will be part of the record in
> the form of the conference call transcripts that will be released with the
> final report.
>
> Further, also note that Register.com was extensively involved in the
> creation of the document that they criticise above. I will leave it to
> others to determine whether or not this constitutes reasonable
> objections or
> not.
>
> > The work-product of the Task Force remains substantially incomplete, and
> no
> > amount of dancing around the issue will hide the fact that most
> task force
> > members have simply not been following the discussions on transfers that
> have
> > been occurring on the registrar and public forum lists and
> remain largely
> > unaware of the huge amount of outstanding unresolved issues.
>
> Incorrect on both counts. In fact, you might be interested in the rather
> well-reasoned objections by the IP constituency today on our weekly
> conference call in which the IP constituency rep and the registry rep both
> talked me out my my proposal to have further discussion on the pure-EPP
> model on the basis that it was distractive due to the fact that
> none of the
> registries are using pure-EPP. Rather well informed if you ask me.
>
> > participation from several constituencies being limited in the extreme.
> In
> > part this may be blamed on the actions of your Chair that worked ever so
> > diligently to exclude representatives from the registrant community.  In
> part
>
> Is conclusion as well-founded as the rest that you present in your message
> below?
>
> > One major issue that I view as still unresolved is where the proposed
> policy
> > will live.
>
> This is correct. Our prior recommendations on this issue have
> been withdrawn
> due to input from the community, the staff and the Names Council.
> While the
> task force is expected to be precise in its recommendations, we cannot
> specify implementation - ie, which contracts get modified and
> how. This task
> is beyond the scope of the DNSO. Instead, it has been requested that we be
> as precise as possible in our description of what the desired effect of
> these recommendations is in order that the lawyers and contracted parties
> can sort this out and implement the recommendations as the community has
> envisaged.
>
>
> > It is also certainly possible for a proposed policy to live within the
> > context of a registrar Code of Conduct.
>
> Nope - beyond the scope of the DNSO. Only a consensus of accredited
> registrars can adopt a binding code of conduct - already been
> down that road
> (remember the first six months of this issue before there was a
> task force?)
>
>
> > Also, the concerns of the registrant community have not been fully taken
> into
> > consideration by the task force, if at all.  We have to put up with
> > horrendous verification systems, we are confronted with language issues,
> and
> > most often we don't even know who the registrar is for our
> domain as many
> > registrations are handled by ISPs and other resellers that
> don't routinely
> > make the registrant aware of who the actual registrar-of-record is.  The
> > proposal on the table solves none of these problems.  We have
> registrants
> > complaining of "lost years" in the transfers process with no method to
> obtain
> > redress of their grievances, we have rampant confusion owing to the
> unknown
> > length of grace periods and aggravation owing to the shortness of time
> > available to respond to a registrar in the transfers process.
> Again, the
> > proposal fails to address these issues.  We have a failure on
> the part of
> > both ICANN and the registrars to clearly communicate the procedures and
> > policies relating to transfers ,and nothing in the proposal
> which forces a
> > registrar to clearly state the conditions for a successful
> transfer either
> on
> > their websites or in their terms of service contracts.
>
> Do you propose that ICANN regulate the market behavior of the industry?
> Setting minimum standards for things like transfers is one thing,
> requiring
> specific behaviors such as those you describe are completely
> another. If you
> are serious with this remark, might I recommend that you ensure that it is
> tabled with the TF? I don't see support for the proposition
> coming from the
> Registrar or Registry constituency, but if the user voice is
> united on these
> points, we may have to reconsider our respective positions. My
> preference is
> to allow Registrars and Registries to provide shitty service. The market
> will eventually separate the wheat from the chaff. Also note that the task
> force has discussed this specific point at length.
>
> > Finally, we have registrars that create their own policies (such as
> "unpaid
> > status") and utilize loopholes to game the process.  The proposal offers
> > little comfort to those of us that understand the capacity of
> these rogue
> > registrars to circumvent the system.  If they don't abide by
> the spirit of
> > the rules in place now, how can you possibly expect them to
> abide by a new
> > set of rules without some type of sanctions program as a deterrent to
> > continued abusive behavior?  Sure, I know that the idea of sanctions is
> > anathema to the registrar constituency, but abusive and rogue behavior
> > deserves to be punished, and some of these registrars need to be slammed
> down
> > hard.
>
>
> Can you be more specific where the recommendations fall short in this
> regard. Remember, the dispute resolution clauses require the
> losing party to
> cover the cost of the proceedings...this adds up quickly when the
> rules are
> being abused.
>
> > I plan to join the conference call on transfers scheduled for
> November 11.
> I
> > encourage others to do the same.  Details may be found at
> > http://www.dnso.org/clubpublic/nc-transfer/Arc00/msg00603.html
>
> To be quite honest, I'd prefer if the general community did *not* attend
> this call in large numbers for a very practical reason. The
> purpose of this
> call is to allow me to continue a dialogue that I started with my
> constituency (as their TF) rep while we were in China. We ran out
> of time in
> our constituency meeting and did not get the chance to completely
> enumerate
> the entire list of concerns that the membership had with the
> interim report.
> This call is not a DNSO sponsored call, it is a Tucows sponsored call. My
> boss will kill me if 50 people show up. Further, input will not
> be solicited
> from observers during this call, solely registrar constituency
> members will
> be consulted. If the GA wishes to have a call with their rep,
> this is their
> perogative, but it is really beyond my financial and political means to
> provide a complete forum for all interested policies (in other
> words, sorry
> for the misconception, I should have been clearer when I said "observers",
> but really, I only intended for registrars to show up.)
>
> Thanks for the discourse - I hope it has been as useful for you as it has
> been for me. Regardless, you know where to find me :)
>
>
>                      -rwr
>
>
>
>
> Got Blog? http://www.byte.org/blog
>
> "People demand freedom of speech as a compensation for the freedom of
> thought which they seldom use."
>  - Soren Kierkegaard
>
>
>
> ----- Original Message -----
> From: <DannyYounger@cs.com>
> To: <Jeff.Neuman@neustar.us>; <ga@dnso.org>
> Cc: <mcade@att.com>
> Sent: Thursday, November 07, 2002 11:15 PM
> Subject: Re: [ga] Ignoring the Rules
>
>
> > Jeff,
> >
> > When the transfers task force process commenced we were all keenly aware
> of
> > the views held by the VeriSign registrar, BB Online UK Limited, Internet
> > Domain Registrars, Namesecure.com and register.com.  As time went by,
> other
> > registrars joined this particular camp:  BulkRegister.com, Go Daddy,
> > NameScout, Wild West Domains, Totalnic,  joker.com and others.
> Yet during
> > all this time, the task force only considered a single proposal that
> > represented the thinking of the numeric majority of the registrar
> > constituency without affording due consideration to those within the
> > constituency that held differing views (even though those others
> collectively
> > account for more than 60% of all the registrations in the gTLD
> namespace).
> >
> > Over one year ago Bruce Beckwith made the following remark on the
> registrar
> > list regarding the developing transfers document:
> >
> > "In addition, as we have stated in the past, this document should also
> > address the thorny issues of setting clear definitions for many
> aspects of
> > registrar transfers.  For example, we need to clearly define apparent
> > authority, as well as how a third party could validate transfers.  There
> is
> > also not sufficient discussion in the document on the
> registrar/registrant
> > contract, and how/whether an ISP/reseller can act as an agent
> on behalf of
> > the registrant, since they are not a party to the registrar/registrant
> > contract (a facet of the apparent authority definition that is needed).
> > Finally, it is very important that we understand that
> non-registrars need
> to
> > participate in the policy-formation process for the result to have
> > credibility.  Most importantly, we need to consult with
> registrants (i.e.,
> > consumers), who are the very important other half of this equation."
> > http://www.dnso.org/clubpublic/registrars/Arc01/msg01287.html
> >
> > To date, the task force has still not fully or reasonably addressed the
> > concerns raised by the VeriSign registrar.  Neither has the task force
> > considered or evaluated the proposals put forth by participants such as
> > register.com which covered authentication/notarization issues
> and topics,
> > among others, such as the use/appropriateness of Registrar Lock (see
> > http://www.dnso.org/clubpublic/registrars/Arc01/msg01314.html ).
> >
> > The work-product of the Task Force remains substantially incomplete, and
> no
> > amount of dancing around the issue will hide the fact that most
> task force
> > members have simply not been following the discussions on transfers that
> have
> > been occurring on the registrar and public forum lists and
> remain largely
> > unaware of the huge amount of outstanding unresolved issues.
> Debate and
> > discussion on the task force list has also been minimal at best with
> > participation from several constituencies being limited in the extreme.
> In
> > part this may be blamed on the actions of your Chair that worked ever so
> > diligently to exclude representatives from the registrant community.  In
> part
> > this also may be blamed on the registrar constituency that chose to only
> have
> > one representative on the task force, when clearly the
> "minority" views of
> > the constituency should also have been expressed with equal vigor by
> another
> > representative.
> >
> > Jeff, I don't know why you are of the belief that it is up to
> any of us to
> > formally "present" proposals to the task force... contrariwise, the
> > obligation falls on the task force to pay attention to
> discussions in the
> > community and to proactively gather the necessary
> data/commentary in order
> to
> > reach out to those that might be impacted by a pending proposal.  Simply
> > putting up an interim report on a website does not constitute necessary
> > outreach, not if you actually expect to take their views into
> consideration.
> > I am still of the view that the TF is doing no more than "going through
> the
> > motions" and will jam through the proposal on the table simply
> in order to
> > meet an arbitrary publication deadline.  I would like to see you extend
> the
> > comment period for at least another full month so that counter-proposals
> may
> > be both offered and considered prior to any final action being
> recommended.
> >
> > One major issue that I view as still unresolved is where the proposed
> policy
> > will live.  While you have noted that Chuck Gome's proposed
> policy is very
> > similar to the TF recommendations, one essential difference lies in how
> this
> > policy comes to life.  Under the VeriSign proposal, the registry is
> > essentially the entity responsible for creating the language
> that governs
> the
> > transfers process, and each registry in conjunction with ICANN
> may act to
> > amend their registry contracts to impose their protocols upon the
> registrars.
> >  No consultation with either the registrar constituency or the
> DNSO proper
> is
> > required in this scenario, only ICANN's tacit agreement.  As a matter of
> > prudent policy, I am not comfortable with this particular approach that
> can
> > trump the views of all other parties in the ICANN process.
> However, I am
> > even more bothered by the fact that the Task Force hasn't even
> considered
> or
> > evaluated the relative merits of Chuck's proposal (or for that
> matter any
> > other policy now in place in the ccTLD community, be it the
> auda policies
> or
> > those in place in .ca or elsewhere).
> >
> > If the proposed policy is expected to live within a revision to
> Exhibit B
> to
> > the registry-registrar contract, then I am equally concerned that this
> > unequivocally removes ICANN from the sphere of enforcement as
> noted by the
> > language utilized in Reconsideration Decision 02-2, wherein it
> is stated:
> > "Because the "registrar requirements" regarding transfers are
> not included
> in
> > any contract enforceable by ICANN, it is not appropriate that ICANN
> attempt
> > to enforce them."
> > http://www.icann.org/committees/reconsideration/rc02-2.htm
> The matter of
> > who "enforces" transfers is of great concern to registrants who
> would not
> > feel comfortable with the prospect of the VeriSign registry acting as
> judge
> > over matters that involved their own subsidiary company, the VeriSign
> > registrar.
> >
> > If the proposed policy is to live within the Registrar Accreditation
> > Agreement to which ICANN is indeed a signatory, then I would be
> a lot more
> at
> > ease, but we still haven't resolved the issue of who is charged with the
> > enforcement obligations.  If this is a matter that involves compliance
> with
> > contracts, then why would it not be appropriate for such matters to be
> under
> > the direct purview of the ICANN Contract Compliance Monitor,
> the position
> > recently created in the new budget?  Further, what exactly will be the
> role
> > of the Ombudsman in these matters?  Supposedly, the Ombudsman's
> office is
> > charged with the resolution of grievances, and a dispute over a transfer
> > certainly qualifies as a grievance.  Ultimately, the task force must
> > determine what ICANN considers its role to be relative to enforcement of
> the
> > existing contracts... has anyone on the TF taken the time to
> ask the ICANN
> > Board what its view of this situation is?  Why rush into a proposal for
> > dispute mechanisms of the kind that are proposed without first getting
> input
> > from the Board?
> >
> > It is also certainly possible for a proposed policy to live within the
> > context of a registrar Code of Conduct.  This would have the effect of
> making
> > the representations therein actionable under law.  As a matter
> of policy,
> we
> > should have a self-policing industry that is guided by such
> Codes (unless
> of
> > course the contracting parties prefer that we begin to lobby our local
> > governments to implement "regulations" designed to reign in the rogue
> element
> > in this industry).
> >
> > Also, the concerns of the registrant community have not been fully taken
> into
> > consideration by the task force, if at all.  We have to put up with
> > horrendous verification systems, we are confronted with language issues,
> and
> > most often we don't even know who the registrar is for our
> domain as many
> > registrations are handled by ISPs and other resellers that
> don't routinely
> > make the registrant aware of who the actual registrar-of-record is.  The
> > proposal on the table solves none of these problems.  We have
> registrants
> > complaining of "lost years" in the transfers process with no method to
> obtain
> > redress of their grievances, we have rampant confusion owing to the
> unknown
> > length of grace periods and aggravation owing to the shortness of time
> > available to respond to a registrar in the transfers process.
> Again, the
> > proposal fails to address these issues.  We have a failure on
> the part of
> > both ICANN and the registrars to clearly communicate the procedures and
> > policies relating to transfers ,and nothing in the proposal
> which forces a
> > registrar to clearly state the conditions for a successful
> transfer either
> on
> > their websites or in their terms of service contracts.
> >
> > Finally, we have registrars that create their own policies (such as
> "unpaid
> > status") and utilize loopholes to game the process.  The proposal offers
> > little comfort to those of us that understand the capacity of
> these rogue
> > registrars to circumvent the system.  If they don't abide by
> the spirit of
> > the rules in place now, how can you possibly expect them to
> abide by a new
> > set of rules without some type of sanctions program as a deterrent to
> > continued abusive behavior?  Sure, I know that the idea of sanctions is
> > anathema to the registrar constituency, but abusive and rogue behavior
> > deserves to be punished, and some of these registrars need to be slammed
> down
> > hard.
> >
> > I plan to join the conference call on transfers scheduled for
> November 11.
> I
> > encourage others to do the same.  Details may be found at
> > http://www.dnso.org/clubpublic/nc-transfer/Arc00/msg00603.html
> > --
> > This message was passed to you via the ga@dnso.org list.
> > Send mail to majordomo@dnso.org to unsubscribe
> > ("unsubscribe ga" in the body of the message).
> > Archives at http://www.dnso.org/archives.html
> >
>
> --
> This message was passed to you via the ga@dnso.org list.
> Send mail to majordomo@dnso.org to unsubscribe
> ("unsubscribe ga" in the body of the message).
> Archives at http://www.dnso.org/archives.html
>

--
This message was passed to you via the ga@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html