<<<
Chronological Index
>>> <<<
Thread Index
>>>
[comments-whois] [Olivier.Guillard@nic.fr: Re: whois survey DNSO and IETF]
FYI
----- Forwarded message from Olivier Guillard / AFNIC <Olivier.Guillard@nic.fr> -----
One of the major thing that confuse users is due to the
improper use of the word "registrant" in most of the gtld
model.
Etymologically speaking, the word : "registrant" is the one
that register a domain name. It is linked to the action of
creating a domain, something that happen once in the life of
this domain.
This is very different than from having rights on the name
or than being a permanent contact for administrative issues
concerning the domain.
Practically speaking, under the gtlds, the registrant is the
one that has all the power on the operations that can be
perfomed on the domain name.
Do you still have rights if nothing is done so that they are
implemented ?
The improper use of the terminology "registrant" in the GTLD
environment brings a lot of troubles.
Olivier
le lundi 12 août à 14 H 17 , Olivier Guillard / AFNIC a écrit :
>
> To go further, let's gather information from other strategical Internet
> sources, by commentting related IETF working groups:
>
> Provisioning Registry Protocol (provreg-EPP) or Cross Registry Information
> Service Protocol (crisp) discussed in IETF make assumptions that I feel more
> political (or at least historical) than technical. It will of course have
> incidences on the registries database manipulation and data publication,
> of course critical for whois.
>
> Some concrete remarks:
>
> first, their are two different working groups discussing about common
> issues: EPP and CRISP talk about accessing a central registry repository
> (even if EPP is registrar operation oriented while CRISP is more talking
> about publication to the Internet community).
>
> Second, in both case the "registrant" is seen has having a particular
> statutes (look in EPP for example: <domain: registrant ...> is different
> than <domain:contact ...>). This is probably not relevant, particulary
> in the ccTLD environment and for IP community needs. It would be of course
> a good idea to distinguish between registrant (the one that register a
> name) and the holder of the name.
>
>
> Following link to a domain name would probably clarify
> who is who:
> **********
>
> holder : compulsory and unic
>
> registrant : compulsory and unic
>
> registrar : compulsory and unic
>
> tech-contact : at least one compulsory and possible multiple
>
> admin-contact : optional and possible multiple
>
> billing contact : optional but unic if exists
>
>
> more Info:
> *********
>
> holder : the one that hold
>
> registrant : the one that register
>
> registrar : who knows :)
>
> tech-contact : for example the registrar technical
> contact and/or the registrant
> technical contact and/or the holder
> technical contact. At least one
> technical contact is required;
>
> admin-contact : an optional entry for lawyers
> for example. Also one can imagine
> that a domain can be share by more
> than one entity. This option could
> be provided as a service for the
> community;
>
> billing contact : in a thick model, from the registry
> point of view, the billing contact
> is the registrar, so this entry shouldn't
> be required. It could be provide as
> a service for the registrar community;
>
> Data:
> ****
>
> For the data attached to those contacts, see at the end of
> this mail (Individual and Organizational Names, e-mail adress,
> etc.). Other information could be also attached like trademark
> numbers, to promote added value service like domain names
> qualification (see http://www.eureg.org/principles).
>
> I don't see the technical justification of giving a particular
> statutes to one of those contacts (like "registrants" might have
> in EPP).
>
> Two things that should be attached to those contacts are
> surely:
>
> - Policy and security on updating data (who, how...)
>
> - Policy and security on accessing data (who, how...)
>
> Such policies should be a mix between:
>
> - Local legislation
> - Registry policies
> - Contact preferences
>
> Quick other comment:
> *******************
>
> > names MAY be provided in both UTF-8 [RFC2279] and a subset
> > of UTF-8 that can be represented in 7-bit ASCII depending on
> > local needs
>
> The concept of "local needs" is very difficult to perceive in
> the global environment. Practically, I know no implementation
> that fully support UTF8, and for me those IETF discussions are
> of course GTLD oriented. Supporting non-ascii caracters in DN
> and whois is one of the local needs, but not the only ccTLD
> constraints.
>
>
> SOME RELATED DRAFT EXTRACTS:
> ***************************
>
> FROM: draft-ietf-provreg-epp-domain-04.txt
> ##########################################
>
> - If supported by the server, one OPTIONAL <domain:registrant> element
> and one or more OPTIONAL <domain:contact> elements that contain
> identifiers for the human or organizational social information objects
> associated with the domain object.
>
>
> FROM draft-ietf-crisp-requirements-00.txt
> #########################################
>
> 3.2.4 Domain Registrant Search
>
> The service MUST provide the capability of searching for registrants
> by exact name match or a reasonable name subset. The service MAY
> provide limits to the number of results from this search to
> alleviate performance or comply with Section 3.1.1. If the service
> limits the number of results from this search to alleviate
> performance, it MUST provide the client with a response indicating
> this condition. If the service limits the number of results from
> this search to comply with Section 3.1.1, it MUST NOT provide the
> client with a response indicating this condition.
>
> The service MUST provide a mechanism to distribute this search
> across all applicable domain registries and registrars. The service
> SHOULD have a means to narrow the scope of a search to a specific
> TLD. The service MUST be able to specify to the client an empty
> result set should the search yield no results.
>
>
>
> FROM draft-ietf-crisp-lw-user-00.txt
> #####################################
>
> The target inetOrgPerson entries MAY have any number of attributes
> defined, with any number of access restrictions, as required by
> local security policies, government regulations or personal
> privacy concerns. However, the mail attribute MUST be defined,
> MUST be valid, and MUST have anonymous read permissions.
> Furthermore, all of the attributes MUST be secured against
> anonymous add, delete and modify permissions.
>
>
> FROM draft-ietf-crisp-requirements-00.txt
> #########################################
>
> 2.4 End Users
>
> 2.4.1 Service Providers and Network Operators
>
> Service providers and network operators provide connectivity,
> routing, and naming services to many other entities, some commercial
> and some non-commercial, both large and small. Their operational and
> administrative staff often interact with Internet registries on
> behalf of other end-users. Service providers and network operators
> interact with all of the Internet registry operators outlined in
> this document on a frequent and consistent basis. For example,
> network operators use the directory services of Internet registries
> to determine contact information for network resources that have
> technical problems.
>
> 2.4.2 Intellectual Property Holders
>
> Intellectual Property Holders have legal rights to the use of domain
> names based on copyright and trademark laws of various governments.
> They use the directory services of Internet registries, mostly
> domain registries and registrars, for purposes of maintaining and
> defending claims to domain names consistent with applicable laws and
> regulations.
>
> 2.4.3 Law Enforcement
>
> Law enforcement agencies use the directory services of Internet
> registries to find information used to carry out the enforcement of
> laws within their jurisdictions.
>
> 2.4.4 Certificate Authorities
>
> Certificate authorities use the directory services of Internet
> registries as part of their verification process when issuing
> certificates for Internet named hosts.
>
> 2.4.5 DNS Users
>
> Users of the Internet have client software that resolves domain
> names to IP addresses. Often when trouble occurs in the resolution
> process of DNS, these users trouble shoot system problems with the
> aid of information from the directory services of Internet
> registries.
>
> 2.4.6 Domain Registrants
>
> Entities given authority over a domain via purchase, lease, or grant
> from a domain registry, either directly or via the services of a
> domain registrar.
>
>
> from draft-ietf-provreg-epp-contact-04.txt
> ##########################################
>
> 2.3 Individual and Organizational Names
>
> Individual and organizational names associated with a contact are
> represented using character strings. These strings have a specified
> minimum length and a specified maximum length. Individual and
> organizational names MAY be provided in both UTF-8 [RFC2279] and a
> subset of UTF-8 that can be represented in 7-bit ASCII depending on
> local needs.
>
> 2.4 Address
>
> Every contact has associated postal address information. A postal
> address contains OPTIONAL street information, city information,
> OPTIONAL state/province information, an OPTIONAL postal code, and a
> country identifier. Address information MAY be provided in both UTF-8
> and a subset of UTF-8 that can be represented in 7-bit ASCII depending
> on local needs.
>
> 2.4.1 Street, City, and State or Province
>
> Contact street, city, and state or province information is represented
> using character strings. These strings have a specified minimum
> length and a specified maximum length.
>
> 2.4.2 Postal Code
>
> Contact postal codes are represented using character strings. These
> strings have a specified minimum length and a specified maximum
> length.
>
> 2.4.3 Country
>
> Contact country identifiers are represented using two-character
> identifiers specified in [ISO3166].
>
> 2.5 Telephone Numbers
>
> Contact telephone number structure is derived from structures defined
> in [E164a]. Telephone numbers described in this mapping are character
> strings that MUST begin with a plus sign ("+", ASCII value 0x002B),
> followed by a country code defined in [E164b], followed by a dot (".",
> ASCII value 0x002E), followed by a sequence of digits representing the
> telephone number. An optional "x" attribute is provided to note
> telephone extension information.
>
> 2.6 Email Addresses
>
> Email address syntax is defined in [RFC2822]. This mapping does not
> prescribe minimum or maximum lengths for character strings used to
> represent email addresses.
>
> 2.8 Authorization Information
>
> Authorization information is associated with contact objects to
> facilitate transfer operations. Authorization information is assigned
> when a contact object is created, and it might be updated in the
> future. This specification describes password-based authorization
> information, though other mechanisms are possible.
>
>
----- End forwarded message -----
--
Olivier Guillard
---
|| AFNIC - Immeuble International
|| 2 rue Stephenson - Montigny-le-Bretonneux
|| 78181, Saint-Quentin-en-Yvelines CEDEX, France
|| http://www.nic.fr/
|| mailto:Olivier.Guillard@nic.fr
|| tel: +33 1 39 30 83 31
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|