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

GA-DIGEST        Thursday, September 12 2002        Volume 01 : Number 1416

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

Date: Thu, 12 Sep 2002 03:19:39 -0700
From: Jeff Williams <[email-masked]>
Subject: Re: [ga] Consensus Policy Process

Jeff and all assembly members,

  This sounds great.  However your comments and statements below
miss the mark a bit.  That being that any such recommendations, must
be developed with the participation of andy and all of the participating
stakeholders/users.  Presently that is not being done or allowed to be
done.  As such, any such recommendations stand a greater chance
of further degrading the creditability of ICANN and are in consistent
with the White Paper and MoU...

Neuman, Jeff wrote:

> Danny,
>
> Thanks for pointing this out.  Just to let you know, we are on top of the
> requirements for this to be a "consensus policy."  Before we can document
> what is required, we need to finish and finalize the substance of the actual
> recommendations.  Only then can we document the total outreach, the extent
> of disagreement amongst impacted groups, etc. as you have mentioned.
>
> With respect to the timeline, I will leave that answer to our Chairman, but
> I encourage you to voice your onions on the call today.
>
> Thanks.
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, September 11, 2002 1:18 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: [ga] Consensus Policy Process
>
> Marilyn,
>
> In order to achieve a "consensus policy", one of the obligations is to
> provide a written report and supporting materials (which must include all
> substantive submissions to the Supporting Organization relating to the
> proposal) that (i) documents the extent of agreement and disagreement among
> impacted groups, (ii) documents the outreach process used to seek to achieve
>
> adequate representation of the views of groups that are likely to be
> impacted, and (iii) documents the nature and intensity of reasoned support
> and opposition to the proposed specification or policy.
>
> In view of the fact that Network Solutions, Namesecure.com, BB Online UK
> Ltd.
> and Registrars.com voted against the previous iteration of the draft last
> October, it would be reasonable to assume that they might still consider
> themselves to be "impacted groups".  My questions:
>
> 1.  Has the Task Force documented the extent of disagreement, if any,
> expressed by these parties?  If not, when do you intend to get this
> accomplished?
> 2.  What outreach process will the Task Force be using to achieve adequate
> representation of the views of these groups?  Have any of these parties
> participated in the drafting of the current set of proposals?  If not, why
> were they excluded?
> 3.  What outreach process will the Task Force be using to achieve adequate
> representation of the views of registrants?  I would think that two-day
> advance notice of an open teleconference only posted by the DNSO
> Secretariat,
> and not on the ICANN site itself, hardly constitutes an outreach that
> achieves "adequate representation".  What do you consider to be an
> "adequate"
> amount of representation?
> 4.  How does the TF intend to document the nature and intensity of the
> opposition of these registrars, if any, to the proposed policy?  Has the TF
> formally asked any of these folks for their opinions as yet?  If not, when
> do
> you plan to do so?  How much time will be allotted for these parties to
> provide a response?
> 5.  Your terms of reference require you to develop broad understanding
> across
> the NC of the issues underlying the
> disputed area of transfers of domain names between registrars -- where are
> each of those issues listed, identified and analyzed?
> 6.  Your terms of reference also require the TF to identify any broad policy
>
> issues (separate from contract issues), which
> are the responsibility of the DNSO -- where are those broad policy issues
> articulated within the current documents?
> 7.  Will you ever honor the bylaws and post a timeline for this TF?
>
> --
> 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

Regards,
- --
Jeffrey A. Williams
Spokesman for INEGroup - (Over 127k members/stakeholders strong!)
CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng.
Information Network Eng. Group. INEG. INC.
E-Mail [email-masked]
Contact Number: 214-244-4827 or 972-244-3801
Address: 5 East Kirkwood Blvd. Grapevine Texas 75208

- --
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: Thu, 12 Sep 2002 12:27:56 +0200
From: Thomas Roessler <[email-masked]>
Subject: Re: [ga] joesworld.com saga continues

On 2002-09-10 02:58:57 -0700, Abraham Ingersoll wrote:

>Well, well, well .. YesNIC has responded.

It also seems like they have fixed their WHOIS.

% whois -h whois.yesnic.com joesworld.com
- -----------------------------------------------
Queried Domain Information as follows
- -----------------------------------------------

Domain Name : joesworld.com

::Registrant::
	Name      : Jeongwhan Yoon
	Email     : [email-masked]
	Address   : Oksu 2-dong, Songdong-gu, Seoul

*snip*

- -- 
Thomas Roessler                        http://log.does-not-exist.org/
- --
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: Thu, 12 Sep 2002 07:25:39 -0700 (PDT)
From: George Kirikos <[email-masked]>
Subject: [ga] Dotster appeals ICANN's WLS non-consensus decision 

Hello,

In case folks missed it, Dotster's initial appeal of the WLS decision
is at:

http://www.icann.org/correspondence/brannon-letter-to-lynn-09sep02.htm

It's in the form I had predicted earlier, at:

http://www.dnso.org/clubpublic/nc-transfer/Arc00/msg00303.html

Should be interesting to see how ICANN will attempt to wiggle out of
this one.

Sincerely,

George Kirikos
http://www.kirikos.com/

__________________________________________________
Do you Yahoo!?
Yahoo! News - Today's headlines
http://news.yahoo.com
- --
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: Thu, 12 Sep 2002 10:37:11 -0400
From: Joe Baptista <[email-masked]>
Subject: [ga] Overcoming IPv6 Security Threat

- --=======1737BCA=======
Content-Type: text/plain; x-avg-checked=avg-ok-56D95B12; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 8bit

Thanks to everyone who helped out.

cheers
joe baptista

>http://www.circleid.com/articles/2533.asp
>
>Overcoming IPv6 Security Threat
>
>September 12, 2002  |  By Joe Baptista
>
>Technology rags and industry pundits see IPv6 (Internet Protocol version
>6) as the future of networking, but Daniel Golding a participant of the
>North American Network Operators' Group (NANOG) thinks it's a "solution in
>search of a problem". Many others have argued IPv6 is a problem in itself
>and it is unlikely the protocol will gain wide acceptance in the short
>term.
>
>IPv6 does solve many of the problems with the current version of IPv4
>(Internet Protocol version 4). Its purpose is to expand address space and
>fix the IPv4 address depletion problem, which many techies claim, was due
>to mismanagement. The industry's goal is to use the very large address
>allocation pool in IPv6 to expand the capabilities of the Internet to
>enable a variety of peer-to-peer and mobile applications including
>cellular phone technology and home networking.
>
>IPv6, a suite of protocols for the network layer, uses IPv4 gateways to
>interconnect IPv6 nodes and comes prepackaged with some popular operating
>systems. This includes almost all Unix flavors, some Windows versions and
>Mac OS. Some vendors offer upgrades to older operating systems. Trumpet
>Software International in Tasmania Australia manufactures a Trumpet
>Winsock version that upgrades old Windows 95/98 and NT systems to the
>current IPv6 standard.
>
>IPv6 has suffered bad press over privacy issues. Jim Fleming, the inventor
>of IPv8, a competing protocol, sees many hazards and privacy flaws in
>existing IPv6 implementations. IPv6 address space in some cases uses an ID
>(identifier) derived from your hardware or phone "that allows your packets
>to be traced back to your PC or cell-phone" said Fleming. Potential abuse
>to user privacy exists as a hardware ID wired into the IPv6 protocol can
>be used to determine the manufacturer, make and model number, and value of
>the hardware equipment being used. Fleming warns users to think twice
>before they buy themselves a used Laptop computer and inherit all the
>prior surfing history of the previous user!
>
>IPv6 uses 128 bits to provide addressing, routing, and identification
>information on a computer interface or network card. The 128 bits are
>divided into the left 64 and the right 64. Some IPv6 systems use the right
>64 bits to store an IEEE defined global identifier (EUI64). This
>identifier is composed of company id value assigned to a manufacturer by
>the IEEE Registration Authority. The 64-bit identifier is a concatenation
>of the 24-bit company identification value and a 40-bit extension
>identifier assigned by the organization with that company identification
>assignment. The 48-bit MAC address of your network interface card may also
>be used to make up the EUI64.
>
>In the early stages of IPv6 development, Bill Frezza a General Partner
>with the venture capital firm, Adams Capital Management warned software
>developers that if privacy issues are not properly addressed, the
>migration to IPv6 "will blow up in their face"! Leah Gallegos agrees that
>while "expanding the address space is necessary the use of the address for
>ID and tracking is horrific". Gallegos the operator of the top-level
>domain .BIZ and a Director of the Top Level Domain Association cautions
>network administrators that they should refuse to implement IPv6 unless
>these issues are properly addressed.
>
>Privacy concerns prompted the creation of new standards, which provide
>privacy extensions to IPv6 devices. Thomas Narten and Track Draves of
>Microsoft Research published a procedure to ensure privacy of IPv6 users.
>Narten, IBM's technical lead on IPv6 and an Area Director for the Internet
>Engineering Task Force (IETF), agrees "IPv6 address can, in some cases,
>include an identifier derived from a hardware address". But Narten points
>out that a hardware address is not required. "In cases where using a
>permanent identifier is a problem", said Narten "RFC 3041 addresses should
>be used".
>
>RFC 3041 titled "Privacy Extensions for Stateless Address
>Autoconfiguration in IPv6" was published this past January 2001 by the
>IETF. It is an algorithm developed jointly by Narten and Draves which
>generates randomized interface identifiers and temporary addressees during
>a user session. This would eliminate the concerns privacy advocates have
>with IPv6.
>
>Unfortunately RFC 3041 is not widely implemented. But Narten expects major
>vendors to incorporate his privacy standard and offered that Microsoft
>implemented privacy extensions "and apparently intends to make it part of
>their standard stuff". Narten also assisted in the drafting of
>recommendations for some second and third generation cellular phones
>recently approved for publication by the Internet Engineering Steering
>Group. That document recommends that RFC 3041 be implemented as part of
>cellular phone technology but he did not know what direction cell phones
>manufacturers were taking. "I suspect that client vendors will generally
>implement it because of the potential bad PR if they don't" said Narten.
>
>Another obstacle raised by NANOG operators is that there is currently no
>commercial demand for IPv6 at this time. Dave Israel, a Data Network
>Engineer and regular participant on NANOG lists, sees no immediate demand
>for IPv6 services. "The only people who ask me about IPv6", said Israel
>"are people who have heard something about it from some tech-magazine and
>want the newest thing". Israel says he sees no commercial demand for a v6
>backbone.
>
>Daniel Golding, another NANOG participant agrees, "v6 deployment is being
>encouraged by some countries, and the spread of 3G (cellular technology)
>is helping things along, but we have yet to see really widespread v6
>deployments anywhere". Golding sees major backbone networks deploying IPv6
>when it makes economic sense for them to do so. "Right now", said Golding
>"there is no demand and no revenue upside. I don't expect this to change
>in the near future".
>
>Most on NANOG agree the roadblock seems to be a lack of ISPs that offer
>IPv6 services. Stephen Sprunk, a Network Design Consultant with Cisco's
>Advanced Services group sees the "greater adoption of always-on broadband
>access will be the necessary push" to get IPv6 off the ground. "Enterprise
>networks will not be the driver for ISPs to go to IPv6" said Sprunk and
>"NAT is too entrenched". Network Address Translation (NAT) is a method of
>connecting multiple computers to the Internet (or any other IP network)
>using one IPv4 address.
>
>Vint Cerf senior vice president of architecture & technology at WorldCom
>has been using IPv6 for about four years. IPv6 has been a key element for
>some of WorldCom's Government customers. Cerf thinks IPv6 supporters have
>a lot of work ahead to achieve successful deployment of the protocol. He
>expects "that over the next several years we will see a lot of consumer
>devices set up to work with IPv6" and "cell phones are likely candidates,
>as are radio-enabled PDAs".
>
>-EOF

The dot.GOD Registry, Limited
http://www.dot-god.com/

- --=======1737BCA=======--

- --
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: Thu, 12 Sep 2002 17:28:03 +0200
From: "DNSO Secretariat" <[email-masked]>
Subject: [ga] MP3 recording NC teleconf Sept 12, 2002

[To: [email-masked]; [email-masked]]
[To: [email-masked]; [email-masked]]

The MP3 recording of the Names Council teleconference September 12, 2002 is
available at
http://www.dnso.org/dnso/mp3/20020912.NCteleconf.mp3

Happy listening!
DNSO Secretariat

- --
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: Thu, 12 Sep 2002 18:23:23 +0200
From: "DNSO Secretariat" <[email-masked]>
Subject: [ga] NC teleconf. minutes August 1, 2002

[To: [email-masked]; [email-masked]]
[To: [email-masked]]

DNSO Names Council Teleconference on 1 August 2002 - minutes
- ------------------------------------------------------------------------
1 August 2002.
Proposed agenda and related documents
http://www.dnso.org/dnso/notes/20020617.NCteleconf-agenda.html

List of attendees:

Elisabeth Porteneuve   ccTLD
Oscar Robles Garay     ccTLD absent, no apologies
Philip Sheppard        Business
Marilyn Cade           Business
Grant Forsyth          Business
Greg Ruth              ISPCP
Antonio Harris         ISPCP
Tony Holmes            ISPCP
Philipp Grabensee      Registrars absent, no apologies
Ken Stubbs             Registrars
Bruce Tonkin           Registrars
Roger Cochetti         gTLD
Jordyn Buchanan        gTLD
Cary Karp              gTLD
Ellen Shankman         IP absent, apologies, proxy to J. Scott Evans
Laurence Djolakian     IP absent, apologies, proxy to J. Scott Evans
J. Scott Evans         IP absent, no apologies,
Harold Feld            NCDNH
Chun Eung Hwi          NCDNH absent, no apologies
Erick Iriate           NCDNH

14  Names Council Members

Alexander Svensson     GA Alternate Chair

Glen de Saint Géry     NC Secretary
Philippe Renaut          MP3 Recording Engineer/Secretariat

MP3 recording of the meeting by the Secretariat:
http://www.dnso.org/dnso/mp3/20020801.NCteleconf.mp3

Quorum present at 15:10 (all times reported are CET which is UTC + 2 during
summer time in the northern hemisphere).

Philip Sheppard chaired this NC teleconference.

Item 1. Approval of the Agenda
http://www.dnso.org/dnso/notes/20020801.NCteleconf-agenda.html

Philip Sheppard added:
- - an order change to the agenda taking Item 4 early.
- - the next Names Council teleconference date
- - DNSO Board member election
- - confirmation of J. Scott Evans as UDRP Task Force Chair

The agenda was approved.

Item 2. Summary of last meeting:
http://www.dnso.org/dnso/notes/20020724.NCteleconf-minutes.html

Ken Stubbs moved the adoption of the summary, seconded by Grant Forsyth.
The motion was carried.
Decision 1: Summary adopted.

Item 4. ICANN Reform - discussion and vote on revised NC resolution on the
composition of the new GNSO Council
http://www.dnso.org/temp/20020726.NCresolution-Reformv3.htm

Philip Sheppard introduced a revised NC resolution on Reform saying that
after the Board's conditional adoption of the Blueprint (subject to
geographic diversity and a bottom up process), and following input received
from Council members, he proposed Council focus on one issue, namely, the
number of constituency representatives on the proposed GNSO council.

Marilyn Cade proposed a friendly amendment to make it clear the NC may have
future resolutions. This was agreed.  Support for the motion was expressed
by Marilyn Cade, Ken Stubbs, Tony Harris, Tony Holmes and Elisabeth
Porteneuve, all of whom felt that 3 representatives would both better manage
the workload and assure better geographic diversity.

Friendly amendments were made by Bruce Tonkin, Marilyn Cade, Ken Stubbs and
Tony Harris which emphasised in particular the workload of Council and the
importance of three representatives to share that workload.

Philip Sheppard proposed voting on the full resolution as amended. This was
seconded by Bruce Tonkin.

Whereas the Names Council has produced a set of recommendations for ICANN
evolution and reform;

Whereas, the ICANN Board at its Bucharest meeting in June 2002 resolved that
the Board endorses the Evolution and Reform Committee (ERC) Blueprint for
Reform, and described it as being broad outlines;

Whereas the Board instructed the ERC to oversee implementation with the
participation of the ICANN community;

Whereas the Board resolved that further opportunities for strengthening
ICANN's capacity to fulfill its mission should be utilized;

Whereas the Board instructed the ERC to take due account of certain
fundamental issues:
- - geographic and cultural diversity in all parts of ICANN structure,
- - a policy development processes that enhances and promotes a transparent
bottom-up process.

GNSO council.
The Blueprint's proposed two representatives per Constituency fails the
Board's test of geographic and cultural diversity within the constituency.
With three representatives per constituency, the majority of ICANN regions
ARE represented. With two, the majority of ICANN regions are NOT adequately
represented.

The Blueprint's proposed two representatives per Constituency fails the
Board's test of a bottom-up process. Experience has shown that three
representatives improves the constituencies ability to share the workload of
a council member, to be able to participate in task forces of the council,
and to outreach to multiple regions, thus enhancing and promoting a
transparent bottom-up process.

Without prejudice to future NC commentary in this area, the Names Council
resolves therefore to recommend the following implementation of the
Blueprint, without which ICANN will fail to take account of the above
fundamental issues:

there should be three representatives per Constituency on the GNSO council.

11 voted in favour, 1 abstention (gTLD), no vote was recorded for Roger
Cochetti or Philipp Grabensee.
The motion was carried.
Decision 2: motion adopted.

Commentary on preliminary report of Evolution Reform Committee policy
development task force
http://www.dnso.org/temp/20020726.NCresolution-Reformv3.htm

Marilyn Cade commented that much had been learnt about policy development
over the last few years but this learning was not being reflected in the
output of the ERC TF on policy development.

Bruce Tonkin, a member of the Names Policy Development Process Assistance
Group (NPDPAG), said that there had been a marked shift in procedure from
the first call of the ERC TF which sought wide participation to the second
which appeared to be driven from the top. Harold Feld emphasised the
maturing process of the Names Council and that restructuring should look at
the good work in particular of the last 6 months, to which Bruce Tonkin
added that this maturing process also benefited from new documented
procedures that the Names Council now had.

(Discussion continued after a break to handle the admin items below).
Philip Sheppard said that any general or particular input to the Evolution
Reform committee policy development group could be transmitted to the
committee by Bruce Tonkin or himself.
Tony Harris quoting section 6 from the present ICANN bylaws on the structure
of the board of directors that requires international representation. "One
citizen of a country situated in each geographical region can serve as an
At-Large director on the Board" asked whether the same bylaws would be
applied or what policy would be implemented to replace it with regard to the
eight directors elected from the nominating committee.
Alexander Svensson, GA alternate chair, asked the members of the task force
to consider the role of the GA as it would be disadvantageous to tag on a
role at the end or allow the GA to become a mere mailing list.  He drew
attention to a document, "Reforming the GA", authored by Thomas Roessler and
himself.
http://www.dnso.org/clubpublic/council/Arc10/pdf00002.pdf
Philip Sheppard said that the definition in the blueprint of the GA is
narrow but that the current outreach role of the GA beyond constituencies
was a part of the work of the task force on public outreach chaired by Becky
Burr.

Ken Stubbs proposed Council set a provisional date for a meeting in August.
The Chair proposed August 29, 2002.
Decision 3: motion adopted

Item 3: Administrative items.

a) Approval timetable NC chair elections
http://www.dnso.org/temp/200208.NCchair-elections.htm
Decision 4: timetable approved.

b) Election by the task force of J.Scott Evans as chairman of the UDRP Task
Force.
Decision 5: elected UDRP chair confirmed.

c) Board Elections.
The time has come to elect a DNSO representative on the Board, at present
filled by Alejandro Pisanty.
ICANN has given no response to a request for clarification on this point in
view of the current Reform process.

Ken Stubbs commented that the Names Council is still operating and has
administrative responsibilities as an on-going concern which should not be
stopped. Elisabeth Porteneuve said that another supporting organisations had
proceeded with an election to replace a board member.

Philip Sheppard suggested addressing the issue as a request from the Names
Council to the ICANN staff
saying that if nothing to the contrary was heard, the elections would
proceed.
Decision 6: Ph. Sheppard will e-mail ICANN staff with that intent.

Philip Sheppard closed the meeting saying that there would definitely be a
Names Council teleconference on September 12, 2002, and if necessary on
August 29, 2002.

The teleconference ended at 16:00

Next NC teleconference will be on 12 September at 15:00 Paris time, 13:00
UTC/GMT or if deemed necessary 29 August at 15:00 Paris time, 13:00 UTC/GMT.

     See all past agendas and minutes at
     http://www.dnso.org/dnso/2002calendardnso.html
     and calendar of the NC meetings at
     http://www.dnso.org/dnso/notes/002.NC-calendar.html

  ------------------------------------------------------------------------
Information from:  © DNSO Names Council

- --
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: Thu, 12 Sep 2002 18:30:11 +0200
From: "DNSO Secretariat" <[email-masked]>
Subject: [ga] NC teleconf minutes, August 29, 2002

[To: [email-masked]; [email-masked]]
[To: [email-masked]]

ICANN/DNSO
DNSO Names Council Teleconference on 29 August 2002 - minutes
 ------------------------------------------------------------------------
29 August 2002.

Proposed agenda and related documents
http://www.dnso.org/dnso/notes/20020829.NCteleconf-agenda.html

List of attendees:

Elisabeth Porteneuve   ccTLD
Oscar Robles Garay     ccTLD absent,
Philip Sheppard        Business
Marilyn Cade           Business
Grant Forsyth          Business absent, apologies, proxy to Marilyn Cade
Greg Ruth              ISPCP
Antonio Harris         ISPCP
Tony Holmes            ISPCP
Philipp Grabensee      Registrars
Ken Stubbs             Registrars
Bruce Tonkin           Registrars
Roger Cochetti         gTLD  absent, apologies, proxy to Cary Karp/ Jordyn
Buchanan
Jordyn Buchanan        gTLD
Cary Karp              gTLD
Ellen Shankman         IP
Laurence Djolakian     IP
J. Scott Evans         IP
Harold Feld            NCDNH
Chun Eung Hwi          NCDNH absent, apologies, proxy to Harold Feld, Philip
Sheppard
Erick Iriate           NCDNH absent

16 Names Council Members

Glen de Saint Géry     NC Secretary
Philippe Renaut          MP3 Recording Engineer/Secretariat

MP3 recording of the meeting by the Secretariat:
http://www.dnso.org/dnso/mp3/20020829.NCteleconf.mp3

Approval of agenda:

http://www.dnso.org/dnso/notes/20020829.NCteleconf-agenda.html

The agenda was approved and an additional item was proposed by Marilyn Cade:
Deletes and the existing Transfer Task Force.

AOB: Deletes and transfer Task Force

Marilyn Cade reported that the Task Force had a series of meetings planned
where guests made presentations to the Task Force members, some calls were
open and all calls were recorded and minuted.
There is some discussion on whether then Task Force should conclude the work
on deletions.
Some believe that as there is expertise in the Task Force and much of the
achievable workable transfer policy will depend on Standard deletions it
should be a second priority work item.
While others believe that deletions were acknowledged as an appropriate
referral to the Task Force by the Board, and that the Names Council
forwarded this work to the Transfer Task Force, yet others disagree that
this TF should do any work on deletions, and strongly advocate that the TF
advise the NC that they are unable to work on the issue. When considering
whether to create a new task force, the names council members should
consider whether their constituencies have the resources to contribute to
the task force.
Option I:
Complete Transfers/ complete Deletions on different tracks as described
below. Add in a technical working aspect to the current TF on deletions.
Option 2: Return the deletions issue to the Names Council and recommend that
the Names Council establish a different Task Force.

Ken Stubbs said that the meeting was not in a position to deal with the
delete issue as it has not been put up as a proper agenda item.
Bruce Tonkin referred to the new procedure proposed to create an issue
report to the Names Council and let the Council decide whether it will deal
with it, and if so whether to deal with the issue at the Names council level
or use a task force.

Philip Sheppard proposed that the Names Council Chairman and Marilyn Cade
make a short proposal around the issue to discuss during the September 12,
Names Council meeting.

Item I. 1. Confirming vote for NC chair for term of office starting 1
September 2002 for six months.
One nomination of Bruce Tonkin, nominated by Philip Sheppard, seconded by
Ken Stubbs.

An oral vote was recorded: 18 supported the nomination, 2 absent without
proxy

Decision 1: Bruce Tonkin is the Names Council Chair for 6 months office
starting 1 September

The names council unanimously passed a vote of thanks for Philip Sheppard.

Bruce Tonkin expressed his thanks to Philip Sheppard for his outstanding
work and thanked the council members for their confidence in him.

Ken Stubbs expressed his thanks for the superb job done by Philip at the
helm of the Names Council, and for all the time that he has devoted to the
work, and also thanked Glen de Saint Géry for her secretariat work during
Philip's term.
Elisabeth Porteneuve thanked Philip Sheppard for his extraordinary work.
Marilyn Cade shared the comments of the council members about Philip as
Chair.

Philip Sheppard thanked the council members for their kind words and said
that it had been rewarding and fun to work together and make the Names
Council a better place.

Ken Stubbs moved to adjourn the meeting at 15:30 Paris time 13:30 UTC

The teleconference ended at 15:30

Next NC teleconference will be on Thursday September 12 at 15:00 Paris time,
13:00 UTC/GMT

     See all past agendas and minutes at
     http://www.dnso.org/dnso/2002calendardnso.html
     and calendar of the NC meetings at
     http://www.dnso.org/dnso/notes/2002.NC-calendar.html

  ------------------------------------------------------------------------
                 Information from:  © DNSO Names Council

- --
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: Thu, 12 Sep 2002 21:10:56 +0100
From: "Karen Elizaga" <[email-masked]>
Subject: FW: FW: [ga] FYI: .org applicant comments (long)

Dear Ross,

Thank you again for your follow up.  I think there has been a bit of a misunderstanding here, which I hope this email clarifies.  We stated that we developed only the C++ version of the EPP toolkit and extensions to the Java version in response to specific questions posed by ICANN that required us to support our technical capabilities.  We made this statement with good conscience because our developers, in fact, did develop those specific codes.  While we might have been able to state our accomplishments in a different way to recognize the efforts of others (which we do), in an effort to highlight our technical capabilities (the purpose of the response to ICANN), we thought it appropriate to indicate that, in fact, our developers have contributed significantly to new and important protocols.  In light of ICANN's examination of our technical capabilities, this was essential.  In another context, there is no ego - together with others, GNR's development team contributes to progress on Internet standards and demands neither "ownership" or "rights" to its work product, as evidenced by its various postings on SourceForge.

It must be understood, furthermore, that there is actually a very small group of technical developers who have been continually committed to the EPP standardization effort.  We did not intend to, and I do not think the comment we made, diminish the efforts of those others involved in this process.  We, like you, envision a new protocol that is universal, rather than proprietary to each separate registry.
 
> The epp-rtk project finds its roots in the broad agreement that it didn't
> and doesn't make a ton of sense to have 7 new registries running 7 new
> policy sets with 7 new protocols and 7 new interface toolkits. There are a
> number of people and corporations that set out to address this from a
> technical perspective. Verisign, GNR, Afilias, Tucows, Rick Wesson, Eric
> Brunner-Wiiliams, Marshall Rose, Bruce Minor and dozens more have left their
> mark on various aspects of this loosely defined effort.

In the effort to create an EPP client standard, there were disagreements amongst the participants of the project, which resulted in GNR and Liberty (now Afilias) continuing almost exclusively on the development of the APIs that had been discussed up to that point.  Consequently, GNR and Liberty agreed that they would publish their respective work on SourceForge in the hope that their efforts would actually be implemented as the EPP standard across registries.

What you perceive as a "loosely defined effort" in this regard is actually very clear from our point of view:

1.	Liberty contributed a Java toolkit. 
2.	GNR contributed a C++ toolkit and Java extensions to enhance its universal applicability. 
3.	Both parties continue to work with others, update the respective parts of the toolkit and coordinate changes so that new aspects of the solutions function as similarly as possible.
4.	We continue to support the idea that the standard should be made available universally but understand that we are not in a position to foist such a standard unto other organizations.

> My point is not to
> diminish GNR's contribution to the EPP R/RTK initiative, but simply to point
> out that "...concerns about "rights" and "ownership" ... are inappropriate.
> It is appropriate to be concerned about "responsibilities" and "service" to
> the community." (apologies to Postel). Or perhaps more succinctly, as Eric
> Raymond points out[1], "according to the standard open-source licenses, all
> parties are equals in the evolutionary game."
> 
> Given the time that Neulevel, Afilias, Verisign, GNR and others have devoted
> to the development of the protocol, the resources that Afilias continues to
> invest in the public EPP sandbox and the numerous developers (including GNR
> staffers) that make the Universal R/RTK actual living, breathing community
> code, I would simply request that GNR reconsider its public use of language
> like ""We alone have designed, developed and operated most of the SRS
> solutions internally, ranging from the EPP toolkit, protocol independent
> business logic and near-real time updates on DNS..."

Regarding your admonition/request in the last part of your second paragraph, we certainly appreciate all of the thought and contributions made by others on EPP both prior to and during GNR's involvement.  However, we also recognize the work of our developers with pride and think that the highlighting development of our internal SRS solutions, our business logic, updates and even their contributions to "community" projects is appropriate in the context in which they were made.  As for recognizing the work of others as equals in the evolution of EPP, you are right; we could have done so.  However, since two people wrote all of the code for the C++ version (GNR senior developers, Vidar Hokstad and Asbjorn Steira), and recognizing our need to respond to ICANN in as meaningful a way as possible, we perhaps may have made the following statement:

"We have independently designed, developed and operate most of our SRS solutions internally, ranging from the protocol independent business logic and near-real time updates on DNS; moreover, while we recognize the efforts of all of those involved in EPP development, our internal developers independently developed the code for the EPP C++ toolkit and extensions that allow the Java version to work for .info, .name, and even .biz and .us." 

Again, in an evaluation context, we believe that this is appropriate.  To pick a few words out of our submission of 10 pages and to impugn a negative motive seems inappropriate and actually, I think, does diminish GNR's contributions.  It also undermines the commitment of our developers who have never asked for that recognition and instead have offered up their talents (and continue to do so) without demanding "ownership," "rights," or anything else for that matter, in return.

I also would point out that "the numerous developers" you cite actually consist of seven people, of which three (Dan Manley, Lee Yin and Asbjorn Steira) continue to make significant contributions to the current codebase.  We also note that the SourceForge mailing list illustrates fantastic participation by individuals like Rick Wesson and Scott Hollenbeck, who have provided, and continue to provide, very significant and insightful input.  

> As with dotORG, the epp-rtk work also finds its roots in a community - some
> of the same sensitivities must be kept in mind.

We agree with you on the ideal of community, and our developers have worked hard with others who have shown willingness to participate in this effort.  Unfortunately, the original concept of "community" around the epp-rtk fell apart in the summer of 2001 due to the disagreement I cited above, but which I will not get into here.  Our team will continue to contribute to this effort.  While I agree that the EPP project should find its roots in community, we should nonetheless recognize the individuals like Rick Wesson, Scott Hollenbeck, Dan Manley and the GNR developers who actually have continued to make significant and meaningful contributions to this project and to the development of new standards.  

Regards.
KE

Information contained herein is Global Name Registry Proprietary Information and is made available to you because of your interest in our company.    This information is submitted in confidence and its disclosure to you is not intended to constitute public disclosure or authorization for disclosure to other parties.
*****************
What's your .name?
Get one at www.name
*****************

- --
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, 13 Sep 2002 07:36:59 +1200
From: "Peter Dengate Thrush" <[email-masked]>
Subject: [ga] The proposed ccNSO Assistance Group

Dear Alex,

The adcom has been approached by the North American and South American
representatives with the news that your committee has privately requested
that they agree to serve on an Assistance Group your committee is proposing
to form. A copy of  one of your invitation letters is pasted below.

You will understand how confusing and even distressing this is to us, as you
undertook in two conversations with us, when we proposed the formation of
such a group to you, that you would have further discussions with us on a
number of matters. One of those was the formation of such a group, in which
case we had suggested that the Adcom or its nominees would be the
appropriate cctld representatives. A second issue was the nature of the
mandate of any such group, and in particular its ability to "bridge" the
current gap between the ccSO designed after a bottom-up process by the
cctlds, and the ccNSO proposed in the Blueprint apparently without reference
to the cctld consensus.

The two representatives of the adcom you have approached have indicated to
us that they need Adcom approval if they are to accept your invitations to
serve.

We understand because of the time pressure placed on them in your request,
several may have already provided you with an answer, before our
deliberations on this have concluded.
If the matter is as urgent as your behaviour indicates, we wonder why there
has been silence from you since our calls last month, and why you are yet to
reply to our follow up enquiry of August 30.

To allow Adcom to make a decision on the matter, and to advise the other
cctld
managers we understand you have also privately approached, we ask for
answers to the following questions:

1. Do you intend to continue discussing the formation of an assistance group
with the cctld representatives, or are those discussions discontinued on
your part?

2. Which cctld managers have you picked to be on your group, and what are
the principles by which that selection was made?

3. Which other non- cctld representatives have you thought it appropriate to
add to your  group, and what are the criteria you have developed and applied
in your selection process?

4. What is the mandate of the assistance group, and particularly, is
bridging the gap between the cctld consensus position and the Blueprint
ruled out?

You will understand the temptation for the Adcom to regard this group as a
top down device, cynically designed to provide evidence of support for the
Blueprint from a constituency of ICANN that has publicly opposed several
major features of the Blueprint. You will understand the dilemma your
conduct poses to cctlds, who in the main continue to be supporters of a
White paper principles-based ICANN, and who oppose your procedures and
conclusions but nevertheless wonder whether it might be appropriate to take
one more (possibly final) chance to contribute to the shared ideal.

The difficulty they face is in accepting appointment to a position which
seems
to be limited to implementing something the cctlds have articulated clear
consensus disagreement with.

The answers to our questions will be of assistance in advising our members,
and we look forward to hearing from you.

Regards

ccTLD adcom

****************************************************************************
**********

From: Theresa Swinehart [mailto:[email-masked]]
> Sent: September 6, 2002 2:17 PM
> To: [email-masked]
> Cc: Alejandro Pisanty
> Subject: invitation from Alejandro Pisanty, ERC Chair, to participate
in
> the ccNSO Assistance Group
>
>
> Alejandro Pisanty, chair of the ERC, asked me to send the appended
note on
> his behalf.
>
> ********************
>
> Dear Bernie,
>
> As the Chair of the ERC, I am writing to ask whether you would be
willing
> to
> participate in a Assistance Group we are establishing to assist in
coming
> up
> with recommendations on the details of the ccNSO that is, to assist
the
> ERC
> on the formation of the ccNSO as part of ICANN's reformed structure.
The
> ERC
> is extending invitations to this Assistance Group to a variety of
ccTLD
> managers,  including two from the AdCom, as well as members of the
non-
> ccTLD
> manager community. This is consistent with the planned structure of
the
> ccNSO Council according to the Blueprint for Reform. A full list of
> participants will be available upon confirmation of acceptance from
all
> invitees. The bulk of the Assistance Group work will occur in the
month of
> September, with the objective to incorporate outcomes into the third
> Interim
> Report of the ERC, currently scheduled to be completed around 1
October.
>
> The charge for this group is to provide the ERC with recommendations
in
> relation to the ccNSO within the framework of the Blueprint. The
Blueprint
> outlines the overall structure of the ccNSO, but still requires
details on
> the membership of the council and membership of the ccNSO; the scope
of
> the
> ccNSO, and the process of policy development in the ccNSO. The
Assistance
> Group's recommendations will be given great weight and careful
> consideration
> by the ERC, but the ERC of course reserves the right to make
adjustments
> or
> modifications in formulating its final recommendations to the Board
and
> the
> community.
>
> It is important to note that the role of the Assistance Group is not
to
> re-argue decisions already made by the ICANN Board as embodied in the
> Blueprint, nor to be an advocacy platform at all. It is intended to
> provide
> the considered input of knowledgeable people in making recommendations
to
> the ERC for developing the ccNSO within the framework outlined in the
Blue
> Print. It is not intended to be a vehicle for determining or recording
> community-wide consensus. You are free, of course, to take any
positions
> on
> any subjects, including this one, in other fora, but this Assistance
Group
> is solely to help the ERC with the ccNSO within the boundaries defined
by
> the Blueprint.
>
> The existence and membership of this Assistance Group, and the limits
of
> its
> charge, will be announced by the ERC, upon confirmation of all
invitees.
> The
> work product of the Assistance Group will be posted upon its receipt
by
> the
> ERC. In its review of the recommendations, the ERC will explain any
> differences between the input received and the recommendations that it
> ultimately offers to the community.  If there are any differences,
members
> of the working group will of course be completely free to comment on
those
> as they see fit, as indeed are any members of the community, that is,
your
> autonomy or freedom to speak by participating in this effort is not
> inhibited. Your work is simply a voluntary contribution to the
> considerable
> implementation work that the ERC is now undertaking, and only in the
> context
> of that work are you constrained by the framework of the Blueprint.
>
> With regard to timing, the Assistance Group will be working on a fast-
> track,
> with completion of recommendations on 25 September. The ERC has just
> posted
> its second Interim Implementation Report, and the work of this
Assistance
> Group will contribute to the output of the third and final
Implementation
> Report, which will be the basis for final ERC recommendations to the
Board
> at the ICANN meeting in Shanghai. That third report, for which the
> recommendations are relevant, is to be completed on or about 1
October. So
> there is little time.
>
> We have chosen the members of this group based on their interest and
> ability. It is the ERC's hope that the invitees will seek in a
collegial
> way
> to produce truly workable processes that will serve the ICANN
community
> well, and will neither advantage nor disadvantage any particular part
of
> that community.
>
> If you are willing to assist the ERC, and accept this charge, as
described,
> please let me know as soon as possible. The ERC has asked Theresa
> Swinehart
> to be the point of contact to assist the ERC in the coordinating the
work
> of
> this Assistance Group. Please copy her on your response as well. We
would
> hope to announce the formation of this group no later than early next
week.
> Thank you for your consideration.
>
> Alejandro Pisanty
> ERC Chair
>
>

- --
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 #1416
*************************