Re: comments on last draft

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

le mercredi 11 avril à 08 H 30 , Hollenbeck, Scott a écrit :
> >> >** BEGIN REMARK ***************************************************
> >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.
> 
> This isn't necessarily a protocol issue, it's a back-end policy issue!  What
> your registry does within your back end is your business; the protocol
> shouldn't introduce any features that keep you from doing what you need to
> do.  That's what 8.2-[1] says. 

This kind of check might be performed by the registry, by the registrar or
by a third party which is not the registrar, nor the registry. An entry
to be able to discusse with the server to perform this seem important in
many TLD environement.

> More than once people have complained about requirements that had a policy
> slant, and I've removed or reworded every one that was brought to my attention.
> Thus, I don't believe it proper to add a new policy-oriented requirement.

I'm sorry, but reading this paper I have a lot of difficulties to discern
what are technical-oriented requirements from what are policy-oriented
requirements.


> 
> >> 
> >> [snip]
> >>
> >
> >shame :(
> >
> >additional sections in root servers can be a real pain if not properly
> >maintained.
> 
> Shame?  It's common e-mail courtesy to remove sections of a message
> for which no response is provided, and I think we've addressed the
> name server-IP address issue very thoroughly as part of another
> thread.

Exact, and it seems that there is no consensus on this topic.


> >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.
> 
> Klaus just raised a similar thought with name server and domains objects on
> another thread.  I've responded there as well, and I'd like to carry on that
> discussion there if possible to help keep it focused.

Scott, I havn't found the thread, sorry.
I don't see any satisfactory answer to this question.


> >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.
> 
> No, you've quoted the wrong sentence.  Look at 3.4.5-[5] and -[6], where it
> very clearly says that a registrar has to have an opportunity to approve,
> reject, or cancel transfer requests.  There used to be explicit mention of a
> grace period, but it was removed because someone (sorry, I forget who) said
> that was a matter of registry policy.  As written, saying that a registrar
> MUST have an opportunity to approve or reject a transfer means that it can't
> happen right away, which means that there has to be an opportunity (or grace
> period) to respond.

We don't talk about the same issue. My question is how long the registrant
will see his/her domain blocked for if the original registrar reject any
transfert attempts?


> >> >> >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
>          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> My objection is that the kind of abstract object relationships described are
> more appropriately determined by a query protocol or reporting service.

My objection here is that your objection is subjective, I could object the
same way for more than half of the datas return on this one for example:

  [1] The protocol MUST provide services to retrieve information
  describing a domain name from the registry.  Returned information MUST
  include the identifier of the current sponsoring registrar, the
  identifier of the registrar that originally registered the domain, the
  creation date and time, the expiration date and time (if any), 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
  current status of the domain, the most recent authorization
  information, identifiers describing social information associated with
  the domain, and the child name servers registered in the domain.  The
  most recent authorization information MUST be returned only to the
  current sponsoring registrar.


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
|| tel: +33 1 39 30 83 31