ICANN/GNSO GNSO Email List Archives


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

Re: [ispcp] ISPCP Statement on New Registry Services

  • To: mcfadden@xxxxxxxxxxxxxxxxxxxxxx, ispcp@xxxxxxxx
  • Subject: Re: [ispcp] ISPCP Statement on New Registry Services
  • From: Greg Ruth <greg_ruth@xxxxxxxxx>
  • Date: Mon, 10 Nov 2003 13:24:36 -0800 (PST)
  • In-reply-to: <200311101910.hAAJAWia000871@mailbag.com>
  • Sender: owner-ispcp@xxxxxxxxxxxxxx

    Good stuff!  Just a few observations:

1.  Suggest changing "thoughtfully thinking" (which seems a tad
redundant) to "carefully thinking" or "thoroughly thinking".

2.  Where you say, "No new registry service should be introduced
without an explicit evaluation..." I think it would be best to
explicitly state "public evaluation" or words to that effect.  I'm
sure VeriSign believes it thoroughly evaulated (internally) its new

3.  Where you talk about principles by which constituencies ought to
be bound in the dev elopment of new services - SiteFinder wasn't
developed by a "constituency", but rather by a contractor to ICANN,
viz. VeriSign.


--- Mark McFadden <ireland@xxxxxxxxxxx> wrote:
> Regarding the Proposed Issues Report on Registry Services
> Internet Service Providers and Connectivity Providers Constituency
> The ISPCP Constituency has a direct connection with a significant
> body of
> Internet stakeholders.  Our customers - those people connected to
> the
> Internet - are the people and organizations most affected by
> unexpected
> changes in the Internet.  This includes the introduction of new or
> modified
> registry services.  Naturally, the ISPCP constituency needs to be a
> significant contributor to the Registry Services PDP process.
> ISPs are in a unique position to help guide policy development on
> new
> registry services. As those who have been largely responsible for
> the
> stability of the Internet, we believe that it is vitally important
> that the
> GNSO and its Council balance the need to move quickly on potential
> registry
> services while thoughtfully thinking through operational and legal
> impacts
> of any recommendations. Our constituency actively supports the
> principle of
> maintaining the stability that the Internet has always enjoyed. 
> Specifically, we believe that there is a requirement for technical,
> security
> and stability reviews for any newly proposed registry service.  In
> addition,
> we believe that any significant change to registry services - that
> significantly changes or alters fundamental functions of DNS
> related
> services - should also be subject to an explicit and extensive
> security,
> stability and technical review.
> No other group in the GNSO is as well positioned as the ISPCP to
> coordinate
> the technical evaluation of the protocol and operational impacts of
> a
> proposed change to registry services.  Our constituency works daily
> with
> both the protocol standards that make the DNS work and is fully
> aware of the
> operational issues that are not part of the protocols, but which
> are
> embedded in the operational behavior of Internet protocols and
> services. 
> Fundamentally, our constituency believes that:
> "	No new registry service should be introduced without an explicit
> evaluation of its technical, stability and security implications;
> "	No significant changes to registry services should take place
> that
> have the potential to significantly change the behaviour of
> underlying
> Internet services;
> "	The ISPCP constituency should be a central contributor to any
> discussion of the technical implications of the introduction of new
> registry
> services;
> "	All constituencies should be bound by the "principle of least
> astonishment" in the development of new services that affect the
> foundation
> protocols of the Internet; and,
> "	All constituencies should be bound by principles of operational
> security and stability for the Internet's user community.
> On behalf of the ISPCP Constituency,
> Mark McFadden
> ISPCP Secretariat

Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard

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