Subject: Re: [provreg] Lists and EPP

From: [email-masked]
Date: Thu, 09 Jun 2011 07:42:20 -0400

The "scale" claim I'm still mulling on. When I wrote the first ICANN escrow
spec (registries) I put in the means for an escrow deposit to span more than
a single media capacity, a means also present in the second ICANN escrow spec
(registrars), which somebody wrote.

So the unboundednes of a "record" (or sequence of grouped XML glop) is at
least by the capacity bounds of the transport media (current DVDs are big,
but not infinite), and the transmit capacity between the source and sink
does determine the limit before the trasmission of an instance of a record 
must also contain updates to data within that record.

But I'm not interested in edge cases of EPP-for-Verisign or EPP-for-GoDaddy,
or transport-for-domainers-slamming-the-com-drop-pool, but in the more common
problem, for which a registry policy declaration of the maximum size of a
unit of data (or the equivalent unerlying database access bandwidth) can be
announced to the registrar, just like a dcp.

For this, a LIST command semantics and syntax can be specified and implemented
and interoperability demonstrated, with the option of using the IETF or any
equivalent means of making the specification available without liability to
its authors, implementors and eventual users.

Based upon limited experience with one registry platform operator's dbms,
the LIST command and the LIST response may be sufficienty seperated in time
to require more bookkeeping overhead than a mere wait() and the assumption
of stream semantics.

Eric

---

From: "Gould, James" <[email-masked]>
Date: Thu, 9 Jun 2011 14:03:49 +0000

Eric,

I'm sure that a method could be created to support a bulk list command and
response in EPP, but I question whether it is appropriate for EPP.  This
information is already provided via reports and made available via FTP and
via a web application, so what is the driver for adding this to the
provisioning channel?  Creating an XML response of thousands to millions
of records does represent a scalability issue for the server and the
client.  For bulk data it's best to separate format definition from data,
which is why for data escrow I'm not a fan of the use of XML.  The same
holds true for bulk information.  I don't believe it's a good use of the
limited provisioning resources to support an unbounded bulk data feed,
where the focus should continue to serve the provisioning needs and not
the reporting and synchronization needs.

--

JG

James Gould
Principal Software Engineer
[email-masked]

703-948-3271
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

VerisignInc.com

On 6/9/11 7:42 AM, "[email-masked]" <[email-masked]> wrote:

>_______________________________________________
>provreg mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/provreg

---

From: Jothan Frakes <[email-masked]>
Date: Thu, 9 Jun 2011 10:42:46 -0700

I like that Jan had an Idea about walking the report, but I'd suggest
that it would still place a burden on the EPP communications in the
case of Jim's jumbo jumbo data packet example.

It really shouldn't impact the other users to have such a report
happening, and I could still see that our jumbo jumbo example would
place additional load on the EPP server, and there's a matter of
maintaining state from TRID to TRID on the client side and server
side, so it might even be more fugly of a solution than just pushing
the whole thing in one response.

What about using EPP to trigger a report generation and having the
response contain either a URI to that report or a response token that
allowed a poll message to retrieve that report URI upon the completion
of it being generated?  Perhaps even a poll message that generally
contains a list of the reports available in its response?

Then that data could be retrieved from an out of band process which
would not place undue burden on the networks, and it could easily
retrofit to existing implementations.

-Jothan

Jothan Frakes

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 9 Jun 2011 19:53:31 +0200

On 9 jun 2011, at 16.03, Gould, James wrote:

> provisioning channel?

It does not matter what the mechanism is, as long as _all_ registries use _exactly_ the same mechanism.

Whether epp is used or not is secondary, and from my perspective (with a registrar hat on) up to the registries.

Choose whatever you want, but ONE solution. And then make the specification of that list that _everyone_ use made public.

   Patrik

---

From: Christopher Browne <[email-masked]>
Date: Thu, 9 Jun 2011 14:23:53 -0400

> the whole thing in one response.

When I put my "transactional hat" on, there's a whole lot of ugly there:
- If EPP generates a "jumbo jumbo" packet, that induces largeness in
several places:
  1.  Large, long-running transaction against database, which DB guys
hate for pretty well-understood reasons.
  2.  Very large data packet that crosses the network
  3.  Large amount of network bandwidth is used
  4.  Very large packet of data that needs to be processed by the
client (e.g. - what if there's 17GB of XML needing to be parsed?)

- If EPP has protocol added to split this into more "bite-sized"
chunks, complexity is induced, as we need to have multiple commands
issued, that do partial processing
  1.  If there's a database, one of two things happen:
     a) If a transaction is held open, you wind up with the same
large-long-running transaction, and perhaps it runs longer
     b) If there's a new transaction per request, consistency between
"chunks" is problematic
  2.  The data packets may be of more reasonable size, individually, but...
  3.  There's still a very large amount of bandwidth used.  This part
is invariant.
  4.  Individual data packets are smaller, so more manageable to
clients, but they have a bigger problem in synchronizing them at the
end.

That seems to capture the ugliness pretty well.

> contains a list of the reports available in its response?

I like that idea quite a bit; I think Andrew Sullivan was the first
one to mention it, upthread.

It allows pushing the problems to different places, and I don't think
this is just a matter of us all fooling ourselves into imagining that
it looks better.

It's a very common pattern to say "OLTP system only does OLTP,
Analytics are done elsewhere."

> retrofit to existing implementations.

I suspect that there have been enough workarounds going around that
some registrars may have accustomed themselves to not using the poll
queue facility.  *Some* care needs to be taken so that the poll queue
doesn't become the scary, fragile component that induces the next
round of complaints.

---

From: "Gould, James" <[email-masked]>
Date: Thu, 9 Jun 2011 19:28:41 +0000

I still don't understand the problem that we're trying to solve.  What is
the problem with generating the reports and making the reports available
for consumption by a predetermined schedule and at a predefined location?
Moving the report generation or report generation trigger into the
provisioning system is mixing provisioning and reporting for little added
benefit.  Is the problem the lack of a standard report format?  Is the
problem the need to generate the report on demand?  I believe that these
problems can be addressed outside of EPP.

--

JG

James Gould

703-948-3271
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

VerisignInc.com

---

From: Edward Lewis <[email-masked]>
Date: Thu, 9 Jun 2011 15:53:29 -0400

>use _exactly_ the same mechanism.

Why?

(And I'm not saying it has to be EPP or not has to be EPP.)

A few messages back I mentioned that in meetings 
with some registries, doing the work to increase 
commonality was judged to be "not worth it."  A 
response on this list was that I was reporting 
something that was a sampling of a few registries 
and not representative of registrars.

My comeback (which I just didn't get around to 
asking until now) is the registries do know at 
some level of familiarity, what registrars go 
through.  The relationship is more symbiotic than 
adversarial.  And, as a challenge, if registries' 
opinion is not sufficient, is there any data that 
does come from registrars?

I mean, a lot of us want to build nice, neat 
systems.  And I'm sure anyone using the protocol 
would like something nice and neat.  But, are 
there material complaints against what we have 
now and a willingness to reinvest in achieving 
something nicer and neater.

I'll grant that having one universal solution is 
a nice and neat thing to have.  But I have yet to 
see that it is crucial to have "one" universal 
solution given my experience in operator arenas.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

When talking about a long day keep this in mind (found on wikipedia.org):

Because the earliest and latest time zones are 26 hours apart, any given
calendar date exists at some point on the globe for 50 hours.

---

From: Jothan Frakes <[email-masked]>
Date: Thu, 9 Jun 2011 14:31:51 -0700

> Why?

I think the answer varies.

Let's take the circumstance of a more recent registry service provider
(RSP) or ccTLD converting/evolving to EPP.

If one looks at the list of registrars at the following URL:
http://www.icann.org/en/registrars/accredited-list.html

You can break them down by RSP   I have not adjusted for marketshare
nor do I roll-up add storm 'thread-fleets', these are just the raw
listing of registrars.

.name,.jobs,.com,.net are on VeriSign
.aero, .asia, .info, .mobi, .org and .xxx are on Afilias
.biz, .travel, .tel are on Neustar

Look at rightmost column on that list and map the providers to the
registrar mix and the pattern appears clear.

Nearly everyone has .com integration (ie VeriSign).  Most have Afilias
and many are Neustar.

Anyway, unless volume of registrations and wider adoption of their
namespace is not a priority to them, a new RSP or ccTLD is  looking at
that URL and saying to themselves that they should make their system
work like one of these three providers.

> Why?

I'd also assert that even though Afilas, Neustar, and VeriSign have
been pioneers in the space, and I have had the privilege of working
with Scott and Jim to tell you that they're top notch, a company in
their position is not really going to have any commercial benefit from
adapting their EPP to that of the providers who have a smaller segment
of the overall list of registrars on that list.  That commercial
benefit is often the catalyst for funding projects and updating
things.

The 201X TLDs could be a vehicle... I'd say the exception to the above
is where there is a new implementation benefit or standard that
evolves, such as the effort to bring some uniformity to the
sunrise/landrush/go-live fields and phases that is currently under
way.  That kind of uniformity is of mutual benefit to all parties and
there is a bit of a level playing field because these all launch about
the same time in theory.

-Jothan

---

From: "Patrik Faltstrom (pfaltstr)" <[email-masked]>
Date: Thu, 9 Jun 2011 23:45:13 +0200

> work like one of these three providers.

Look at net::dri instead and _all_ registries and you get a more complete picture. The world is not gTLD only.

   Patrik

---

From: Bernie Hoeneisen <[email-masked]>
Date: Fri, 10 Jun 2011 10:39:53 +0200 (CEST)

Hi Ed et al.

On Thu, 9 Jun 2011, Edward Lewis wrote:

> A few messages back I mentioned that in meetings with some registries, doing 
> the work to increase commonality was judged to be "not worth it."  A response 
> on this list was that I was reporting something that was a sampling of a few 
> registries and not representative of registrars.
>
> My comeback (which I just didn't get around to asking until now) is the 
> registries do know at some level of familiarity, what registrars go through. 
> The relationship is more symbiotic than adversarial.

As you know, I was with you while talking to Registries about EPP 
improvements. And I came to a similar conclusion: Registries have little 
motivation to "change a running system". Registries don't appear to have a 
problem.

Registries are often those who set the policies and build the (EPP) 
systems, sometimes with proprietary EPP extensions. Registrars, on the 
other hand, usually have to cope with what they get and find ways around 
the resulting problems. However, those who suffer from such problems are 
Registars!

> And, as a challenge, if registries' opinion is not sufficient, is there 
> any data that does come from registrars?

I have not observed major Registrar participation in the IETF (or other 
fora where EPP is discussed), which I believe is a significant cause of 
the mess that happened with real-life "extended" EPP.

Does anybody know, why there are so few Registrars active in this field?
Any idea how to get more Registrars involved in EPP discussions?

cheers,
  Bernie

--

http://ucom.ch/
Tech Consulting for Internet Technology

---

From: "Wilhelm, Richard" <[email-masked]>
Date: Mon, 13 Jun 2011 17:07:59 -0400

There's at least one registrar here.

Thx

Rick

---

From: Mark Elkins <[email-masked]>
Date: Tue, 14 Jun 2011 07:59:32 +0200

> There's at least one registrar here.

...  quietly listening to the discussions!
  (.co.za team)

-- 
  .  .     ___. .__      Posix Systems - Sth Africa
 /| /|       / /__       [email-masked]  -  Mark J Elkins, Cisco CCIE
/ |/ |ARK \_/ /__ LKINS  Tel: +27 12 807 0590  Cell: +27 82 601 0496