comments on last draft

[Olivier Guillard <Olivier.Guillard@nic.fr>]

Dear Scott and all,

Afnic is the .fr registry. We have read this draft:
http://www.ietf.org/internet-drafts/draft-ietf-provreg-grrp-reqs-01.txt
with a great interest.

We thank you for this job that contribute harmonizing
practises.

We wished to ask you some questions and express ideas
about certain chapters found in this document either
because we don't understand them or because they doesn't
matche our practises.

For an easier reading:

Each point is framed by a ** REM ***...
The chapters titles are given
The particular suggestions added in the original text are underlined
                                                          ^^^^^^^^^^
Regards,


Olivier


1. Introduction
---------------

** BEGIN REMARK ***************************************************

Thin Registry: A registry in which some element of the social information
               associated with registered entities is distributed between
               a shared registry and the registrars served by the registry.

Thin Registry: A registry in which all elements of the social information...
                                   ^^^

just a comment here: there is no definition for those registries that
                     validate information (social and/or technical)
					 stored and published for a given TLD.
					 

** END REMARK ***************************************************


3.4.2 Object Registration
-------------------------

** BEGIN REMARK ***************************************************

  [3] The protocol MUST provide services to register name servers.  Name
  server registration MUST NOT be limited to a specific period of time.
  Name servers registered within the registry's authoritative TLDs MUST
  be registered with a valid IPv4 or IPv6 address.  A name server MAY be
  registered with multiple IP addresses.  An IP address MAY be shared
  among multiple name servers using distinct server names. Name servers
  that exist in TLDs other than those for which the registry is
  authoritative MUST be registered without an IP address providing that
  the server's TLD is itself a valid TLD.

.fr db don't need independant name server objects today. We understand
that name servers objects can be useful, but only in certain environment
and only if their maintenance are associated with relevant policie
usage (like contacting the techs that maintain domains served by a
nameserver being suppressed for example). 

Anyway, the time spent to check the integrity of existing datas under
certain environment does not justify today the implementation of such
a feature, for us, it shouldn't be a requirement.

Morover, if it's implemented, we don't see why the IP address should be
required. It is only necessary when a given NS serves a zone under which
it's referenced.

For example:

If exemple.fr is served by ns.exemple.fr, then we need the IP of
ns.exemple.fr as glue.
If exemple.fr is also served by ns.example.com or ns.dupont.fr it's
not our buisness to announce the IP address of those hosts, so why
ask for this information? (we check that these NS are properly
resolved before announcing exemple.fr)

We would suggest a "SHOULD" and a "MAY" here:

  [3] The protocol SHOULD (or even MAY) provide services to register
                   ^^^^^^          ^^^
  name servers.  Name server registration MUST NOT be limited to a
  specific period of time. Name servers registered within the
  registry's authoritative TLDs MAY be registered with a valid
                                ^^^
  IPv4 or IPv6 address.


** END REMARK ***************************************************

** BEGIN REMARK ***************************************************

  [4] The protocol MUST provide services to manage name servers that MAY
  be associated with multiple domains.

Why again (see above)?

  [4] The protocol MAY provide services to manage name servers that MAY
                   ^^^
  be associated with multiple domains.


Something like:

"The protocol MAY provide services to manage multiple domain name maintaining."

Would be another way of maintaining multiple domain changes


** END REMARK ***************************************************



3.4.3 Object Association
------------------------

** BEGIN REMARK ***************************************************

  [2] The protocol MUST provide services to associate IP addresses with
      name servers. Name servers MAY have multiple IP addresses.  An IP
      address MAY be associated with multiple name servers.

Once again, we don't see why IP addresses of NS should be required.

--->  A name server MAY NOT be associated to any IP address.
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

** END REMARK ***************************************************

** BEGIN REMARK ***************************************************

  [4] Some managed objects represent shared resources that MAY be
  referenced by multiple registrars.  Requests to associate a known
  shared resource object with another registered object MUST NOT be
  limited to the registrar that sponsors the registered objects.  For
  example, server ns1.example.com (managed by registrar X) MAY be
  associated with both domain example.com (managed by registrar X) and
  domain test.com (managed by registrar Y). Registrar X maintains
  administrative control over domain example.com and server
  ns1.example.com, and registrar Y maintains administrative control over
  domain test.com.  Registrar Y does not have administrative control
  over server ns1.example.com.

A question here: what happens to test.com if example.com is removed?

And another more important one:
Who is responsible for the db integrity?


** END REMARK ***************************************************


3.4.5 Object Transfer
---------------------

** BEGIN REMARK ***************************************************

  [2] The protocol MUST provide services to transfer social information
  objects among authorized registrars.

This point is sensitive, because personal information do not have the
same status in each country. For example we have implemented a red list
for domains belonging to individuals.


** END REMARK ***************************************************
** BEGIN REMARK ***************************************************

  [6] The protocol MUST provide services that allow the original
  sponsoring registrar to approve or reject a requested object transfer.
  Requests to approve or reject the transfer of registered objects MUST
  be limited to the registrar that currently sponsors the registered
  object.  Unauthorized attempts to approve or reject the transfer of a
  registered object MUST be explicitly rejected.

For how long? What happens if the registrant WANTS to transfer his/her
domain and the current registrar doesn't? is there any grace period?

the real point is: where is the user here?

** END REMARK ***************************************************

3.4.7 Object Deletion
---------------------
** BEGIN REMARK ***************************************************

All sub chapters
----------------

whois responsible for the db integrity?


** END REMARK ***************************************************


3.4.8 Object Existence 
----------------------

** BEGIN REMARK ***************************************************

  [2] The protocol MUST provide services to determine if a name server
  exists in the registry.  Name servers MUST be searchable by fully
  qualified name.

->  [2] The protocol MAY provide services to determine if a name server
                     ^^^
see above

** END REMARK ***************************************************
** BEGIN REMARK ***************************************************

  [3] The protocol MUST provide services to determine if a social
  information object exists in the registry.  Social information MUST be
  searchable by a registry-unique identifier.

What if this information is not connected to any domain name object?
For example, I personally think that it should be cleaned up and in
all cases NOT published anymore (issue to manage in 3.4.8)

** END REMARK ***************************************************

3.4.9 Object Information Query
------------------------------

** BEGIN REMARK ***************************************************

  [2] The protocol MUST provide services to retrieve information
  describing a name server from the registry. 

->  [2] The protocol MAY provide services to retrieve information...
                     ^^^

see above


** END REMARK ***************************************************
** BEGIN REMARK ***************************************************

  [3] The protocol MUST provide services to retrieve social information
  from the registry.  Returned information MUST include identification
  attributes (which MAY include name, address, telephone numbers, and
  e-mail address), the identifier of the registrar that originally
  registered the information, the creation date and time, the date and
  time of the last successful update (if any), the identifier of the
  registrar that performed the last update, the date and time of last
  successful transfer request or completed transfer (if any), the
  most recent authorization information and identifiers describing
                                            ^^^^^^^^^^^^^^^^^^^^^^
  domain names associated with the social information
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


** END REMARK ***************************************************


3.5 Domain Status Indicators
----------------------------

** BEGIN REMARK ***************************************************

SUGGESTION:

One of the states could be "validation process". A domain name
could then be pending waiting for (for example) an intermediate
service or a third party validation.

It would allow to implement the following (page 19):

"However, intermediate services that preserve the integrity of the protocol
MAY be provided. For example, an intermediate service that determines if a
registrant is authorized to register a name in a TLD MAY be provided."


** END REMARK ***************************************************


7.6 Security
------------

** BEGIN REMARK ***************************************************

  [1] Transactional privacy and integrity services MUST be available at
  some protocol layer.

  [2] This document describes requirements for basic user identification
  and authentication services.  A generic protocol MAY include
  additional security services to protect against the attacks described
  here, or a generic protocol MUST depend on other-layered protocols to
  provide additional security services.

==> What do "basic user identification and authentication services"
consist of? Why isn't AUTHENTICATION at least as important as PRIVACY
and INTEGRITY (presence of MUST key word)?

** END REMARK ***************************************************

-- 
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