Subject: GA-DIGEST V1 #1502
From: [email-masked] (GA-DIGEST)
To: [email-masked]

GA-DIGEST          Friday, November 8 2002          Volume 01 : Number 1502

----------------------------------------------------------------------

Date: Fri, 08 Nov 2002 05:45:41 -0500
From: Joanna Lane <[email-masked]>
Subject: RE: [ga] Ignoring the Rules

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: [email-masked] [mailto:[email-masked]]On Behalf Of Ross Wm.
> Rader
> Sent: Friday, November 08, 2002 1:05 AM
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]
> 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: <[email-masked]>
> To: <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>
> 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 [email-masked] list.
> > Send mail to [email-masked] 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 [email-masked] list.
> Send mail to [email-masked] 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 [email-masked] list.
Send mail to [email-masked] to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html

------------------------------

Date: Fri, 8 Nov 2002 06:49:45 EST
From: [email-masked]
Subject: Re: [ga] Ignoring the Rules

Ross,

You write:  "AA (apparent authority) no longer exists, therefore the concern 
is moot."  

Just because a few members of the task force have recommended that the 
concept of AA be ditched, this does not equate to the concern necessarily 
being moot.  If this were the case, then why did a group of registrars deem 
it necessary to re-visit the issue?  Their comment follows:

"The current proposal creates an incentive for gaining registrars to obtain 
the customer's "apparent authority" by more avenues, possibly including 
deceptive marketing practices, since it will allow for transfers without 
verification of the registrant's objective manifestation of intent to 
transfer.  How does the proposal address the situation where "apparent 
authority" is obtained by fraud or deceptive marketing?  In such a case, 
there is no real authority for the transfer, and auto-ACK makes it easier to 
perpetrate the fraud.  What if a registrar that is known to harbor fraudulent 
resellers or to use deceptive marketing tactics originates a transfer 
request?  Again, doesn't auto-ACK simply facilitate these entities 
perpetrating fraud against consumers?"  
http://www.dnso.org/clubpublic/registrars/Arc01/doc00125.doc

Regarding 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), 
you write:  "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."  
Let's take a look at a real-world situation often raised in discussions led 
by David Wascher of IARegistry -- A Telco-ISP buys out another which causes a 
mass displacement of thousands of users... the gaining Telco-ISP wishes to 
cut a deal with a different registrar... under your proposal, the Telco-ISP 
would have to send a letter to 10,000+ customers asking each of them to 
formally grant the Telco-ISP Administrative Contact privileges in order to 
effect the change. The ability for this Telco to request a transfer is where 
the Apparent Authority definitions (that you consider to be moot) comes into 
play.  I can see this TF proposal having seriously deleterious effects upon 
the IARegistry business model.  Has the Task Force specifically contacted 
this potentially impacted party to secure their views?

In my view the TF has shown little regard for the economic impact of their 
recommendations... to quote your last message, "Might it be that supporting a 
rational portability policy isn't in their economic interests?"  Economic 
interests are very much the operative reality.  A Task Force that hasn't 
given consideration to the risk/cost factors of implementing a new policy 
hasn't properly done their job.  In response to this concern a group of 
registrars recently wrote:  "The current proposal would require significant, 
costly changes to Registrar and Registry systems, as well as to certain 
aspects of business models and practices that have evolved over the last 
year.  These must be taken into account prior to making changes."  I see no 
evidence that the TF has taken these matters into account as the report 
defers consideration of the risk/cost analysis until after the public comment 
period (in contravention of the Council Rules of Procedure which make it 
clear that such considerations shall be presented within the Interim Report).

You write that "the task force has specifically consulted with the needs of 
the user community through a variety of outreach efforts".   I disagree.  An 
occasional open conference call that is poorly publicized does not constitute 
proper outreach.  Did the TF post any messages to slashdot, notify the Better 
Business Bureaus, contact representatives of the Cyberspace Association 
(IDNO), the Domain Name Rights Coalition, or the Small Business 
Administration offices to make users aware of your activities?  Was any 
effort made to contact representatives from icannatlarge or from any other 
At-large structure?  The record of outreach that you propose to detail in a 
later report is a sham.   As to your remark regarding other "constituencies" 
representing the users... that is just pure BS.  

Ross, it has taken the TF a full year to arrive at an Interim Report, and now 
you expect that within three weeks affected parties can adequately respond by 
way of the notice-and-comment provisions and table well-developed salient 
counter-proposals... this is irrational and does not serve the needs of 
affected parties.  The process is so deficient that these parties have no 
other choice but to actively oppose your efforts -- their business models are 
at stake and you can't expect them to behave in any other fashion.  What is 
called for is to open up your perversely closed task force to these other 
groups to allow them to fully participate in the decision-making process.  
Give them the necessary time to present a counter-proposal with substantive 
arguments or let the record show that they had no proposal to offer in lieu 
of the current recommendations.  There is no compelling need for a mad rush 
to complete the TF work in time for an arbitrary Amsterdam deadline.  Do the 
right thing and extend the comment period long enough to secure the needed 
commentary from all affected parties that need a certain amount of time to 
formulate their thoughts... after all, it took you guys over a year just to 
formulate your own set of recommendations.   

Finally, as to the market behavior of the industry, I do believe that it 
should be regulated but I don't believe that ICANN should function as such a 
regulator.  It lacks the expertise, accountability and legitimacy to function 
in such a capacity.  It can however, act to enforce the contracts to which it 
is a party, and any new proposed policy should involve ICANN as a contracting 
party charged with an enforcement responsibility.  

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

------------------------------

Date: Fri, 8 Nov 2002 07:48:34 EST
From: [email-masked]
Subject: [ga] Listen-only ports

Bruce,

The current ICANN Bylaws state:  "Except where determined by a majority vote 
of members of the NC present that a closed session is appropriate, meetings 
shall be open to physical or electronic attendance by all interested 
persons."  I am interested in exercising my right to electronic attendance at 
the upcoming Names Council session.  Please advise if listen-only ports will 
be made available to the community in compliance with these bylaws.

P.S. You will also note that the proposed bylaws also invoke a virtually 
identical clause:  "Except where determined by a majority vote of members of 
the GNSO Council present that a closed session is appropriate, meetings shall 
be open to physical or electronic attendance by all interested persons."
- --
This message was passed to you via the [email-masked] list.
Send mail to [email-masked] to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html

------------------------------

Date: Fri, 8 Nov 2002 14:30:36 +0100
From: DNSO Secretariat <[email-masked]>
Subject: [ga] dnso.org - Search service

[[email-masked]]
[[email-masked]]
[[email-masked]]
[[email-masked]]

Just to inform you that a search service has been installed on the dnso.org homepage.

DNSO sec.
- --
This message was passed to you via the [email-masked] list.
Send mail to [email-masked] to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html

------------------------------

Date: Fri, 8 Nov 2002 09:21:56 -0500
From: "Ross Wm. Rader" <[email-masked]>
Subject: Re: [ga] Ignoring the Rules

This is not a productive conversation. As Jeff pointed out, substantive
input on the product is required. But given your penchant for defending the
sometimes illogical actions of your former employer and the incumbent
monopolist, one quick last stab at it from my end.

> "The current proposal creates an incentive for gaining registrars to
obtain
> the customer's "apparent authority" by more avenues, possibly including
> deceptive marketing practices, since it will allow for transfers without
> verification of the registrant's objective manifestation of intent to
> transfer.  How does the proposal address the situation where "apparent
> authority" is obtained by fraud or deceptive marketing?  In such a case,
> there is no real authority for the transfer, and auto-ACK makes it easier
to
> perpetrate the fraud.  What if a registrar that is known to harbor
fraudulent
> resellers or to use deceptive marketing tactics originates a transfer
> request?  Again, doesn't auto-ACK simply facilitate these entities
> perpetrating fraud against consumers?"

There is no logic to the above statement. If Apparent Authority does not
exist, it cannot be seen to increase fraudulent behavior. Further, we have
heard many times that the primary problem that needs to be solved is that of
registrars gaming the system (n'ack with out notice etc.), not deceptive
marketing. There is demonstrable community support for the concept and
quantifiable support in the form of current dynamics. Lastly, it is beyond
the scope of the DNSO to design a policy to regulate the marketing tactics
of third parties - especially those not under contract with ICANN.

> play.  I can see this TF proposal having seriously deleterious effects
upon
> the IARegistry business model.  Has the Task Force specifically contacted
> this potentially impacted party to secure their views?

The Task Force has consulted with this party *several* times. The fact that
the privileges I suggest can be obtained when a domain name is renewed or
activated through the registration agreement seemed to be a reasonable
compromise between security and portability.

> registrars recently wrote:  "The current proposal would require
significant,
> costly changes to Registrar and Registry systems, as well as to certain
> aspects of business models and practices that have evolved over the last
> year.  These must be taken into account prior to making changes."  I see
no

As a registrar, I completely fail to see how this is a reasonable statement.
We have asked for specific demonstrations of this comment, but we have yet
to see them.

> proper outreach.  Did the TF post any messages to slashdot, notify the
Better
> Business Bureaus, contact representatives of the Cyberspace Association
> (IDNO), the Domain Name Rights Coalition, or the Small Business
> Administration offices to make users aware of your activities?  Was any
> effort made to contact representatives from icannatlarge or from any other

Our efforts were widely promoted throughout the GA and the constituencies -
in other words, throughout the DNSO where this type of work is to be
conducted. We really tried to leave it to the various members to decide if
they wanted to participate or not.

> later report is a sham.   As to your remark regarding other
"constituencies"
> representing the users... that is just pure BS.

Very productive and substantive, bravo.

> Ross, it has taken the TF a full year to arrive at an Interim Report, and
now
> you expect that within three weeks affected parties can adequately respond
by
> way of the notice-and-comment provisions and table well-developed salient
> counter-proposals... this is irrational and does not serve the needs of

No, I expect participants in the DNSO to take advantage of the two-way
street that the TF has set up. For instance, I have published numerous
interim drafts to my constituency over the last few months. There should be
no surprises for anyone here. Of course, your mileage may vary depending on
the constituency, forum and individual interest.

> affected parties.  The process is so deficient that these parties have no
> other choice but to actively oppose your efforts -- their business models
are
> at stake and you can't expect them to behave in any other fashion.

I keep hearing this from Verisign and Register.com, but I'm not seeing it be
demonstrated. One would think that for two organizations with their business
models at stake that they would be more specific in describing what their
concerns were. I find it interesting that Verisign, when asked about their
specific objections in Shanghai, declined to elaborate on the record. We can
only listen to those that speak Danny.

> affected parties.  The process is so deficient that these parties have no
> other choice but to actively oppose your efforts -- their business models
are
> at stake and you can't expect them to behave in any other fashion.  What
is
> called for is to open up your perversely closed task force to these other
> groups to allow them to fully participate in the decision-making process.
> Give them the necessary time to present a counter-proposal with
substantive
> arguments or let the record show that they had no proposal to offer in
lieu
> of the current recommendations.  There is no compelling need for a mad
rush

These parties have been intimately involved at every step of the way and
there is no reason why they could not have developed their own set of
recommendations at any point over the last two years - had they chosen to do
so. The final record will document all contributions, or lack thereof.

Thanks,

                     -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: <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, November 08, 2002 6:49 AM
Subject: Re: [ga] Ignoring the Rules

> Ross,
>
> You write:  "AA (apparent authority) no longer exists, therefore the
concern
> is moot."
>
> Just because a few members of the task force have recommended that the
> concept of AA be ditched, this does not equate to the concern necessarily
> being moot.  If this were the case, then why did a group of registrars
deem
> it necessary to re-visit the issue?  Their comment follows:
>
> "The current proposal creates an incentive for gaining registrars to
obtain
> the customer's "apparent authority" by more avenues, possibly including
> deceptive marketing practices, since it will allow for transfers without
> verification of the registrant's objective manifestation of intent to
> transfer.  How does the proposal address the situation where "apparent
> authority" is obtained by fraud or deceptive marketing?  In such a case,
> there is no real authority for the transfer, and auto-ACK makes it easier
to
> perpetrate the fraud.  What if a registrar that is known to harbor
fraudulent
> resellers or to use deceptive marketing tactics originates a transfer
> request?  Again, doesn't auto-ACK simply facilitate these entities
> perpetrating fraud against consumers?"
> http://www.dnso.org/clubpublic/registrars/Arc01/doc00125.doc
>
> Regarding 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),
> you write:  "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."
> Let's take a look at a real-world situation often raised in discussions
led
> by David Wascher of IARegistry -- A Telco-ISP buys out another which
causes a
> mass displacement of thousands of users... the gaining Telco-ISP wishes to
> cut a deal with a different registrar... under your proposal, the Telco-IS
P
> would have to send a letter to 10,000+ customers asking each of them to
> formally grant the Telco-ISP Administrative Contact privileges in order to
> effect the change. The ability for this Telco to request a transfer is
where
> the Apparent Authority definitions (that you consider to be moot) comes
into
> play.  I can see this TF proposal having seriously deleterious effects
upon
> the IARegistry business model.  Has the Task Force specifically contacted
> this potentially impacted party to secure their views?
>
> In my view the TF has shown little regard for the economic impact of their
> recommendations... to quote your last message, "Might it be that
supporting a
> rational portability policy isn't in their economic interests?"  Economic
> interests are very much the operative reality.  A Task Force that hasn't
> given consideration to the risk/cost factors of implementing a new policy
> hasn't properly done their job.  In response to this concern a group of
> registrars recently wrote:  "The current proposal would require
significant,
> costly changes to Registrar and Registry systems, as well as to certain
> aspects of business models and practices that have evolved over the last
> year.  These must be taken into account prior to making changes."  I see
no
> evidence that the TF has taken these matters into account as the report
> defers consideration of the risk/cost analysis until after the public
comment
> period (in contravention of the Council Rules of Procedure which make it
> clear that such considerations shall be presented within the Interim
Report).
>
> You write that "the task force has specifically consulted with the needs
of
> the user community through a variety of outreach efforts".   I disagree.
An
> occasional open conference call that is poorly publicized does not
constitute
> proper outreach.  Did the TF post any messages to slashdot, notify the
Better
> Business Bureaus, contact representatives of the Cyberspace Association
> (IDNO), the Domain Name Rights Coalition, or the Small Business
> Administration offices to make users aware of your activities?  Was any
> effort made to contact representatives from icannatlarge or from any other
> At-large structure?  The record of outreach that you propose to detail in
a
> later report is a sham.   As to your remark regarding other
"constituencies"
> representing the users... that is just pure BS.
>
> Ross, it has taken the TF a full year to arrive at an Interim Report, and
now
> you expect that within three weeks affected parties can adequately respond
by
> way of the notice-and-comment provisions and table well-developed salient
> counter-proposals... this is irrational and does not serve the needs of
> affected parties.  The process is so deficient that these parties have no
> other choice but to actively oppose your efforts -- their business models
are
> at stake and you can't expect them to behave in any other fashion.  What
is
> called for is to open up your perversely closed task force to these other
> groups to allow them to fully participate in the decision-making process.
> Give them the necessary time to present a counter-proposal with
substantive
> arguments or let the record show that they had no proposal to offer in
lieu
> of the current recommendations.  There is no compelling need for a mad
rush
> to complete the TF work in time for an arbitrary Amsterdam deadline.  Do
the
> right thing and extend the comment period long enough to secure the needed
> commentary from all affected parties that need a certain amount of time to
> formulate their thoughts... after all, it took you guys over a year just
to
> formulate your own set of recommendations.
>
> Finally, as to the market behavior of the industry, I do believe that it
> should be regulated but I don't believe that ICANN should function as such
a
> regulator.  It lacks the expertise, accountability and legitimacy to
function
> in such a capacity.  It can however, act to enforce the contracts to which
it
> is a party, and any new proposed policy should involve ICANN as a
contracting
> party charged with an enforcement responsibility.
>
>
>
>
>
>
>

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

------------------------------

End of GA-DIGEST V1 #1502
*************************