Subject: RE: [ietf-provreg] Unique identifiers for Contact

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 5 Apr 2004 12:52:32 -0400

> Agreed. What are the chances of this being accepted as standard?

Zero.  The RFCs were just published.  The only opportunity for change now is
if/when the documents are considered for progression to draft standard.
That won't be in the near future.

Plus, I'm not convinced that this is a real problem.  What kind of "check
storms" are you expecting when creating contacts?  If you can handle the
volume of check commands received for domain names, the volume of contact
checks is probably quite small in comparison.  In addition, this sort of
server-created identifier would make the contact create command inconsistent
with the domain and host create commands.

-Scott-

---

From: Antony Perkov <[email-masked]>
Date: Mon, 5 Apr 2004 18:18:26 +0100

In case anyone is interested, this is something we enforce as a matter of
policy in the .coop registry.  

It has worked well so far in terms of preventing ID collisions, but is a
little strange when people start transferring contacts back and forth, and
causes some confusion when people first integrate with our system (i.e. when
they get errors because their IDs don't comply with our rules).

> -----Original Message-----
> From: Rick Wesson [mailto:[email-masked]] 
> Sent: 05 April 2004 17:51
> To: Andre Marais
> Cc: IETF Provreg
> Subject: Re: [ietf-provreg] Unique identifiers for Contact
> 
> 
> Pick a namespace for all your contacts, such as 
> FLAME-?????-CT anything
> created with that prefix is yours, the likely hood of others creating
> contacts within your space seems unlikely.
> 
> the handlespace is 16 chars wide (it think) and should have plenty
> of unused names.
> 
> -rick
> 
> On Mon, 5 Apr 2004, Andre Marais wrote:
> 
> > Hi All,
> >
> > When looking at EPP base commands (specifically check) and 
> the contact
> > mapping specification I could not help but notice the following with
> > regard to the check command for provisioning contacts 
> within the system.
> >
> > If a registry wants to provision a contact within the 
> system, it first
> > needs to poll the systems using contact:check, and only if 
> the unique
> > identifier (which might be arbitrarily chosen) does not 
> exist, could it
> > create the identifier with the relevant required information.
> >
> > Now even though such a scheme would work (initially), what 
> would happen
> > when you have 10 registrars (or even more) all provisioning within a
> > single registry, and using any particular identifier 
> generation scheme
> > (random, range sequential etc) to generate identifiers for 
> provisioned
> > contact records. As the number of contact records increase 
> (or rather
> > the number of unique identifiers) and the number of 
> registrars increase,
> > the probability of unique identifiers clashing increases also.
> >
> > When these identifier clashes become more frequent, one could expect
> > that there would be an increase in contact:check command 
> storms together
> > with a increased latency when processing transactions that requires
> > contact provisioning.
> >
> > Shouldn't there be a command that allows for identifier 
> generation on
> > the server side which would eliminate this type of problem?
> >
> > If this was discussed before, and a solution was provided, 
> please direct
> > me so that I could steer clear of digging up old bones.
> >
> > Regards,
> > Andre
> >
> > --
> > Reading, after a certain age, diverts the mind too much from its
> > creative pursuits. Any man who read too much and uses his own brain
> > too little falls into lazy habits of thinking.
> >  - Albert Einstein.
> >
> > 
> --------------------------------------------------------------
> ---------
> > LEGAL DISCLAIMER:
> > The views or representations contained in this message, 
> whether express
> > or implied, are those of the sender only, unless that 
> sender expressly
> > states them to be the view or representations of an entity 
> or person,
> > who shall be named by the sender and the sender shall state to
> > represent. No liability shall otherwise attach to any other 
> entity or
> > person.
> > 
> --------------------------------------------------------------
> ---------
> >
>