RE: [ispcp] ISPCP Comments on the ICANN Strategic Plan
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.
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?
> -----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.
> ï�² The Strategic Plan is unclear as to whether the relationship
> 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.
> ï�² 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.
> ï�² We believe that the reference made to the ASO Community
> global consensus policy governing IP addressesâ€� 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.
> ï�² The ISPCP welcomes the appointment of the ombudsman and the role in
> helping to educate consumers â€“ a task, which in the past, has
> left to ISPs.
> ï�² We are also glad to see more emphasis placed on compliance so that
> policy work developed within the gNSO becomes more meaningful.
> ï�² 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.
> ï�² 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.
> ï�² 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.
> ï�² 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â€™s
> 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 Constituency, ICANN