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

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

Thanks for the comments, Jordyn.  Based on earlier comments regarding
transaction identifiers I agree that we need to change the requirements
somewhat, but in a way that's slightly different than what you've proposed.
I'll explain below.

<Scott/>

> -----Original Message-----
> From: Jordyn A. Buchanan [mailto:jordyn@register.com]
> Sent: Tuesday, January 09, 2001 1:03 PM
> To: Hollenbeck, Scott; 'Jaap Akkerhuis'
> Cc: ietf-provreg@cafax.se
> Subject: RE: comments on your grrp-reqs-05.txt (second try)
> 
> 
> 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.

I don't think "user-friendly" is an issue because they'll be needed by users
_only_ when they wish to transfer a domain.  If they happen to lose track of
the identifier it should be very easy to recover it from both registry and
registrar on demand.

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

I agree from the requirements perspective; we can save the debate on how
this should work for the protocol discussion.

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

Thinking ahead to protocol I think it's simpler and cleaner if transfer
command syntax remains consistent, but since this does get into the
mechanics of _how_ transfers operate I think we can strike the text that
describes this as a requirement.

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

I believe this topic would be more appropriate to tackle when we talk
protocol.  For now, I think it better if we use words like this to identify
the need for transaction identifiers (this came up in an earlier discussion
regarding section 3.3):

"[1] Registry operations that create, update, or delete objects MUST be
associated with a registry-unique identifier.  The protocol MUST allow each
transaction to be identified in a permanent and globally unique manner."

This describes _what_ the protocol has to do without making any statements
about _how_ it should be done.

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

OK, this could be as simple as changing a MUST to a MAY in 3.4-[6] as you
noted.

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

Both of these requirements have already been changed to remove any mention
of _how_ the identifier should be created or used.
 
> 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.

Got it.

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

I'm OK with these changes, too.

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

We earlier discussed bagging this requirement completely because it
describes registry implementation detail.  I'd prefer to delete it than
reword it.