Hi Roger, Thank you for your email and the summary.
It was great to see so many people attending the last ICANN meeting, the CPH TechOps session, and the joint meeting with REGEXT. As one of the authors of the current version of the Reporting Repositories – we deliberately avoid the Registry suffix as it makes sense for resellers as well – I think we should recall why we started this project. Registrars can obtain reports from registries that are difficult to automate right now. So two years ago, the idea came up to standardize them and try to create a Quick Win. The current proposal fulfills this requirement but seems to be limited due to possible further developments. The new proposal to solve this via two new IANA registries may take this limitation into account, but at least for me, it feels like an overkill. If the current number of drafts are an issue, then I think, we could condense them down to achieve a similar result. If the BCP is an issue, then we can still change it to Informational. Irrespective of the structure and the resulting content, the new proposal contains no procedure for distributing the reports. Although there may be different reasons for this, we should not lose sight of it. It wouldn't be much of a gain if we ended up with reports, but they were distributed over all kinds of protocols (FTP, SFTP, FTPS, HTTPS, REST, email). That hardly results in any simplification. Therefore, I would like to ask you to consider whether there might not be a simpler and faster solution. Best, Tobias > On 6. Nov 2019, at 23:48, Roger D Carney <rcar...@godaddy.com> wrote: > > Good Afternoon, > > I took an action item out of the Interim REGEXT Meeting held 03NOV2019 in > regards to the Registry-Registrar Reporting discussion. > > We discussed, for almost two hours, several proposals around standardizing > Registry-Registrar Reports. Roughly there were three proposals: > · Column/Report Registry – Create two (2) first come first serve > registries at IANA to contain the industry agreed standardized 1) column > names and definitions and 2) Report Name and column mappings. This was a new > proposal presented at the Interim Meeting. > · Best Practice – Define each standard report as an RFC. Over the past > year or so there have been several drafts created to document proposed > reporting standards between Registries and Registrars. > (draft-mcpherson-sattler-report-structure > <https://datatracker.ietf.org/doc/draft-mcpherson-sattler-report-structure/>, > draft-mcpherson-sattler-reporting-repository > <https://datatracker.ietf.org/doc/draft-mcpherson-sattler-reporting-repository/>, > draft-mcpherson-sattler-transaction-report > <https://datatracker.ietf.org/doc/draft-mcpherson-sattler-transaction-report/>, > draft-sattler-premium-domain-fee-report > <https://datatracker.ietf.org/doc/draft-sattler-premium-domain-fee-report/>, > draft-sattler-domain-inventory-report > <https://datatracker..ietf.org/doc/draft-sattler-domain-inventory-report/>, > draft-sattler-domain-drop-list-report > <https://datatracker.ietf.org/doc/draft-sattler-domain-drop-list-report/>, > draft-sattler-unavailable-domain-report > <https://datatracker.ietf.org/doc/draft-sattler-unavailable-domain-report/>, > draft-sattler-contact-inventory-report > <https://datatracker.ietf.org/doc/draft-sattler-contact-inventory-report/>). > · Dataset File Format – A proposed format that can be used to define > and pass bulk data between Registry-Registrar. There was some discussion on > possible modifications that would possibly allow report definition and > delivery (draft-gould-regext-dataset > <https://datatracker.ietf.org/doc/draft-gould-regext-dataset/>). > > To provide focus and eliminate as much duplicate effort as possible, I would > propose that the WG proceed with the Column/Report Registry concept; remove > (from the REGEXT backlog) the internet drafts created under the Best Practice > concept; and continue with the Dataset File Format for bulk operations but > not be used/modified for these standard reports. > > For discussion details please see the meeting notes (coming soon). > > > Thanks > Roger > > _______________________________________________ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
