Re: Lists and EPP

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
Principal Software Engineer
[email protected]

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

VerisignInc.com




On 6/9/11 1:42 PM, "Jothan Frakes" <[email protected]> wrote:

>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