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

GA-DIGEST           Friday, August 24 2001           Volume 01 : Number 698

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

Date: Fri, 24 Aug 2001 12:06:11 -0500
From: Raul Echeberria <[email-masked]>
Subject: Re: [ga] Meetings at Montevideo

At 07:12 AM 23/08/01 +0000, Roberto Gaetano wrote:
Some questions to Raul:

Sorry for the delay in answering.

>- are there sessions with simultaneous translation (interpretation)?
>- if yes, which ones?

There will be simultaneous translation Spanish-english-spanish in the GA, 
NC, Public Forum and ICANN Board.

We planned to have Portuguese Translation but most of Brazilians who 
usually  participate in ICANN meetings have told us that their spanish 
and/or english understanding is enough good, so Portuguese translation 
would not be necessary.

>- if yes, who is paying, ICANN or the sponsors?

We, the Host Committee with our sponsors.

>Regards
>Roberto

Hope to see you.

Raul

- --
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, 24 Aug 2001 11:45:10 -0400
From: "Gomes, Chuck" <[email-masked]>
Subject: RE: [ga] Meetings at Montevideo

As with the the IFWP meeting in Buenos Aires in 1998, the Latin American
community is once again proving to be a shining example of being a meeting
host.  My compliments to the team.

Chuck Gomes

- -----Original Message-----
From: Raul Echeberria [mailto:[email-masked]]
Sent: Friday, August 24, 2001 1:06 PM
To: [email-masked]
Subject: Re: [ga] Meetings at Montevideo

At 07:12 AM 23/08/01 +0000, Roberto Gaetano wrote:
Some questions to Raul:

Sorry for the delay in answering.

>- are there sessions with simultaneous translation (interpretation)?
>- if yes, which ones?

There will be simultaneous translation Spanish-english-spanish in the GA, 
NC, Public Forum and ICANN Board.

We planned to have Portuguese Translation but most of Brazilians who 
usually  participate in ICANN meetings have told us that their spanish 
and/or english understanding is enough good, so Portuguese translation 
would not be necessary.

>- if yes, who is paying, ICANN or the sponsors?

We, the Host Committee with our sponsors.

>Regards
>Roberto

Hope to see you.

Raul

- --
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, 24 Aug 2001 18:08:36 +0200
From: "Dom..." <[email-masked]>
Subject: [ga] Un message aux français...

Bonjour aux français inscrits sur cette liste (il doit bien y en
avoir quelques uns, au vu des adresses d'emails...).

Je m'y suis inscrit moi même suite au message d'Annie Renard qui
regrettait qu'aussi peu de français soient représentés dans les
instances internationales d'Internet.

Plein de bonnes volonté, me voilà donc inscrit depuis quelques
temps, mais je dois hélas avouer que mon manque de maîtrise de la
langue anglaise me fait passer à côté de pas mal de chose.

Je n'ai pas trouvé comment voter, et je pense qu'aujourdhui,
c'est sans doute trop tard...

Ne serait-il pas possible de traduire les informations les plus
importantes ?

Excuse me for this message in french, my English is really too bad...
Dom...
- -- 
[email-masked]

- --
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, 24 Aug 2001 09:16:48 -0700
From: Eric Dierker <[email-masked]>
Subject: [ga] ICANN COMPLIANCE

Dear Members of the GA of the DNSO of  ICANN,

Lately I have had the privilege of working with some countries that are
developing their Internet systems nationwide.  When it comes to
equipment and technology it is easy to handle and/or out source and
begin in and out of country training and education.  From servers to
switches to satellites to systems - money and time are the only
opponents.  When it comes to Policy we are screwed.  There is no
standard, there is no example, there is no order.  The *ISO* for
internet standards is ICANN and I cannot in good conscience recommend
it's policies.  Based upon my time sheets going back over a year I have
spent over 2,500 hours researching archives, articles, treatises etc.
etc. regarding internet strategy, analysis and policy.  I have argued,
debated, probed and been educated by some of the best and the brightest
in the business and academia and have reached the absolute conclusion
that there is no World Wide Open and Transparent Policy setting standard
for the Internet.  But the closest we have is the beast known as ICANN
and the only open and transparent bottoms up apparatus within it is the
GA. God help us.

So I have a few questions.

I ask was there ever any follow up on this?

{written months ago on this list}
> >
> > In the midst of all this procedural to-ing and fro-ing about
elections
> > and suspensions, I have a substantive question:
> >
> > I am attempting to review the various U.S. Committee and
Subcommittee
> > investigations into the activities of ICANN.  Can anyone direct me
to
> > an up-to-date list of all investigations, with links to transcripts?

> > Alternatively, is anyone aware of a summary of all recent
> > investigations?
> >
> > Thank you.

Secondly has anyone ever answered the question of who owns ICANN?

Has ICANN filed for their required 3 year IRS non-profit extension with
proof of following their exemption criteria?

As I understand it Jones and Day handled Postels estate and he owned
ICANN and yet J&D still represent ICANN and have not filed the 
proper probate and corporation papers transferring ownership.

As I further understand the initial contracts with the USG were handled
by Postel and therefor there is a legacy.

If I am to extrapolate I would tell my Europe friends that the *ICANN*
Internet is owned by some sort of Monarchy.  
therefor we should look for a new king or queen and petition 
for a Parliament accordingly.

Laugh as you will but only after you answer the first questions to your
own satisfaction.

I would thank any of you for an intellectual reply.  Yes, this may be a
little tongue in cheek, but how else do we suffer such madness

Sincerely,
Eric
- --
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, 24 Aug 2001 19:11:39 +0200
From: Jefsey Morfin <[email-masked]>
Subject: Re: [ga] FW: ICANN meeting in Montevideo

Dear Vany,
this only shows how absurdly ill managed is the ICANN Corporation.
Do you think that any other Corporation would stand in business five
minutes in having their contractors - what are the SOs - asked to pay
for providing it services?

I think your NC teleconferencing budget is here: ask the operators to
pay you for talking in front of their camera :-)  You will tell them it is
normal ICANN practice.

The ICANN has to decide once for all if it is either:

- -  a Corporation conducting business in order to cover its budget and
    trying to stabilize and protect its revenues in a contractual way as
    does any corporation, choosing its strategy and objective accordingly.
    In that case it is totally subject to competition and it is to drastically
    review its policy in order to pay for what it uses, or to go down.

    So, I want to see a clear plan covering all the expenses incurred by
    the ICANN - including the payment of every travel and expense it
    exposes its contractors and helpers to. When you do not have the
    money for something, you do not spend it. Period.

    I am in NO mood to pay for the ICANN mismanagement. I am in no
    mood to subsidize GIP members with my family money. Nor US
    DoC interests. I already my my French taxes. I am also in NO
    mood to support such a biased mismanagement which hurts my
    interests thought the ICP-3 monopolistic attitude. I fully support
    any competitor who will provide me better, more stable, more
    secure, more professional, more open services, more cooperative
    services. If I was not I would be a fool.

- -  or a non profit association of stake holding Members represented
    through their constituencies, with common good as an objective with
    a budget covered by Members in proportion to the turn-over in the
    Internet area and participating into the cost of the services they
    obtain from he ICANN.

    Such an endeavor being seriously controlled by these Members to
    avoid any mission creep, and being strictly cost limited to the
    Membership fees and contributions.

I would consider as unstabilizing any help a Foundation might bring to
anyone to pay for something owed by the ICANN. I fully support that
a Foundation might pay for Joop attending the Montevideo meeting where
he wants to propose a new project. Or developing ccTLD being helped
as ccTLDs are either customers or Members of the ICANN. I fully
support that my own Foundation spends a very few money on some
ICANN oriented projects.

But, after consideration, I fully disapprove - it was mistake of mine to
fall into that trap and I apologize and correct it here - to ask for my own
travel to Montevideo. No BoD Member, no NC Member, no candidate,
no employee, no contractor should ever pay for any ICANN related
expense. Never.

I even say that every incurred expense of that kind since the start of
the ICANN should be listed by present and former BoD, NC Members,
employees and Candidates and be paid back by the ICANN. I am
extremely serious about this. I fully state that the current practice is
dishonest.

Let be clear, it is not only ethically dishonest. It is also a bad
practice against the Global Internet Community interest. It only favors
lobbying professionalism over professional dedication, network
service management competence and user interest protection. This
destabilizes the network and lead to a de facto monopolistic situation.
This will only resolve through the confusion of the rise of competitors
to the ICANN or international investigation or disinterest.

That ICANN has not the money for its expenses is either due to poorly
computed rates because of an ill understanding of what competition
is, or due to too many totally out of scope issues. IMHO both are true.
This boils down to incompetence and mission creep.

When I learn what you say, there is not a need for a change. There
is an obligation for a stop. I am sorry, Vany, for all that. I apologize for
having smiled at your efforts to get subsidies for you travels I took for
political lobbying. You deserve all my/our respect. But you have to stop.

To conclude I fully understand now why only 2 trips as paid for. Over 2,
if the project was good, it should have be taken, and be now paid, by
the ICANN. It seems that people in Salzburg are wiser than in MdR.

Now, we have many US lawyers here:

- - if in an US citizen, could have Vany tax deducted the cost of her
   travels?
- - how do you qualify the fact for a corporation to pay for the expenses
   of a person on a board in another company it does business with?

Jefsey

On 15:01 24/08/01, Nilda Vany Martinez Grajales said:
>Jefsey and all:
>
>There's no such GA candidates nor NC candidates, etc.    There is simply
>DNSO candidates!!!  If you begin to clasify candidates in such a way that you
>and others are doing, you are simply trying that other's see this process as
>vicious.   And it is not.
>
>As far as I know all candidates was nominated by GA members anyway,  and 
>none of
>such nomineers was NC members.
>
>No NC member is funded by ICANN funds neither DNSO funds to travel to ICANN
>meetings.
>
>And, it can happen that being an NC member or ICANN Board member, such 
>member is
>unable to attend certain ICANN meetings even if the funds are available 
>from own
>funds, company funds, other external sources.
>
>I am an NC member, and it happened that for Stockholm meeting my organization
>didn't have budget for pay for me to attend such meeting, I am unelegible to
>receive funds from Salzburg Seminar because I received in the past two grants.
>I searched other external funds, but I didn't find them.  And guess what? I
>decided to pay from my own pocket the airticket and other expenses while
>in Stockholm and a coleague from Honduras that went also to Stockholm for
>ICANN meeting kindly offered me her room to stay because it has another bed.
>
>Now imagine that the actual situation is for Stockholm meeting and not
>Montevideo meeting, and I have a nomination I accepted for ICANN Board.   My
>situation would be exactly the same.   No funds from DNSO, no funds from
>constituency, no travel grants, no funds from ICANN, no funds from anywhere,
>only my own pocket (and still I don't achieve to make lower my debt with my
>credit card).
>
>All people (including candidates for certain positions) has the same chance to
>decide wether attend or not certain ICANN meetings.  If some of the candidates
>has sponsors or decides to sponsor from their own pocket, or simply doesn't
>finds any sponsor and decides not go, this is the bussiness of everyone and is
>not related in any manner with actual positions they hold (NC members,
>ICANN Board members, etc), because no money comes from ICANN, neither DNSO 
>funds
>to pay or sponsor candidacy activities.
>
>I would like that, in the future, there will be an organization/foundation 
>that
>decides to have travel grants for DNSO candidates when needed or applicable.
>
>And please, keep in mind...all candidates are DNSO candidates!!!
>
>Best Regards
>Vany
>
>
>Jefsey Morfin wrote:
>
> > Bravo Joana!
> > Your English being better than mine I will not spoil it.
> >
> > I will only say:
> > 1. I concurr 100% with every word you say
> > 2. the point is not the candidate capaign but that GA candidates are
> > excluded from possibilities and advatages granted to non-GA candidates
> > however the larger support they get (see the endorsements).
> >
> > Jefsey
> >
> > On 01:25 23/08/01, Joanna Lane said:
> > >on 8/22/01 12:57 PM, Derek Conant at [email-masked] wrote:
> > >
> > > > Was it appropriate to solicit funding on behalf of the DNSO GA without
> > > > formal authorization or permission from the DNSO or ICANN?
> > >
> > >
> > >I have never professed to speak for DNSO GA and do not now, neither have I
> > >solicited funds on behalf of the DNSO GA from anybody.
> > >
> > >There are a lot of generalizations being bandied about in this discussion
> > >about funding of Board candidates for Montevideo. Some of these are 
> missing
> > >the salient points.
> > >
> > >What is being overlooked is that on this particular occasion, the election
> > >of a Board Director coincides with a physical meeting of those judging the
> > >merits of the candidates. That is an unusual situation. None of those
> > >participating in this vote have themselves been subjected to the 
> requirement
> > >to meet f2f with their electorate in advance of their election or
> > >appointment without an election, nor to the best of my knowledge, are 
> any NC
> > >representatives funding their own travel expenses to Montevideo, and yet
> > >they see fit to raise it as an issue with candidates for the current
> > >election. Please correct me if I'm wrong.
> > >
> > >It has not been the practice or the custom for nominees to participate 
> in a
> > >physical meeting with their electorate prior to election, for any position
> > >as Director, member of the NC, Task Forces, GA Chair, or other elected
> > >official of ICANN DNSO. And it wasn't an issue under discussion in this
> > >election, until after the election itself commenced. This could be 
> regarded
> > >as attempts to change the rules of the election after it has started
> > >(whether or not it is a good or bad thing). Therefore, candidates in this
> > >election could not have been expected to think that physical attendance
> > >would be a requirement to qualify, and in fact, it is not. Allegations now
> > >being made that candidates should not have accepted nomination if they 
> were
> > >not prepared to attend, are completely unfounded. If you want to 
> change the
> > >rules, you may do so by consensus, but not retroactively by fiat. If you
> > >allow any organization to impose rules and regulations in this way, 
> there is
> > >no end to abuse, hence the importance of concrete consensus building
> > >procedures to arrive at fair election rules for all affected stakeholders,
> > >something I myself have advocated very strongly since day one, and is
> > >supported by calls for the same by the ALSC and ICANN Board, amongst 
> others.
> > >Attendance of Board candidates at ICANN meetings has not been formally
> > >adopted in any rules, and is therefore outside the scope of any possible
> > >criteria that can be set by the NC in their deliberations to judge
> > >integrity, willingness or interest of any candidate.
> > >
> > >Nevertheless, the NC, at the 11th hour, has in its wisdom, taken the
> > >position that the election should not take place without giving candidates
> > >the opportunity to meet with that part of the electorate that will be in
> > >attendance in Montevideo, and in particular, the ccTLD constituency
> > >representatives who have difficulty communicating with members by other
> > >means. It could therefore be viewed that new criteria set for this 
> election
> > >by one constituency, the ccTLDs, supported by other constituencies, 
> has been
> > >introduced without proper advance notice having been given to affected
> > >stakeholders who have endorsed candidates already, and not necessarily 
> those
> > >who were not planning to attend. It may or may not be that those endorsers
> > >would have rather nominated an alternative candidate. We will never know
> > >simply because the goal posts have moved during the election.
> > >
> > >The notice given to candidates by the NC Teleconference was well past any
> > >reasonable notice period that would normally be required for a person to
> > >make themselves available. Now, what is required is to abandon prior
> > >committments and fly half way round the world for pro bono work, and at
> > >personal expense, since those who have called for the interview are not
> > >willing to pay expenses.
> > >
> > >I was aware that ICANN was a not for profit organization, but I did not
> > >think it was a charity, and for a number of years I have personally
> > >established a policy of charitable giving only to children in need and
> > >regret that ICANN does not qualify. As far as pro bono work, I have given
> > >the major portion of my time for many months to DNSO at the expense of 
> other
> > >pro bono and my own business work that I would normally be doing, and have
> > >to draw the line at out of pocket expenses amounting to thousands of
> > >dollars, whether or not I can afford it.
> > >
> > >Also, it is not my intention to approach my supporters for funding as that
> > >discourages those who may now be deliberating on adding their name in
> > >support, thinking that if they do so, they will be hit for a contribution.
> > >Endorsements of individuals without a corporate paymaster should not come
> > >with a price tag that those with corporate funding do not have to impose.
> > >
> > >Those organizations that do fund participants have either not replied to
> > >inquiries made since this issue arose, or have responded negatively. 
> It has
> > >already been mentioned that it is too late to make such applications.
> > >
> > >I sense this is a sports game, whereby, having already competed as an
> > >unsponsored woman in a largely sponsored man's club and qualified as a
> > >player, run round the field a few times and scored a few points, now, 5
> > >minutes before time, the home base has been moved to a few thousand miles
> > >away, way out of sight......
> > >
> > >In any developing organization, obviously the goal posts will move, but it
> > >is worth noting that the results of moving these specific goal posts 
> at this
> > >particular moment in time *does* discriminate against those that seek to
> > >represent the non-represented, (however coincidental that may be). By
> > >default, this situation favors those candidates with business 
> interests that
> > >are already well represented at all levels, including the Board, and at a
> > >time when even the ALSC is calling for a more diverse and balanced
> > >representation within this organization.
> > >
> > >Is it any wonder that DNSO has begun to splinter off real talent, namely
> > >ccTLDs and now possibly NCDNHC. It is this moving of the goal posts,
> > >backward and forward, that has frustrated genuine participation in the
> > >process, and prevented real improvements being made.
> > >
> > >Too bad this election is an illusion of fair play, rather than evidence of
> > >it. I will, nevertheless, continue to strive and speak out for higher
> > >standards, by whatever means possible. As I said in my candidate 
> statement,
> > >this is a vote for conscience. You do not need me in Montevideo to 
> meet your
> > >own. History will be the judge of your vote.
> > >
> > >Regards,
> > >
> > >Joanna
> > >
> > >The URLs for Best Practices: DNSO Citation:
> > >http://www.dnso.org/dnso/gaindex.html
> > >(Under "Other Information Documents"; "August 2001:
> > >Proposal for Best Practices for the DNSO GA")
> > >Part I:
> > >http://www.dnso.org/dnso/notes/20010813.GA-BestPractices.html
> > >Part II:
> > >http://www.dnso.org/dnso/notes/20010813.GA-BP-flowchart.pdf
> > >(Access to the .pdf file requires installing the Adobe Acrobat
> > >Reader, which is available for free down load at
> > >http://www.adobe.com/products/acrobat/readstep2.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
>
>--
>Nilda Vany Martinez Grajales
>Information Technology Specialist
>Sustainable Development Networking Programme/Panama
>e-mail: [email-masked]
>http://www.sdnp.org.pa
>
>
>
>--
>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, 24 Aug 2001 11:39:26 -0700
From: Kent Crispin <[email-masked]>
Subject: Re: [ga] FW: ICANN meeting in Montevideo

On Fri, Aug 24, 2001 at 07:11:39PM +0200, Jefsey Morfin wrote:
> Dear Vany,
> this only shows how absurdly ill managed is the ICANN Corporation.
> Do you think that any other Corporation would stand in business five
> minutes in having their contractors - what are the SOs

The SOs are not contractors for ICANN.

[500 lines of useless quoted material removed]

- -- 
Kent Crispin                               "Be good, and you will be
[email-masked]                           lonesome." -- Mark Twain
- --
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, 24 Aug 2001 12:13:41 -0700
From: Eric Dierker <[email-masked]>
Subject: [ga] ICANN | Advisory | 23 August 2001

This is a multi-part message in MIME format.

- --Boundary_(ID_Wo05KUl5BNeuXmIqTIYAYA)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

Dear All,

Reference: http://www.icann.org/announcements/icann-pr23aug01.htm

Here is a proposition that due to the great privilege bestowed upon
Verisign we should be able to invoke.

Verisign shall make no changes in implementation of the execution of
its' trilateral contract with ICANN and the DoC without first receiving
approval from the GA of the DNSO of  ICANN.

By contract, executive order and DoC regulations this is doable.  Joanna
wrote this back a few months ago and I think it rings true today;

Joanna Lane wrote:

<major snippage>
>
> You're not going to like this but.... tech problems should never drive

> anything related to policy development for social issues. History
teaches us
> that technical difficulties can be overcome and therefore should be a
low
> priority at this point. First we have to clarify the problem in terms
of
> what is, and is not, socially acceptable, and balance this against
technical
> requirements to maintain the stability of the net and in particular
the DNS.
> Once a socially acceptable solution is found, we identify the
technical
> difficulties in achieving the desired solution, then look for the
technical
> solution. If there is no existing technical solution, we have to
develop
> one. To work the other way round on this particular issue, it to put
the
> cart before the horse.
>
> There is also the issue of creating a single point of failure that
> > doesn't exist now.
>
> Agreed, but if there's only one WHOIS server for each TLD, that is
already a
> single point of failure for that TLD isn't it?
>
> >
> > I have a whois client that looks up the TLD and queries the
appropriate
> > host. It then takes the referer reference and re-queries the actual
host
> > that has the data. Note that ripe.net is already under EU dominion
and
> > they've already altered their whois output.
>
> ... and over time the rest will follow as they realize that they have
no
> idea how many EU citizens are already in their database.
Interesting...
>
> Regards,
> Joanna.

Any highschool research assistant can track Versigns' wholly owned
subsidiry gobble up expired names and offer them for resale.  This would
appear to be private profiteering by exploitation of a government
contract forconcessionairing, which would appear to be unethical.

Sincerely,

Eric

- --Boundary_(ID_Wo05KUl5BNeuXmIqTIYAYA)
Content-type: text/html; charset=us-ascii; name=icann-pr23aug01.htm
Content-transfer-encoding: 7BIT
Content-disposition: inline; filename=icann-pr23aug01.htm
Content-Base: "http://www.icann.org/announcements/ica	nn-pr23aug01.htm"
Content-Location: "http://www.icann.org/announcements/ica	nn-pr23aug01.htm"

<HTML>
<HEAD>
  <META NAME="GENERATOR" CONTENT="Adobe PageMill 3.0 Win">
  <TITLE>ICANN | Advisory | 23 August 2001</TITLE>
</HEAD>
<BODY BGCOLOR="#ffffff">
<P>
<CENTER>
  <TABLE WIDTH="95%" BORDER="0" CELLSPACING="2" CELLPADDING="0">
    <TR> 
      <TD WIDTH="100%"> 
        <P> 
        <CENTER>
          <TABLE BORDER="0" WIDTH="100%" CELLSPACING="2" CELLPADDING="0">
            <tbody> 
            <TR> 
              <TD WIDTH="7%">&nbsp;</TD>
              <TD WIDTH="25%"><font face="Arial, Helvetica, sans-serif"><IMG SRC="http://www.icann.org/logos/icann-logo.gif"
            WIDTH="188" HEIGHT="145" NATURALSIZEFLAG="0" ALIGN="BOTTOM" 
            ALT="ICANN Logo"></font></TD>
              <TD WIDTH="68%"> 
                <P> 
                  <CENTER>
                    <font face="Arial, Helvetica, sans-serif" size="+2"><B><font size="+3">Advisory</font></B></font> 
                  </CENTER>
                </P>
                <P> 
                  <CENTER>
                    <font face="Arial, Helvetica, sans-serif" size="+1"><i>23 
                    August 2001</i></font> 
                  </CENTER>
              </TD>
            </TR>
            </tbody> 
          </TABLE>
        </CENTER>
        <p></P>
        <P> 
        <CENTER>
          <FONT FACE="Arial"> 
          <HR NOSHADE WIDTH="100%">
          </FONT> 
          <p>&nbsp;</p>
          <p><font face="Arial, Helvetica, sans-serif"><b><font size="+2">Third 
            Advisory Concerning Equitable Allocation of Shared Registration System 
            </font> <font size="+2">Resources</font></b> </font> </p>
        </CENTER>
        <P><font face="Arial, Helvetica, sans-serif">(23 August 2001) As previously 
          reported in advisories dated <a href="http://www.icann.org/announcements/icann-pr16jul01.htm">16 
          July 2001</a> and <a href="http://www.icann.org/announcements/icann-pr10aug01.htm">10 
          August 2001</a>, the registry operator and registrars participating 
          in the Shared Registration System (SRS) for .com/.net/.org have been 
          working together to devise a plan to handle expiring names in a manner 
          that is fair and does not interfere with other activities in the SRS.</font></P>
        <P><font face="Arial, Helvetica, sans-serif">While all parties will continue 
          to look for a long-term solution, the registry operator announced today 
          that it has developed, and is preparing to implement, a short-term measure 
          that will allow for the resumption of the batch delete process. This 
          short-term measure will allow for the return of deleted names to the 
          &quot;pool&quot; of names available for registration by any registrant, 
          through any registrar, on a first-come/first-served basis. This will 
          alleviate the growing backlog of names in delete-pending status and 
          may provide additional data for use in developing appropriate long-term 
          solutions.</font></P>
        <P><font face="Arial, Helvetica, sans-serif">ICANN's Domain Name Supporting 
          Organization has already been advised of the situation and has begun 
          to discuss possible measures for handling expiring names. Members of 
          the community are urged to participate in the DNSO's discussions, so 
          that all viewpoints can be considered in developing measures for fair 
          allocation of expiring names.</font></P>
        <hr NOSHADE width="100%">
        <P><font face="Arial, Helvetica, sans-serif">Subject: [RegistrarsList] 
          Announcement Regarding Suspension of Delete Batch Job and Connection 
          Utilization within the SRS<br>
          Date: Thu, 23 Aug 2001 14:56:57 -0400<br>
          From: &quot;VeriSign Global Registry Services&quot; &lt;[email-masked]&gt;<br>
          To: &lt;[email-masked]&gt;</font></P>
        <p></p>
        <P><font face="Arial, Helvetica, sans-serif">To all Registrars:</font></P>
        <p><font face="Arial, Helvetica, sans-serif"><b>Summary</b></font></p>
        <p><font face="Arial, Helvetica, sans-serif">On Friday August 10, 2001, 
          VeriSign Global Registry Services (VeriSign GRS) temporarily suspended 
          the batch releases of deleted .com, .net, and .org domain names to ensure 
          continued service quality within the Shared Registration System (SRS). 
          As described in the announcement of the suspension, VeriSign GRS has 
          been working with ICANN and the registrar community to devise an appropriate 
          plan to handle expiring names in a manner that is fair and does not 
          interfere with other activities in the SRS.</font></p>
        <p><font face="Arial, Helvetica, sans-serif">VeriSign GRS believes that 
          a long-term solution will require fundamental changes in the way expiring 
          names are handled. Nonetheless, in view of concerns that an ultimate 
          solution might be made more difficult by an accumulation of expiring 
          names during the suspension, VeriSign GRS has been evaluating short-term 
          measures for addressing the issues that caused the suspension. The purpose 
          of this email is to communicate the details of these short-term measures 
          and the schedule for their implementation.</font></p>
        <p><font face="Arial, Helvetica, sans-serif">VeriSign GRS will continue 
          to work with the Registrar Constituency, the DNSO, and the Names Council 
          to develop better policies and processes for registrations being returned 
          to the available pool. To the extent that the short-term measures described 
          below provide relevant experience, VeriSign GRS will endeavor to share 
          that information in a manner consistent with the confidentiality it 
          accords to its customers' business information.</font></p>
        <p><font face="Arial, Helvetica, sans-serif"><b>Goals</b></font></p>
        <p><font face="Arial, Helvetica, sans-serif">The goals of this new session 
          management process are:</font></p>
        <ul>
          <li><font face="Arial, Helvetica, sans-serif">To re-enable the registry 
            batch release process.</font></li>
          <li><font face="Arial, Helvetica, sans-serif">To ensure each registrar 
            is able to obtain RRP sessions reasonably necessary to support its 
            business practices.</font></li>
          <li><font face="Arial, Helvetica, sans-serif">To support the business 
            practices of each registrar in such a way that the business practices 
            of one would not impact the business practices of another.</font></li>
          <li><font face="Arial, Helvetica, sans-serif">Improve performance and 
            lower system latency during peak processing periods.</font></li>
        </ul>
        <p><font face="Arial, Helvetica, sans-serif"><b>Implementation Details</b></font></p>
        <p><font face="Arial, Helvetica, sans-serif">To facilitate the above goals, 
          additional capacity has been added to the SRS and three (3) session 
          pools have been created.</font></p>
        <blockquote> 
          <p><font face="Arial, Helvetica, sans-serif">1. Guarantee Pool<br>
            2. Overflow Pool<br>
            3. Automated Batch Pool</font></p>
        </blockquote>
        <p><font face="Arial, Helvetica, sans-serif">Each of these pools is described 
          in detail below. In summary, we expect the implementation of these three 
          session pools to provide the following advantages:</font></p>
        <ul>
          <li><font face="Arial, Helvetica, sans-serif">A larger and more reasonable 
            number of guaranteed sessions that will better support small to medium 
            registrars that have a traditional business model and that have been 
            experiencing difficulties obtaining sessions.</font></li>
          <li><font face="Arial, Helvetica, sans-serif">Support for registrars 
            whose business model involves more extensive use of automated batch 
            processing, without adversely impacting other registrars.</font></li>
          <li><font face="Arial, Helvetica, sans-serif">Eliminate the need for 
            &quot;session squatting&#148; (acquiring and holding sessions that 
            are not needed or used).</font></li>
        </ul>
        <p><font face="Arial, Helvetica, sans-serif"><b>Guarantee Pool</b></font></p>
        <p><font face="Arial, Helvetica, sans-serif">The Guarantee Pool is a session 
          pool in which each registrar is guaranteed 15 sessions. Registrars should 
          continue using the current hostname access (rrp.verisign-grs.com) in 
          order to obtain their guaranteed sessions. There is no change required 
          for registrars to access this pool. Registrars should be aware that 
          due to the load-balancing technology currently employed, it may take 
          multiple connection attempts to obtain these guaranteed sessions. Our 
          data show that over 75% of registrars use 15 or less sessions. Intensive 
          automated batch processing will not be permitted in this pool.</font></p>
        <p><font face="Arial, Helvetica, sans-serif"><b>Overflow Pool</b></font></p>
        <p><font face="Arial, Helvetica, sans-serif">The Overflow Pool is a first-come-first-served 
          pool of additional sessions. As with the Guarantee Pool, the Overflow 
          Pool is accessed via the rrp.verisign-grs.com hostname. VeriSign GRS 
          has added sufficient capacity to this pool to accommodate historical 
          registrar session activity, with the movement of intensive batch processing 
          to the Automated Batch Pool described below. Intensive automated batch 
          processing will not be permitted in this pool. We believe the increased 
          capacity coupled with the movement of batch processing to another pool 
          will enable registrars to obtain the sessions they need when they need 
          them, thus eliminating the need for session &#147;hoarding&#148; or 
          &#147;squatting&#148;.</font></p>
        <p><font face="Arial, Helvetica, sans-serif"><b>Automated Batch Pool</b></font></p>
        <p><font face="Arial, Helvetica, sans-serif">This pool of sessions has 
          been established specifically to support registrars whose business practices 
          include the execution of intensive automated batch processing. This 
          pool is completely separate from the Guarantee Pool and Overflow Pool, 
          and is accessed only via a separate hostname (rrp-auto.verisign-grs.com). 
          Intensive automated batch processes (such as the daily automated CHECK 
          activity) must be performed in this pool only. Registrars that desire 
          to perform this type of activity in this pool should request access 
          from VeriSign GRS. VeriSign GRS will grant access only to those registrars 
          that request it, and will permit up to 50 sessions to each requesting 
          registrar. This pool is specifically allocated to intensive automated 
          batch processing. The purpose of this pool is to provide an area where 
          intensive automated batch activities can be performed without impacting 
          other activities.</font></p>
        <p><font face="Arial, Helvetica, sans-serif"><b>Monitoring</b></font></p>
        <p><font face="Arial, Helvetica, sans-serif">VeriSign GRS closely monitors 
          registrar session activity and will work with registrars to assist them 
          in using the session pool(s) that will best support their business activities. 
          Registrars that perform intensive automated batch processing will be 
          required to modify their systems (i.e., use a different RRP hostname 
          address) so that these activities are performed only in the Automated 
          Batch Pool. VeriSign GRS believes that these measures will permit all 
          registrars to obtain as many sessions as needed to perform business. 
          Thus, there should no longer be a need for registrars to &quot;hoard&quot; 
          or &quot;squat&quot; on sessions unnecessarily. VeriSign GRS is ready 
          to implement technology that will automatically close unused sessions; 
          however, we will only implement this technology if session &quot;hoarding&quot;or 
          &quot;squatting&quot; continues to be a problem.</font></p>
        <p><font face="Arial, Helvetica, sans-serif">VeriSign GRS will utilize 
          several monitoring mechanisms to detect inappropriate session utilization. 
          We will inspect for inappropriate utilization if events such as the 
          following occur:</font></p>
        <ul>
          <li><font face="Arial, Helvetica, sans-serif">A sudden change in a registrar&#146;s 
            transaction or session profile</font></li>
          <li><font face="Arial, Helvetica, sans-serif">Activity causing impact 
            to system performance</font></li>
          <li><font face="Arial, Helvetica, sans-serif">Complaints about system 
            response or inability to obtain sessions</font></li>
        </ul>
        <p><font face="Arial, Helvetica, sans-serif">Following the occurrence 
          of these types of events, VeriSign GRS will evaluate session activity, 
          looking for the following specific behaviors:</font></p>
        <ul>
          <li><font face="Arial, Helvetica, sans-serif">Loops of repeated transactions 
            (e.g., multiple attempts of the same CHECK or ADD command for the 
            same domain name)</font></li>
          <li><font face="Arial, Helvetica, sans-serif">A high ratio of &quot;unsuccessful&quot; 
            to &quot;successful&quot; SRS responses</font></li>
        </ul>
        <p><font face="Arial, Helvetica, sans-serif">If these characteristics 
          exist, this behavior will be determined to be inappropriate for the 
          Guarantee and Overflow Pools and the registrar will be notified and 
          directed to move this activity to the Automated Batch Pool. If you have 
          any additional questions about what constitutes &#147;intensive automated 
          batch processing&#148;, please contact VeriSign GRS Customer Service.</font></p>
        <p><font face="Arial, Helvetica, sans-serif"><b>Enforcement</b></font></p>
        <p><font face="Arial, Helvetica, sans-serif">The following enforcement 
          procedures will be employed.</font></p>
        <ul>
          <li><font face="Arial, Helvetica, sans-serif">A 1st offense will result 
            in the registrar having its bandwidth and sessions immediately limited 
            in the Guarantee and Overflow Pools so that the behavior does not 
            impact the system or other registrars. The registrar will receive 
            an email and telephone notification. When the registrar has notified 
            VeriSign GRS of the resolution of the issue (e.g., the activity has 
            been moved to the Automated Batch Pool), these bandwidth and session 
            limitations will be removed.</font></li>
          <li><font face="Arial, Helvetica, sans-serif">A 2nd offense will result 
            in the same action as the 1st, with the added action that the registrar 
            will be notified that subsequent offenses will result in it being 
            blocked entirely from the Guarantee and Overflow Pools. </font></li>
          <li><font face="Arial, Helvetica, sans-serif">A 3rd offense will result 
            in the registrar being blocked from the Guarantee and Overflow Pools 
            for 7 days, requiring that all transactions be performed in the Automated 
            Batch Pool.</font></li>
          <li><font face="Arial, Helvetica, sans-serif">Subsequent offenses will 
            result in the registrar being blocked from the Guarantee and Overflow 
            Pools for 30 days, requiring that all transactions be performed in 
            the Automated Batch Pool.</font></li>
        </ul>
        <p><font face="Arial, Helvetica, sans-serif">Enforcement of these procedures 
          will begin with the resumption of batch releases described below.</font></p>
        <p><font face="Arial, Helvetica, sans-serif"><b>Implementation Schedule</b></font></p>
        <p><font face="Arial, Helvetica, sans-serif">These three pools are available 
          now. Registrars that do not engage in intensive automated batch processing 
          may continue to access the SRS through rrp.verisign-grs.com as they 
          do now. No system changes are necessary. No intensive automated batch 
          processing is to be performed in the Guarantee Pool or Overflow Pool. 
          Registrars that do engage in intensive batch processing are required 
          to request access to, and move that activity to, the Automated Batch 
          Pool. This will require a minor modification to use the rrp-auto.verisign-grs.com 
          access host.</font></p>
        <p><font face="Arial, Helvetica, sans-serif"><b>Resumption of Batch Releases</b></font></p>
        <p><font face="Arial, Helvetica, sans-serif">VeriSign GRS believes that 
          the prompt resumption of registry batch releases is in the best interests 
          of the registrars and the Internet community. Therefore, the batch release 
          process will be resumed at 18:00 UTC (1400 hrs EDT) on Thursday, August 
          30, 2001. Registrars that anticipate resuming associated intensive automated 
          batch processing must modify their systems to access the Automated Batch 
          Pool via rrp-auto.verisign-grs.com by that time. Registrars that perform 
          this type of activity in the Guarantee or Overflow Pools will be subject 
          to the enforcement procedures noted above. Registrars will not be permitted 
          more than 200 total sessions across all pools. This upper limit is not 
          a guarantee. The plan described here only guarantees 15 sessions. However, 
          if registrars use the Automated Batch Pool for intensive batch processing, 
          and use no more sessions than necessary to perform business (e.g., no 
          session &quot;hoarding&quot;), there should be no shortage of sessions.</font></p>
        <p><font face="Arial, Helvetica, sans-serif">Subsequently, all batch releases 
          will be performed daily at 18:00 UTC (1400 hrs EDT). Note this time 
          change. Batch releases are always completed within 15 minutes. Therefore, 
          registrars that utilize intensive batch processing associated with the 
          registry daily batch release have no need to start that processing prior 
          to 17:45 UTC (1345 hrs EDT), or to continue it past 18:30 UTC (1430 
          hrs EDT).</font></p>
        <p><font face="Arial, Helvetica, sans-serif"><b>Assistance</b></font></p>
        <p><font face="Arial, Helvetica, sans-serif">The VeriSign GRS Customer 
          Service and Technical Operations staffs are standing by to assist registrars 
          as needed. We will closely monitor the utilization and activity in each 
          pool. If, at any time, a registrar is unable to obtain a session in 
          the Guarantee or Overflow Pools after repeated attempts, please notify 
          VeriSign GRS Customer Service immediately. Registrars should be aware 
          that the ability to obtain sessions can also be impacted by registrar 
          session management practices and Internet Service Provider issues. Sessions 
          that are broken or otherwise terminated uncleanly may require up to 
          15 minutes to time-out and reset, and depending on the current number 
          of sessions, may inhibit the creation of new sessions until the broken 
          sessions have timed-out.</font></p>
        <p><font face="Arial, Helvetica, sans-serif">We strongly believe that 
          this process will ensure all registrars can acquire the sessions they 
          need when they need them.</font></p>
        <p><font face="Arial, Helvetica, sans-serif">VeriSign GRS is committed 
          to ensuring continued SRS service quality, with equitable access to 
          every registrar. As appropriate, this plan may be adjusted in the future 
          to meet that commitment.</font></p>
        <p><font face="Arial, Helvetica, sans-serif">Best Regards,</font></p>
        <p><font face="Arial, Helvetica, sans-serif">Chris Sheridan<br>
          Manager, Customer Service<br>
          VeriSign Global Registry Services<br>
          www.verisign-grs.com<br>
          [email-masked]</font></p>
        <p></p>
        <P> 
        <CENTER>
          <FONT FACE="Arial"> 
          <HR NOSHADE WIDTH="100%">
          </FONT> 
        </CENTER>
      </TD>
    </TR>
  </TABLE>
</CENTER>

</BODY>
</HTML>

- --Boundary_(ID_Wo05KUl5BNeuXmIqTIYAYA)--
- --
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 #698
************************