Re: comments on last draft

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

Thank you for your quick response

le mardi 10 avril à 12 H 48 , Hollenbeck, Scott a écrit :
> >1. Introduction
> >---------------
> >
> >** BEGIN REMARK ***************************************************
> >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.
> >					 
> There's no additional definition for a "validating" registry because I
> didn't see validation as a model discriminator.

The idea here is that the validating process is a step that need
to be performed under certain TLD (may be not by the registry).
This validation can have many reason (data protection, naming
plan etc.).

An entry point to allow this step must be available somewhere
in the protocole (probably in the object management section),

Something like:

      The protocol MUST provide services that allow a validating service
	  to approve or reject object registration. Requests to approve or
	  reject the registration objects MUST be limited. Unauthorized
	  attempts to approve or reject the object registration MUST be
	  explicitly rejected.

if there is no "validating service" for a particular registry, this feature
will not be used.

> >** END REMARK ***************************************************
> 
> 
> >3.4.2 Object Registration
> >-------------------------
> >
> >** BEGIN REMARK ***************************************************
> >
> >  [3] The protocol ......
> >....cut......
> 
> I think we've covered this particular requirement very thoroughly in another
> thread.  I disagree with the change from MUST to SHOULD or MAY in the first
> sentence; we know for a fact that there are registries that require this
> feature.  The second MUST will be changed to a SHOULD with an explanation of
> when it has to happen.

Ok, I understand the first MUST if there are registries that require this
feature (even if I don't see any reason why we would use this feature today).
But I still think that the question of registring Name Servers with or
without IP is a question of policy regarding the registration of the
name servers objet and shouldn't be stressed by a SHOULD.

--->  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 ***************************************************
> 
> If example.com is removed, server ns1.example.com will have to removed or
> renamed.

Is this a requirement?

> test.com will have to be updated to note the change.  Each
> client/registrar is responsible for the integrity of the objects
> they sponsor.

It means that the client must be very aware of many things :)

Will it be sufficient to have a whole coherent db?

> 
> >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 ***************************************************
> 
> Agreed -- how this is managed will be a registry policy matter.

Yes, that's one of the reason why we need to check and validate if it is
really an individual that register a domain name.

> >** 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 ***************************************************
> 
> "How long" and grace periods are a registry policy matter.  It will be up to
> each registry to figure out what works for them.

Then a fonctionality must be implemented to allow the registry to configure
a grace period in this situation.


> 
> >3.4.7 Object Deletion
> >---------------------
> >** BEGIN REMARK ***************************************************
> >
> >All sub chapters
> >----------------
> >
> >whois responsible for the db integrity?
> >
> >
> >** END REMARK ***************************************************
> 
> Each client is responsible for the integrity of the objects they sponsor.

Will it be sufficient to have a whole coherent db?

> >** 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 ***************************************************
> 
> This gets into another thread that's currently open on the mailing list,
> that of queries returning what Klaus has called "reverse" associations.  I
> don't believe that such a feature is proper in a provisioning protocol, but
> it is appropriate for a query protocol or reporting service.

I think the protocole should support this, even if a registry can
disable the feature (question of policie).



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