<<<
Chronological Index
>>> <<<
Thread Index
>>>
Re: [nc-transfer] Standardized definitions
Ross,
It is definitely a good idea to have definitions document,
but it must be very carrefully drafted.
Looking from ccTLD perspective - I am chairing the CENTR IANA WG
and we are utmostly interested in definitions issue - I will have
several additions or corrections to make, and I would do so with
the help of my colleagues.
My prima facies immediate observation (reaction epidermique
en francais) is that it is very important to NOT re-write old
definitions to the ICANN gTLD scheme Registry-Registrar-Registrant,
and be very carreful to some ICANN new concepts, which did appeared
with new gTLD, and which are not accepted imposed on ccTLD.
As an example, the word Internic was never associated by
old Internautes with any webthing, but with
"whois -h rs.internic.net" query. The NIC-Handle was - and is still
- the name of object associated with Administrative or Technical
Contact, etc, etc.
The "Sponsoring Organization" in plain English (quoting a native
English European) is associated in Europe with something like
Formula 1 race, and Camel cigarettes. ICANN try to re-write history
transforming ccTLD Managers to "Sponsoring" camels, and
unilateraly put it on their IANA website.
Re your note "Whois", why you do not mention RIPE database software,
free and used worldwide.
I stop here, more off line, an input to your document.
Elisabeth
--
> From owner-nc-transfer@dnso.org Tue Jan 15 16:06 MET 2002
> Message-ID: <004c01c19dd6$4941b650$040a000a@RRADER2K>
> From: "Ross Wm. Rader" <ross@tucows.com>
> To: <nc-transfer@dnso.org>
> Subject: [nc-transfer] Standardized definitions
> Date: Tue, 15 Jan 2002 10:07:01 -0500
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> X-Priority: 3
> X-MSMail-Priority: Normal
> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
>
> In the past, I have found that DNSO discussions of policy often get bogged
> down by discussions of definition. Unfortunately, there really is no lingua
> franca that bridges the gap between the colloquial terms that we all use,
> the contractual terms employed by the staff and the technical terms in use
> by the engineers. For instance, I've noticed that the people that register
> domain names are interchangeably referred to as SLD Holders, Registrants,
> Users, Members, Subscribers and Customers.
>
> This dynamic often leads to a lack of understanding that slows down the
> interchange of ideas and occasionally has completely derailed discussions on
> important issues. Early last year, this became apparent to me so I undertook
> the creation of a document that spelled out what the definition of these
> various terms are. In the intervening period, I have found this document to
> be useful in a number of forums as a basis for establishing a common
> understanding that we could base our discussions on.
>
> This document, entitled "Domain Name and Related Definitions" may at some
> point be submitted to the IETF for inclusion in their RFC archive. While it
> has received substantial peer review and has been modified several times, I
> don't believe that it is quite firm enough to become an official IETF
> document. Definitions occasionally carry unintended political statements
> that I would like to ensure don't exist in this document before I submit it.
>
> Anyways, this entire ramble is a roundabout way of saying that I believe
> that this document will be useful for our purposes here. We have several
> groups in this task force, each with their own evolved language, that needs
> to be brought together for a common purpose. Hopefully this document will
> assist in bringing us together.
>
> The abstract for this draft is:
>
> A number of policy and technical development efforts related to the
> DNS are underway, both within the engineering community, ICANN-
> circles and elsewhere in light of the current and evolving scope and
> utility of DNS, domain name registries and related entities. In
> order for this work to be truly effective and broadly applicable, it
> is important that accepted definitions act as the foundation. This
> document is an attempt to create a starting point for the requisite
> dialogue that will ultimately foster the determination and
> acceptance of these new protocols. This document obsoletes <draft-
> rader-dnwhois-defn-00.txt> and <draft-ietf-provreg-dn-defn-01.txt..
>
> The entire document can be found online at
> http://www.byte.org/drafts/draft-rader-dn-defn-00.txt
>
> Please let me know if you see any areas where this document can be improved.
>
> Thanks,
>
> -rwr
>
>
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|