Re: [regext] Registry-Registrar Reporting

Tobias Sattler <sattler@united-domains.de> Fri, 08 November 2019 09:22 UTC

Return-Path: <sattler@united-domains.de>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44E4E120827 for <regext@ietfa.amsl.com>; Fri, 8 Nov 2019 01:22:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=united-domains.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9BUPZyPp14V for <regext@ietfa.amsl.com>; Fri, 8 Nov 2019 01:22:57 -0800 (PST)
Received: from falbalka.udag.de (intmail.udag.de [89.31.137.125]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A56DF1201DE for <regext@ietf.org>; Fri, 8 Nov 2019 01:22:56 -0800 (PST)
From: Tobias Sattler <sattler@united-domains.de>
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=united-domains.de; s=ud20150520; t=1573204973; bh=w7AZGwMhbywoqUN8pc6pr3iroJIQMeu0GHCt8yBd+R4=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=pIZqTt+C5oa86gNaIvD6vSDE6uT8gr9c1NImEcM2oWas6DrLiKpEUT0YoGx9Af/AK wPo/2/h7HVy8XECH6SiVYbC+0pVM87wOvgCuNsGIXFT3r3xZNxrnxW9JxPu7GSL/Xv Sd6YBqh1Q1tN3hmHfaP/Mr6iUSYIsUqdK9pTg9PWKnSlkk/DabjEhHYcP/agAYC5DZ iIVMsMXs3ArWGsKnKZcPwtm6wnsk+IUadmxomszJQ8uNQ+K2X66y4EBXHEefiodTax MgiK/2yQCw9RTtZAOLjq04/WurpI54Os8gGKR45HD0IJtFQipjF/pMOZ0tzGshVQcm ZxYQwmIb6B4qQ==
Message-Id: <B82FD3E7-F153-4C66-BE17-2D781292B4F6@united-domains.de>
Content-Type: multipart/alternative; boundary="Apple-Mail=_0EC11FBB-142A-4510-9201-725DB451CF04"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Fri, 08 Nov 2019 10:22:53 +0100
In-Reply-To: <BL0PR02MB5491A7F4EB7EEA75CD05F245B1790@BL0PR02MB5491.namprd02.prod.outlook.com>
Cc: "regext@ietf.org" <regext@ietf.org>
To: Roger D Carney <rcarney@godaddy.com>
References: <BL0PR02MB5491A7F4EB7EEA75CD05F245B1790@BL0PR02MB5491.namprd02.prod.outlook.com>
X-Mailer: Apple Mail (2.3445.104.11)
Authentication-Results: falbalka.udag.de; auth=pass smtp.auth=sattler smtp.mailfrom=sattler@united-domains.de
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/koLcd9O6jUfx5UWr8kalk0XniZM>
Subject: Re: [regext] Registry-Registrar Reporting
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Nov 2019 09:22:59 -0000

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 <rcarney@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