[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [wg-c] Please Explain "No on 1, Yes on 2" (More)



At 02:42 PM 4/12/00 -0400, John Charles Broomfield wrote:

All TLDs should be chartered. The charter defines if the TLD is generic, or 
restricted, or whatever. That way there is no blockage. If the restricted 
TLD's charter can't be figured out, then it doesn't delay any other TLD 
from being in the root (i.e. even other restricted TLDs which do have a 
sound charter). Generic TLDs (the .COM type) will end up with a fairly 
boilerplate "generic" charter.

>Hi,
>I did an abstain/no vote/whatever (hey, Eric picked it as a "a" instead of
>"A" :-) ) because I think that mixing gTLDs and chartered/limited TLDs is
>mixing apples an oranges. If things are sorted out for both types at the
>same time, then fine for adding whatever, but if concerns on the chartered
>side are not ironed out, why block the generic side, and vice-versa.
>The concerns and issues to be dealt with are VERY different in both cases
>(although they have many TECHNICAL similarities).
>Similarities:
>-they are both strings of characters that would be entered in the legacy roots
>-in both cases there will be an entity running a database that generates the
>  zone file.
>-in both cases there will (presumably) be multiple secondaries located in
>  different geographic areas for resilience.
>-both will have SLDs visible under them.
>(further technical requirements imposed on the entities maintaining the
>database may be common sense, o BCP).
>Unfortunately, apart from those generalities, I feel that it ends there.
>
>The idea many of us in this WG (certainly not all) have of a gTLD is an
>unrestricted TLD open to registration to all those who wish to register in
>it through some sort of registrar facility (which many argue to keep
>separate from the registry so as to allow multiple choice), with no
>limitations (other than technical) on the choice of characters for the SLD,
>with a pricing cheme which is dependent on the value-added services that one
>may (or not) be getting packaged along together with that name (which, as
>the additional services are NOT strictly linked to the registry operations,
>is why we argue for separate cost-recovery no-frills backend registry
>operations). Stability of these generic TLDs should not be in the hands of
>the entity doing the backend registry operations (which will probably be some
>sort of service company trying to make a profit running these services), but
>in the hands of some entity higher up in the food chain, which as we have it
>would be ICANN. The entity running the backend registry owes allegiance to
>itself, and noone else, so it would just be looking at how to maximise it's
>profits, not through streamlining its operations, but by raising tariffs as
>far as it could go, without killing off the cashflow (if by doubling tariffs
>you lose just 25% of your customers, it certainly makes sense -at least to me-
>to double your tariffs, as your cashflow would be increased by 50%, and your
>profits by more than that -the extra 100% is PURE profit-).
>Issues to be resolved are precisely the confirmation (or denial) of much
>which I mention above. Things like:
>-Is the registry to be run on a cost-recovery basis? (which doesn't preclude
>  a for-profit company bidding to win a tender to run it and making a profit
>  out of that).
>-Are registry/registrar functions forced to be kept separate? If so, are the
>  registry-registrar interface specs something that the registry entity
>  decides, or the registrar entity, or mandated by ICANN to use an open
>  standard?
>-Is ICANN the ultimate authority on how/who/what are operations for a gTLD?
>  (like who runs them, and being able to decide to redelegate)
>-How and who to decide which are the strings that constitute a gTLD? (first
>  choose registry and let it choose what it wants? Somehow draw up a list of
>  a bunch of gTLDs that some sort of consensus is given about them being a
>  good idea in a generic way to become gTLDs? Allow ICANN to "dictate" new
>  gTLDs with no community input?...)
>...
>
>Once those issues are resolved, presto we have everything we need to go
>ahead (these ARE the issues we've been arguing over for the past few years)
>with gTLDs.
>
>On the other hand, for chartered TLDs, these are (in some ways) very similar
>to ccTLDs, in that a homogeneous community is identified that wishes to have
>a TLD (the community of museums, or of american indigenous people, or of ham
>radio operators...), and therefore responsability for that TLD is
>transferred to this community. All operations, pricing, registrar-registry
>structure, profit or not, would be completely up to that community. After
>all, it is THEIR TLD (and therefore, THEIR PROBLEM), as with ccTLDs...
>The issue to be resolved before delegating chartered TLDs are completely
>orthogonal to those for delegating generic TLDs:
>-Is there really a justification for creating a TLD for this specific
>  community (some may argue that this is also an issue with generic TLDs)?
>-Who decides what constitutes a community? (we could argue that ccTLDs are
>  chartered TLDs, in which the charter for creation is that they have to be in
>  ISO-3166, and from there they get delegated to the country -or whoever shows
>  up from that country/territory-).
>-Is the entity requesting the delegation in the name of that community
>  representative of that community?
>-Is there consensus within that community for this entity?
>...
>
>As you can see, I feel that the issues are VERY different (some may disagree
>and take the stance that a TLD is just a bunch of characters and there is no
>difference between .com, .mil, .fr and .to but we would just have to agree
>to disagree there).
>
>This is why I personally declined to answer in favour or not of bundling
>chartered TLDs and generic TLDs in the first rollout. If I think a little
>further (and if I am permitted to change my vote) I actually vote NO to
>bunching them together, because the issues are so different, that they won't
>necessarily be resolved simultaneously, and therefore delays in defining one
>shouldn't hinder the other.
>
>Yours, John Broomfield.
>
> > Bret A. Fausett wrote:
> > > Or is the "No" on #1 based on the concern that there are too few 
> gTLDs to be
> > > implemented? too many?
> >
> > Just for clarification, I didn't misread the question -- but I did read 
> some
> > votes against #1 (when coupled with a vote for #2) as a vote revisiting the
> > 6-10 question. In my mind, affirmation of the S/K principles assumes a
> > multiplicity of TLD models, "from open TLDs to restricted TLDs with more
> > limited scope." But perhaps others read them differently.
> >
> > So I would also ask, does N/Y/x mean that one supports 6-10 new gTLDs
> > meeting the S/K principles that but one hopes that they are all open gTLDs,
> > all closed gTLDs? If so, that seems a poor test of the S/K principles
> > themselves. Why am I wrong?
> >
> > Thanks.
> >
> >        -- Bret
> >
> >
> >