ICANN/GNSO GNSO Email List Archives

[ispcp]


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

RES: [ispcp] ISPCP Comments on the ICANN Strategic Plan

  • To: "'Mark McFadden'" <mcf@xxxxxxx>, "'Mansourkia, Magnolia'" <Maggie.Mansourkia@xxxxxxx>
  • Subject: RES: [ispcp] ISPCP Comments on the ICANN Strategic Plan
  • From: "Antonio Tavares" <atavares@xxxxxxxxxxxxxxx>
  • Date: Thu, 30 Dec 2004 04:43:29 -0200
  • Cc: "'Mark McFadden'" <mcfadden@xxxxxxxxxxxxxxxxxxxxxx>, <ispcp@xxxxxxxxx>, <ispcp-activities@xxxxxxxxx>
  • Importance: Normal
  • In-reply-to: <1102062088.41b02208e6406@panthermail.uwm.edu>
  • Organization: DIALDATA
  • Reply-to: <atavares@xxxxxxxxxxxxxxx>
  • Sender: owner-ispcp@xxxxxxxxxxxxxx

Dear Mark

Would you please send us the powerpoint presentation you have made during
our constituency meeting about comments on ICANN Strategic Plan?
Thanks
Antonio Tavares

-----Mensagem original-----
De: owner-ispcp@xxxxxxxxxxxxxx [mailto:owner-ispcp@xxxxxxxxxxxxxx] Em nome
de Mark McFadden
Enviada em: sexta-feira, 3 de dezembro de 2004 06:21
Para: Mansourkia, Magnolia
Cc: 'Mark McFadden'; ispcp@xxxxxxxxx; ispcp-activities@xxxxxxxxx
Assunto: RE: [ispcp] ISPCP Comments on the ICANN Strategic Plan

Hi Maggie!
We miss you here in Cape Town.

The issue of >3 character TLDs came up in the constituency again.  But I
believe
that there is a general realization that the ISPs are not responsible for
filtering those names at this point.  In an answer to a question on this
topic
I said that I saw no evidence that ISPs were filtering DNS resolutions nor
were
they filtering outbound SMTP traffic based on names.  It's tragic, but the
problem is much more difficult than this.  Instead, there are software
developers and applications builders that seem to think that TLDs are always
either two or three characters in length.

That's a much more difficult community to reach through education and
outreach. 
What I think is happening is that there is a gradual realization that
blaming
the ISP community for the problem is a very easy, but not very effective
approach to the problem.

mark
Secretariat
ISPCP Constituency, gNSO


Quoting "Mansourkia, Magnolia" <Maggie.Mansourkia@xxxxxxx>:

> Hi guys. How are the meetings going? I think what you've come up with
below
> is great and have nothing further to add.  Also, I'm curious-any further
> discussions from registries re the alleged filtering of newer TLDs?
> Cheers,
> Maggie
>
> -----Original Message-----
> From: owner-ispcp@xxxxxxxxxxxxxx [mailto:owner-ispcp@xxxxxxxxxxxxxx] On
> Behalf Of Mark McFadden
> Sent: Thursday, December 02, 2004 11:39 AM
> To: ispcp@xxxxxxxxx
> Cc: ispcp-activities@xxxxxxxxx
> Subject: [ispcp] ISPCP Comments on the ICANN Strategic Plan
>
> The ISPCP would like to make the following remarks in support of the
> strategic plan and raise a few issues.  Whilst the strategic plan is seen
as
> a welcome step forward, we have concerns that the proposals still lack
> measurable objectives and detailed timelines.
>
> ï&#65533;²	The Strategic Plan is unclear as to whether the relationship
between
> ICANN and the Root Server Operators will be formalized to the extent of a
> contractual relationship.  The ISPCP supports the formalization of
> relationships with the Root Server Operators.  The precise nature of that
> relationship is a matter that we reserve comment upon.  Whatever that
> relationship ends up being, those providing Root Server functionality must
> be accountable to ICANN.
> ï&#65533;²	We support the five key suggestions for IANA including:
improving
> IANA request tracking and responsiveness; providing more reliable
operating
> capacity; doing better reporting from IANA on operations issues; making
root
> zone management professional; and, making root servers themselves more
> robust.  We especially support the move towed project management
orientation
> for request tracking and crucial IANA transactions.
> ï&#65533;²	We believe that the reference made to the ASO Community
â&#8364;&#339;building
> global consensus policy governing IP addressesâ&#8364;&#65533; is not
supported by the
> demise of an independent ASO and the assertion of global address policy
> development by the RIR CEOs through the NRO.
> ï&#65533;²	The ISPCP welcomes the appointment of the ombudsman and the
role in
> helping to educate consumers â&#8364;&#8220; a task, which in the past,
has
often been
> left to ISPs.
> ï&#65533;²	We are also glad to see more emphasis placed on compliance
so that
> policy work developed within the gNSO becomes more meaningful.
> ï&#65533;²	It is essential that all ICANN activities result from a
bottom-up
> process and the PDP process needs to be flexible and tailored to meet the
> demands of individual policy opportunities.
> ï&#65533;²	We seek more information with regard to the proposed
regional
> meetings: whether they will be focused on outreach and education
activities,
> or part of the formal policy development process.  If the latter, then the
> ISPCP questions how this will be integrated into the discussions necessary
> at full, global ICANN meetings.
> ï&#65533;²	Whilst we have commented on some of the issues raised by the
ISPCP
> consideration of the strategic plan it is apparent that far more
discussion
> and consultation is required.  Therefore, the ISPCP requests that the
ICANN
> Board of Directors acknowledge this requirement and seek to address it in
a
> manner that meets with the full acceptance of the ICANN community.
> ï&#65533;²	The ISPCP also notes with dismay that the Supporting
Organizations
> were not consulted prior to the public dissemination of the document.
While
> the intent may be to craft a plan for operation and management of ICANN,
it
> is clear that the plan has far-reaching consequences for
ICANNâ&#8364;&#8482;s
delivery
> of
> services and thus, its policy.  This process needs to change so that
> Supporting Organizations have a meaningful way to have input at an earlier
> stage in the plan development.
>
> Mark McFadden
> ispcp-activities@xxxxxxxxxxxxxxxxxxx
> Secretariat
> ISPCP Constituency, ICANN
>






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