Subject: Re: [provreg] Lists and EPP

From: [email-masked]
Date: Wed, 08 Jun 2011 23:14:42 -0400

> There's also zone file access and ICANN reports ...

The access control models for Zone File access and SRS access are distinct.

The sink for connections over which Registry Reports are transported is 
neither a registry, nor a registrar, nor is the data contained in such
reports contact, host, or domain objects.

> We're about to start to see an onslaught of articles where
> registrars are going to talk about how they can only assimilate 1 TLD
> per month or perhaps 3 in 2 months. ...
 
Lack of planning on their part, the difference in temporal density of
engineering deltas, even if mere repitition of certification checks with
no change of state other than the associated name space and account
identifiers from the 2004 and 2001 experiences has been a matter of
record for over three years now.

Registrars which implemented agile clients had foresight.

Eric

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 9 Jun 2011 08:42:43 +0200

> Registrars which implemented agile clients had foresight.

It is not that simple...

A registrar have one user interface, regardless of whether it is a web page or API. That exposes a certain business logic to the registrants.

The registry then translates the business logic regarding registration, renewal, transfer etc into the specific logic that the registry in question require.

This implies both changes in the business logic and epp requirements.

And in many cases it does not matter how agile clients you have...because the way renewal works for example, and requirements from the registry that certain things must be exposed to the registrant and what not.

   Patrik

---

From: "Jan Jansen" <[email-masked]>
Date: Thu, 9 Jun 2011 08:50:52 +0200 (CEST)

Hi all,

At the risk of opening a bad can of worms ... An alternative to
the 'long' list could be to add a reference to the 'next' object
similar to the 'DNSSEC zone walk' way. It preserves the EPP object
style and allows to generate a list on the receivers side.
On the bad side, it does not provide a unique view as things might
change while retrieving the list although I guess that as a registrar
you wouldn't care to much if you can do this on a regular base, say
once a day or so.

It might produce some heavy load on registry systems though.
(But then again, we had to think more like registrars and less
like registries ?)

Fitting a round peg in hexagonal shape hole ?

-jan-

> A registrar have one user interface, regardless of whether it is a web
> page or API. That exposes a certain business logic to the registrants.
>
> The registry then translates the business logic regarding registration,
> renewal, transfer etc into the specific logic that the registry in
> question require.
>
> And in many cases it does not matter how agile clients you have...because
> the way renewal works for example, and requirements from the registry that
> certain things must be exposed to the registrant and what not.
>
>    Patrik
>
> _______________________________________________
> provreg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/provreg
>

---

From: Jothan Frakes <[email-masked]>
Date: Wed, 8 Jun 2011 23:51:26 -0700

I agree the agile client approach is wise.

Meanwhile, the registrars that are downstream from registries have to
make a lot of changes to accommodate delta between implementation A
and implementation B of EPP / Business Logic, etc.  Many of the
changes present themselves once the developers are in the OT&E wading
pool and notice the differences between systems, which planning can't
necessarily overcome.

These 'opportunities' to address the differences simply present
themselves with the need to address them, not unlike a jury summons or
a flaming paper bag on the doorstep after a ring of the doorbell.

Jothan