RE: comments on last draft

["Hollenbeck, Scott" <shollenbeck@verisign.com>]

>-----Original Message-----
>From: Olivier Guillard [mailto:Olivier.Guillard@nic.fr]
>Sent: Tuesday, April 10, 2001 2:10 PM
>To: Hollenbeck, Scott
>Cc: ietf-provreg@cafax.se; tech@nic.fr
>Subject: Re: comments on last draft
>
>
>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.

This is why 8.2-[1] was added based on an earlier request from you.  It
already says that validation services may be provided.

[snip]

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

Not specifically, because it's more a matter of how a registry manages it's
data.

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

My assertion is that this is the most reasonable of multiple options, and
that it is indeed possible to maintain relational integrity.

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

That functionality is already provided in the "approve", "cancel" and
"reject" transfer mechanisms described in section 3.4.5.

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

Yes, I think so.

>> >** 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).

I think we'll have to agree to disagree on this point.

<Scott/>