RE: [council] Alternate Roots: A discussion paper

["Antonio Harris" <harris@cabase.org.ar>]

Grant,

Congratulations on this excellent paper.

Tony Harris

----- Mensaje original -----
De: "Grant Forsyth" <grant.forsyth@clear.co.nz>
Para: "names council" <council@dnso.org>
Enviado: Martes 8 de Mayo de 2001 07:25
Asunto: [council] Alternate Roots: A discussion paper


> I agree with those who have advocated the need to discuss this matter and
to
> develop a policy contribution to the Board. I contribute the following
paper
> in order to facilitate productive discussion within the NC.
> I have also attached it as a Word document for those who find this easier.
> I may not be able to join the call, which is a real shame, but I look
> forward to the results of the discussion.
>
>
> Alternate Roots Issues
> Paper for Discussion
> 7 May 2001
>
> By Grant Forsyth, BC Rep
>
> I have noted the discussions that has been circulating on the NC mail list
> on the matter of Alternate Roots and the suggestion that there be a
> discussion on the next audio.  I thought it would be useful to make some
> opening observations and proposed policy directions that could form the
> basis for that discussion.
>
> Some founding principles
> In considering the question of alternate roots, it should be taken as
given
> that:
> 1. A unique naming scheme is an absolute requirement for an orderly and
> stable Internet. See
> http://www.icann.org/correspondence/iab-tech-comment-27sept99.htm (is
there
> any further update on this technical view?)
>
> 2. ICANN and parties in support of ICANN have no ability or wish to
> influence the operations of other enterprises outside the purview of
ICANN -
> such as the Pacific and Atlantic Roots
>
> 3. While "increasing competition" is one of the objectives of ICANN
> this must necessarily be restricted to address those operations operating
> within the sphere of ICANN's responsibility.
>
> 4. ICANN does need to actively manage the Internet space that it has
> responsibility for and the DNS within it, in order to maintain stability.
>
> I would contend that the above four points do NOT need discussion, hence
our
> discussion can focus on what policy directions we might propose to the
ICANN
> Board in order to meet these principles.
>
> Elaboration on the need for principle 1
> I think it might be instructive to build the case for principle 1.  There
is
> enough that is confusing and concept challenging about the Internet for
most
> businesses and individuals, that removing any added confusion derived from
> conflicting or misrepresented naming schemes has to be hugely beneficial.
> Leaving aside issues of fraudulent misrepresentation, there is simply the
> burden of time wasting for users in not reaching the address that they
> expect to reach.  For businesses there is the additional issue of ensuring
> that your trademarks are properly protected and represented on the
Internet.
>
>
> Possible Policy Directions
> Working from the above "givens", it now behoves the NC to articulate
policy
> in order that the ICANN Board can formulate plans and processes to ensure
> Principle 4 above is implemented.  I suggest the following for discussion:
> A. Given 2 above, ICANN should not seek to "coordinate" anything with
> any other party that chooses to do its own thing in its own space.  Other
> parties should be left to develop their own naming scheme for use in their
> own name space.  If they choose to implement naming schemes that are
> similar, or more importantly, confusingly similar, that should not be of
any
> concern to either their users or users in the ICANN DNS space as the two
> naming spaces will be operated quite separately.
>
> B. ICANN should not seek to limit naming schemes that other operators
> might choose to develop in their private space, to do so might be
construed
> as being anti-competitive.
>
> C. ICANN, on behalf of its stakeholders, should take as many active
> measures as it can to maintain the stability of the DNS that it is
> responsible for.  Such measure might include:
> i) ICANN should include requirements for specific performance
> in contracts with those parties who require authorisation from ICANN to
> operate in the ICANN DNS space, EG Authorised Registries and Registrars be
> required to not misrepresent other name structures as being related to or
> accessible from within the ICANN DNS space.
> Note: This is NOT to suggest ICANN seek to restrict
> the ability of a Registry or Registrar from also working with an
> organisation other than ICANN.
>
> ii) ICANN should consider the merits of forming contractual
> relationships with other parties where there is no current formal
> contractual relationship.  This would be with the express purpose of
> enhancing stability and reducing confusion.  Such parties might include
non
> gTLD registrars, ISPs, web browser providers, even individual commercial
> domain name holders.  This should be a positive win-win relationship.
>
> iii) ICANN should, with the assistance of its wide stakeholder
> base, promote the unique qualities and benefits of operating in the
Internet
> Space for which it has management responsibility.
>
> The "problem" of new.net
> With regards to the "problem" of new.net, I suggest a similar variant to
> that above. In my view, the issue with new.net is not that they are
creating
> sub-domains that are similar to gTLDs.  They should be free to do so, just
> as ccTLDs should be free to do so.  The problem is that it appears that
> new.net is misrepresenting how these domains eg, www.your.biz.new.net, are
> going to be able to be promoted eg. as www.your.biz and then working with
> ISPs (anyone else?) to have them conspire with new.net to support this
> misrepresentation by way of corrupting the unique resolution of
truncated -
> hence not unique - names.
>
> Again ICANN should be actively managing a resolution to the problem along
> the lines of:
> i. Strengthening contracts with Registries and Registrars to include
> specific performance clauses on the misrepresentation of a gTLD.
>
> ii. Creating the same positive "authorisation" process with ISPs and
> others, based upon their support not to misrepresent and mis-resolve
unique
> domain names.
>
>
> As an aside
> I take as a useful model, in developing my thinking on the ICANN DNS and
> anyone else's DNS, is that of telephone numbering.
>
> The ITU is responsible for ensuring a globally unique numbering scheme
> operates for its constituent members (those countries that are members of
> the ITU or who choose to abide by its rules).  In so doing, the ITU is the
> sole manager and issuer of country codes eg +44 for the UK, +64 for NZ.
The
> country code is allocated to Government authorised body (NOTE: The only
> reason that the Government comes into play here is a quirk of history and
> that telephone numbering is generally geographically constrained - I am
not
> suggesting that Governments are a necessary element in the allocating of
> ccTLDs).  The duly authorised holder of a country code will then be free
to
> develop the sub numbering scheme, eg, area codes, toll free codes, local
> number ranges, etc, within a very high level overall number length
> limitation.
>
> While all PSTN (public switched telephone network) operators develop their
> own numbering schemes within the ITU and authorised government numbering
> management authority, to ensure the PSTN numbering scheme is unique, they
> are also free to develop their own - and quite likely conflicting -
private
> numbering schemes for their VPN (virtual private networks).  Each operator
> is required to manage the interface between their VPN and the PSTN so that
> their clients do not have any "confusing conflicts".  They most certainly
do
> not represent to either their VPN users or the users of another PSTN, that
a
> customer's VPN number is contactable from another PSTN.
>
> Regards
>
> Grant Forsyth
> Manager Industry & Regulatory Affairs
> CLEAR Communications Ltd
> Private Bag 92143 Auckland
> ph +64 9 912 5759
> fx +64 9 912 4788
> Mobile (021) 952 007
> email grant.forsyth@clear.co.nz
>  <<Alternate Root Issues for Discussion.doc>>
>