RE: comments on your grrp-reqs-05.txt (second try)

["Jordyn A. Buchanan" <jordyn@register.com>]

I'm going to make some comments and at the end of this message I'll suggest 
specific language to address the issues I raise.

At 09:46 AM 1/8/2001 -0500, Hollenbeck, Scott wrote:

>The idea here is that there needs to be a registry-unique "key" that can be
>used to unambiguously identify every transaction performed by the server on
>behalf of a client.  Both client and server know the "key", so both have
>information that can be used to reconcile client-server activity.  No client
>knows the "keys" associated with the transactions of any other client.
>
>This uniqueness plays into my motivation for using these identifiers in the
>transfer process.  While a thick registry may have end-customer information
>that can be used to authenticate transfer requests, a thin registry may not.
>The protocol has to provide a transfer mechanism that works equally well in
>both environments.
>
>The transaction identifier is known to the sponsoring client and the server.
>If the client (registrar) also provides the identifier to the registrant,
>the registrant can take the identifier to a second registrar (who won't know
>the identifier by any other means) to facilitate a transfer.  If the
>protocol requires this identifier to process transfer actions, transfer
>mistakes or unauthorized transfers should be minimized.

This sounds clumsy to me.  If these identifiers are going to be unique and 
not easily guessable, they're probably not particularly 
user-friendly.  This isn't a big deal when we're talking about 
registry/registrar protocol interaction, but I can't imagine that these 
transaction IDs are the kind of things that reigstrars are going to want to 
hand out to domain holders every time they register or modify a domain 
name.  Even if it did become routine for registrars to pass this 
information down to domain holders, I think we're expecting a lot if we 
think that users are going to hold onto these identifiers for an indefinite 
length of time.  This parallels your own objection to using digital 
signatures for transfers--the technology works, but the user probably won't 
put it to good use.

More generally, I think specific mechanisms for authenticating the transfer 
of objects between registrars is a matter of registry policy that will vary 
widely.  The section on transfers should include a requirement that the 
protocol allow the registrar requesting the transfer to pass in information 
to authenticate the transfer, but not get into specifics about what that 
information should be.  (It could be a transaction ID, or a digitial 
certificate, or something as mundane as a password.)

As a final note on this topic, I think that requiring the transaction ID to 
approve or cancel the transfer is unnecessary.  The protocol should be able 
to validate whether or not a request comes from an appropriate registrar 
without this information.  (Basically, the registrar has already 
authenticated themselves--we should be able to determine that the "cancel 
that transfer" comamnd comes from the right place in the same way that we 
determine that the "delete that domain" command does.)

Staying on the topic of transaction IDs, but moving on to a new issue, I 
think that in many circumstances it is not necessary for the registrar to 
pass a transaction ID to the registry.  This should be optional:  if a 
registrar passes in a transaction ID, the registry should use it, but if 
the registrar does not, the registry will generate a unique ID and return 
it once the transaction is complete.  (I'll even concede that I can see 
circumstances when we'd want the transaction ID to be required, but I can 
also see circumstances when the registrar can simply wait and use whatever 
the registry gives them.)

> > 3.4.[3]
> >
> >       ``A request  Must have a transaction identifier ... ''
> >
> > If it is a request for a new domain, should the registrar generate
> > this? It looks like a bootstrapping problem to me, I'm confused
> > but might just not understand. Also
>
>I think I need to reword this text to make it clear that an identifier MUST
>be associated with the transaction, but how it happens is up to the protocol
>designers.

I agree with this.  The text here is actually not problematic (except that 
it requires the registrar to pass in the ID, which I think is unnecessary), 
but 3.3 [1] could probably be re-worked to add the clarity you describe.

> >       ``The transaction identifier MUST be returned to the
> > registrant ...''
> >
> > This sounds as a requirement to how the registrar operates and is
> > outside the scope the registry/registrar protocol. At least, I
> > haven't seen how the protocol can enforce this.
>
>If the identifier is needed to authorize a transfer (which I believe is a
>Good Thing), the identifier has to get to the client (new registrar) who
>issues a transfer request.  The protocol can enforce this by not processing
>a transfer action without the identifier, but perhaps this requirement
>should be changed to not touch on registrar-registrant interaction.

See my comments above on this.  I don't think this should be a requirement; 
we could make it optional, but if that's the case, it really is about the 
relationship between the registrar and registrant and out of scope.

> > 3.4.[6] contact information
> >
> > I have the feeling that the required contact information might be
> > too detailed in certain cases. If the registry/registrar relation
> > is very thin it is possible that just information over the registrar
> > might be sufficient. (But then one can argues thses also have a
> > name, address etc. so it won't hurt.
>
>True, but the protocol has to support both thick and thin models.  It's
>important to distinguish between what the protocol has to do to support
>multiple models, and how each registry may use the protocol.  Section 2.4
>says that an underlying assumption is that a registry may choose to
>implement a subset of the required protocol features, and this is one area
>where I think registries will choose to do things differently based on local
>policies.

While I agree with Scott's statement above, I think that right now the 
requirements are too strict.  Different registries may have different 
notions about what information is required for a contact and what is 
optional.  I suggest we require the protocol handle all of the various bits 
of information, but not require which ones need to be filled out.

> > 3.4.[8] identifiers
> >
> > The mention of ``contact identifier'' remembers me of NIC-handles.
> > I'm also not so sure that all the mentioned identifiers are actually
> > necessary in an actual protocol. Maybe the MUST should become a
> > MAY?
>
>I think there has to be some kind of unique key associated with every
>object.

This is certainly useful at a protocol level, even though many registries 
and/or registrars may not choose to make such extensive use of the 
NIC-handle concept as we may be used to in the .com/.net/.org world.

> > Sections 3.7.[1] - 3.7.[7] describe the basics of the transfer of
> > the objects between registrars. Apart from that, it does something
> > else in the mean time. It actually defines policy matter: The
> > original sponsoring registrar is able to block the transfer. Either
> > (implicitly) by never releasing the current transaction identifier
> > or directly by using 3.7.[7].
> >
> > Whether or not a registrar is able to block such a transfer is a
> > policy matter. Currently it is not allowed in the .nl registry (and
> > as far as I know in .den either). Some time ago it was possible to
> > do this in .nl, but on request of various registrars and given the
> > experience gained, this is no longer the case. It turned out that
> > when there were conflicts between registrant A and registrar X and
> > A wanted to switched to registrar Y, X basically could take the
> > domain from A hostage. Often the registry was dragged into the
> > conflict to decide whether of not the domain was correctly taken
> > ``hostage'', often was forced to take a side in the conflict. The
> > conflicts can be arbitrary. Non-payment by A for services provided
> > by X, non-delivery of services by X paid for by X, or just petty
> > complaints, the dog of A has bitten the cat of X. You name it, we
> > seem it all.
> >
> > The task for a registry is to registry names. Even for conflicts
> > whether or not someone has the right on a certain domain name is,
> > for most registries not part of their job. For that are dispute
> > arbitration thingies or courts of law. So to be dragged into
> > arbitrary conflicts is even worse. Therefore we abolished this
> > blocking. Other registries might have a different policies.
> >
> > Anyway, I tried to reformulate 3.7.[1] and further in a policy
> > neutral fashion, but failed miserably. But I do hope we can come
> > up with something.
>
>This feature has to be in the protocol (it's 100% required in the ICANN gTLD
>world), but it sounds like transfer request blocking by the old registrar
>should be an optional feature.

Yes.  The protocol has to have the capability to allow this, but it 
shouldn't be required for all transfers.

Okay, that's it for now.  Specific changes to language are below.

---

3.3 [1] Registry operations that create, update, or delete objects MUST be 
associated with a registry-unique transaction identifier.  This identifier 
MAY be provided by the registrar, in which case the same identifier MUST be 
returned by the registry.  In the event that the registrar does not provide 
the identifier, the registry MUST generate and return a new transaction 
identifier.

3.4 [3] A request to register an object MAY include a transaction 
identifier. If the registrar includes a transaction identifier with the 
request, this identifier MUST be returned to the registrar.  If the 
registrar does not include the identifier, the registry must generate and 
return a new transaction identifier upon the successful registration of the 
object.


3.4 [6] The protocol MUST provide services to register contact information 
describing human and organizational entities. Contact registration MUST NOT 
be limited to a specific period of time. Contact registration MAY include a 
name (individual name, organization name, or both), address (including 
street address, city, state or province (if applicable), postal code, and 
country), telephone number, facsimile telephone number, and e-mail address.

3.7 [4] The protocol MUST provide services that allows the registrar 
initiating the transfer to pass information which authenticates the 
transfer to the registry.

3.7 [6] The protocol MUST provide services that allow the requesting 
registrar to cancel a requested object transfer before the request has been 
approved or rejected by the original sponsoring registrar. Requests to 
cancel the transfer of registered objects MUST be limited to the registrar 
that requested transfer of the registered object.  Unauthorized attempts to 
cancel the transfer of a registered object MUST be explicitly rejected.

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

3.7 [9] The protocol MUST support a configurable period during which time a 
request to transfer the registration of an object MAY be approved, 
rejected, or cancelled.