RE: comments on last draft

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

>-----Original Message-----
>From: Olivier Guillard / AFNIC [mailto:Olivier.Guillard@nic.fr]
>Sent: Wednesday, April 11, 2001 6:14 AM
>To: Hollenbeck, Scott
>Cc: ietf-provreg@cafax.se; tech@nic.fr
>Subject: Re: comments on last draft
>
>
>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.

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

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

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

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.

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

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.

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

My objection is that the kind of abstract object relationships described are
more appropriately determined by a query protocol or reporting service.

<Scott/>