Re: [ga] Ignoring the Rules

["Ross Wm. Rader" <ross@tucows.com>]

> 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