ICANN/DNSO
DNSO Mailling lists archives

[ga-full]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: User input in the ccSO (was Re: [ga] FW: Comment from the gTLD Registry Constituency


Peter and all assembly members,

Peter Dengate Thrush wrote:

> ----- Original Message -----
> From: "Vittorio Bertola" <vb@bertola.eu.org>
> To: "Peter Dengate Thrush" <barrister@chambers.gen.nz>
> Cc: <ga@dnso.org>; <cctld-discuss@wwtld.org>
> Sent: Monday, September 30, 2002 9:46 PM
> Subject: Re: User input in the ccSO (was Re: [ga] FW: Comment from the gTLD
> Registry Constituency
>
> On Mon, 30 Sep 2002 13:57:40 +1200, you wrote:
>
> >It is also true that there are areas where coordinated action between ICANN
> and the ccTLDs could benefit both of them.
>
> Interesting semantics -ICANNis supposed to be the coordinator of the
> players, including the ccTLds and, say the Address registries. Interesting
> that it has a role of its own, and we are expected to coordinate with it....

  Yes this is interesting but with their recent announcement that ICANN under
the new MoU it is supposed to stick to it's knitting so to speak, i.e. technical

coordination issues only with representation os all of the interested
stakeholders/users.

>
>
> >For example, since there is to be
> some form of At Large membership, perhaps the ccTLDs who already have it or
> want to have it could share the burden of registering individuals, so users
> would sign up once for ICANN and for their ccTLDs, and the general workload
> to maintain this membership would be smaller. This is definitely something
> that the users and the ccSO should discuss in the near future.
>
> I have facilitated the presence of At Large speakers at several of the past
> ICANN meetings, but have to say that the cctlds are little interested in
> this sort of additional work load.

  This is a shame that the ccTLD registry "Managers" are so disinterested
in their registrant because of the additional "Workload"...  This is obviously
part and parcel to the stakeholers/users being dissatisfied with the level
of service from some ccTLD's registries that they are receiving and that
fuels the fires of ICANN stepping in and redeligating those ccTLD's
that are seemingly loaded with dissatisfied Registrants, ect...

  Perhaps an attitude change from some ccTLD's is necessary or
in their best interest?  Perhaps the ccSO effort could sponsor with
other stakeholders/users, especially from the ISP community, a
"ccTLDatlarge"?  ccTLDatlarge.org anyone and/or Peter?  I am
pretty sure that a number of our [INEGroup] members would be willing
to assist in sponsoring this sort of effort.  It would also serve to off
load some of the "Workload" that you mention here in your above
response, Peter.  Are your Game?

>
>
> >Again, I agree with your view, and I agree that ccTLDs should not be forced
> to adopt policies that they don't like (instead, they should be encouraged
> to do so by the fact that those policies are good, and that most other
> ccTLDs are adopting them). Anyway, since there are policies that would
> benefit from central coordination - just to name one, WHOIS uniformity
> across the ccTLDs
>
> Excuse me, but a policy cannot benefit from coordination  -some of the
> participants might.In this case, there are huge local law issues that make
> it certain that a uniform approach to whois is most unlikely -for the
> forseeable.

  You mean "Not for the foreseeable future"?  If so, I would tend to
agree.  But ICANN is trying to change or force this issue, and
has for some time now.  Such a forceful effort will only gain the
legal community financial benifits and serve to only confuse,
disgruntel, and add to cost to the stakeholders/users.  I don't
find that very stabilizing...

> See the recent lawsuit threated against Nominet in the UK as a
> recent example of the local policy/ local law in operation.

  Yes just read that yesterday.  Very interesting indeed.

> The fact that
> there is an enormously passionate dabate in (just) the g space on whois
> issues( trade mark owners/biz vs individual privacy/ safety, for eg) might
> indicate that when you take this issue and muliply it by 190 culural and
> legal flavours you are going to get a complex cocktail, not a milkshake...

  Good point here.  And I hope well taken as well...

>
>
> - there must be a way for the ccSO to develop such
> policies at a central level, with the input of the users too.

  I briefly mentioned one (See above).  A ccTLDatlarge might
be useful here...

> This is why we
> (as the ALAC Advisory Group) suggested that there should be an At Large
> liaison to the ccSO Council.

  Liaisons are fine for some purposes, but for actual stakeholder/user
representation they are basically useless as the stakeholders/users
of ccTLD's have really not direct voice, and no vote at all.  That's
not representative at all...

> I would strongly suggest, for example, that
> when the ccSO sets up working groups it should include a representative of
> the ALAC in them. Would you consider this?
>
> Yes. We have had a DNSO liaison Group for some time, are working with the
> GAC on regional liaision and expect to establish other formal liaison
> systems with others.
>
> Regards
> Peter Dengate Thrush
> Senior Vice Chair
> Asia Pacific TLD Association
> ccAdcom Meeting Chair
>
> --
> This message was passed to you via the ga@dnso.org list.
> Send mail to majordomo@dnso.org to unsubscribe
> ("unsubscribe ga" in the body of the message).
> Archives at http://www.dnso.org/archives.html

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 jwkckid1@ix.netcom.com
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 ga-full@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga-full" in the body of the message).
Archives at http://www.dnso.org/archives.html



<<< Chronological Index >>>    <<< Thread Index >>>