Re: Lists and EPP

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



On Thu, Jun 9, 2011 at 7:03 AM, Gould, James <[email protected]> wrote:
> 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 protected]
>
> 703-948-3271
> 21345 Ridgetop Circle
> LS2-2-1
> Dulles, VA 20166
>
> VerisignInc.com
>
>
>
>
> On 6/9/11 7:42 AM, "[email protected]" <[email protected]> wrote:
>
>>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
>>_______________________________________________
>>provreg mailing list
>>[email protected]
>>https://www.ietf.org/mailman/listinfo/provreg
>
> _______________________________________________
> provreg mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/provreg
>
_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg