Re: comments on last draft

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

le mardi 10 avril à 14 H 27 , Hollenbeck, Scott a écrit :
> >1. Introduction
> >---------------
> >
> >** BEGIN REMARK ***************************************************
> >
> >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.

I understand, but as part of a generic registrar registry protocole, and
regarding the practises of many TLDs, I suppose that this service should
be formalized within the object management sections and seen as a requirement.
For many reasons, as many other ccTLDs, we need to check and validate the
demands of DN.

> 
> [snip]
>

shame :(

additional sections in root servers can be a real pain if not properly
maintained.


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


Well, if I understand what you say:

1)    domain name object, with a required field ("name" or "designation"
      e.g.: "toto.com.");
2)    name server objects whith an equivalent required field that depend
      on a domain name object designation (e.g: ns1."toto.com.")
3)    the maintenance of these objects should not be centralized (here
      starts the troubles)
3bis) for example, a domain object might be remove, this operation having
      no effect on the namerservers designated by this domain (no foreign
	  key in nameserver objets is another word).

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


I would appreciate other point of view on this topic because personally, I
don't think that this option is the most reasonable to maintain relational
integrity.



> >> >3.4.5 Object Transfer
> >> >---------------------
> >> >
> >> >  [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.

You mean it's "implicit" in the following sentence:

	Unauthorized attempts to approve or reject the transfer of a registered
	object MUST be explicitly rejected.

It seems to me that allow the original sponsoring registrar to approve or
reject a requested object transfer is a policie question, not a technical
requirement anyway. But I understand that some registries might need this
feature (actually we do). In this case, the grace period element should
be more explicit.


> >> >3.4.7 Object Deletion
> >> >---------------------
> >> >whois responsible for the db integrity?

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

By experience, I don't.


> >> >  [3] .... crouik ....
> >> >  successful transfer request or completed transfer (if any), the
> >> >  most recent authorization information and identifiers describing
> >> >                                            ^^^^^^^^^^^^^^^^^^^^^^
> >> >  domain names associated with the social information
> >> >  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >> 
> >> 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.

I don't see the problem to see this fonctionality implemented if it's
possible to NOT use it?


Regards,

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