Re: [regext] I-D Action: draft-ietf-regext-simple-registration-reporting-02.txt

Tobias Sattler <sattler@united-domains.de> Tue, 23 February 2021 13:54 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 59CC23A2B34 for <regext@ietfa.amsl.com>; Tue, 23 Feb 2021 05:54:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.798
X-Spam-Level:
X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Y60kUL1nNG94 for <regext@ietfa.amsl.com>; Tue, 23 Feb 2021 05:54:38 -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 EE5E93A2AF0 for <regext@ietf.org>; Tue, 23 Feb 2021 05:54:37 -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=1614088475; bh=g2xuKiqBVIxsP3zHqYKyMgUp17od2zOwV4iX0tmyhzk=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=pOomkqFgHHbfHJQ2gwb00QjhwGcj66yXld7Cwi1EcppHJIz28sSHqeavk8wPWKvhQ F8Sk/c7pcH5dBD5XTHqwtvpTpzJ6jN6vkLQgvJOpNBXV6E1rizmlPNzgnvJ8SnOEor 8Ig1ENtABBeHZWfVi8bOtPwNhLPiTelLBcQ6Y4uZLT6HBdaBC676IVGMrVi2zLii8R gfpVRw1j4V5OONVY/6gzDEevG8D6ameBSG6HIAmPTDd4DI49c/yyQZUffh/JlM3uRp g4rF6kTLUIOWRRYNpIpK2Alw1OF7yYBz2kYmVb4w0o8ofeB8vdkUoD+7peMswHNfKd O93jKOAi9d15A==
Message-Id: <5B4D85D7-B62E-40ED-AB3B-98C7860A4E7D@united-domains.de>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A6D9FB2A-1FAB-4CF3-9FA5-63BCCD5B8360"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Tue, 23 Feb 2021 14:54:34 +0100
In-Reply-To: <CAF1dMVFsz9sHLUqYHbm-9_i=RTVO6eXXFb6cvoy06ieZ=9=bOg@mail.gmail.com>
Cc: regext <regext@ietf.org>
To: Joseph Yee <jyee@afilias.info>
References: <160435567753.30792.18339953573358178721@ietfa.amsl.com> <69619A4B-1586-4AC8-BF45-9906435563C2@united-domains.de> <CAF1dMVFsz9sHLUqYHbm-9_i=RTVO6eXXFb6cvoy06ieZ=9=bOg@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
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/k4tEvgbp-O_gWpbcwZSHAVx9W2I>
Subject: Re: [regext] I-D Action: draft-ietf-regext-simple-registration-reporting-02.txt
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: Tue, 23 Feb 2021 13:54:40 -0000

Hi Joseph,

Thank you for the update.

Please find my comments inline.

Best,
Tobias

> On 22. Feb 2021, at 23:57, Joseph Yee <jyee@afilias.info> wrote:
> 
> Hi Tobias,
> 
> Many thanks for your feedback. Please see comments inline
> 
> 
> On Tue, Nov 3, 2020 at 8:44 AM Tobias Sattler <sattler@united-domains.de <mailto:sattler@united-domains.de>> wrote:
> Hi Joseph,
> Hi Jim,
> 
> Thanks for updating this draft.
> 
> Some thoughts and comments from my side:
> 
> General thoughts
> This document is intended to be informational. Therefore, I think it is better to avoid the word “standard” in the text. Because it would seem to be a de facto standard. I think that someone might be irritated by this later.
> I vaguely recalled that some suggested changing this to BCP.  Can't find it in the minutes. I keep 'informational' with words 'standard' around for now. Will update on future revisions depends on which way the draft will go.
>  
> 
> Abstract
> I would open it up and write about Registries, Registrars, and Resellers.
> I add the words 'producer' and 'consumer' next to the term registry operator and the registrar respectively. Would the intro section be better for the elaboration? 
> 

TS: Looks good to me.

>  
> 
> 1. Introduction
> I would define “the producer” and “the consumer” by using the example Registries and Registrars as well as Registrars and Resellers. And reference later on only to producer and consumer.
> But wouldn't registrar be a better understanded term?

TS: True, however, this document can be used for reports from Registries to Registrars as well as from Registrars to Resellers. Or maybe even the other way around. There might be multiple ways of using it. Therefore, it may make sense to broaden it and to use generic terms, such as producer and consumer.

>  
> 
> 2. Data Element Specification
> I am missing the character encoding. You are mentioning it in section 7. I would add a reference in section 2 to 7.
> Done.

TS: Confirmed.

>  
> 
> 2.1.11 Registrar
> If you open it up to Resellers, then I would rename it to Consumer.
> Would expanding the definition be better? I haven't made any changes to it, want to discuss more on this first.
>  
> 
> 2.2.5. Trade
> I would add the field trade here, which is not uncommon in the ccTLD world. Just to have it right from the start.
> Added.  Do you know if some ccTLD operators use a custom EPP command on trade (to domain object)? Or it's domain update with a new contact object where the registry operator charges on this specific transaction?

TS: I’ve seen multiple implementations some of them not based on EPP either. So I don't think it's wrong to have that in there.

>  
> 
> 2.4.1. Registrar_ID
> If you open it up to Resellers, then I would rename it to Consumer_ID
> Same as Registrar_ID.
>  
> 
> 3. Report Definition Specification
> After reading it, it is not 100% clear to me, what the delimiter is and if the values should be enclosed with (single or double) quotes.
> We referenced RFC4180 regarding CSV.  The source mentioned double quotes.

TS: Confirmed.

>  
> 
> Appendix A. Acknowledgment
> There is a typo in bestpractices.domains. It is bestpractice.domains without a “s".
> Fixed.  thanks.
> 
> The next revision will incorporate the changes mentioned above. And would love to discuss more on items I haven't made changes to.
> 
> Best,
> Joseph
>  
> 
> 
> Best,
> Tobias
> 
> > On 2. Nov 2020, at 23:21, internet-drafts@ietf.org <mailto:internet-drafts@ietf.org> wrote:
> > 
> > 
> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> > This draft is a work item of the Registration Protocols Extensions WG of the IETF.
> > 
> >        Title           : Simple Registration Reporting
> >        Authors         : Joseph Yee
> >                          James Galvin
> >       Filename        : draft-ietf-regext-simple-registration-reporting-02.txt
> >       Pages           : 33
> >       Date            : 2020-11-02
> > 
> > Abstract:
> >   Domain name registries and registrars report to each other by sharing
> >   bulk information through files.  This document creates two IANA
> >   registries to establish a standard reporting mechanism between domain
> >   name registries and registrars.  The first IANA registry lists
> >   standard data elements and their syntax for inclusion in the files.
> >   The second IANA registry lists standard reports based on the standard
> >   data elements.  Each report is a file formatted as a CSV file.  The
> >   advantage of this reporting mechanism is that report, each file, can
> >   be imported by recipients without any prior knowledge of their
> >   contents, although reporting is enhanced with a minimum of knowledge
> >   about the files.  The mechanism for the transmission and reception of
> >   the files is a matter of local policy.
> > 
> > 
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-regext-simple-registration-reporting/ <https://datatracker.ietf.org/doc/draft-ietf-regext-simple-registration-reporting/>
> > 
> > There is also an HTML version available at:
> > https://www.ietf.org/archive/id/draft-ietf-regext-simple-registration-reporting-02.html <https://www.ietf.org/archive/id/draft-ietf-regext-simple-registration-reporting-02.html>
> > 
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-simple-registration-reporting-02 <https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-simple-registration-reporting-02>
> > 
> > 
> > Please note that it may take a couple of minutes from the time of submission
> > until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
> > 
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
> > 
> > 
> > _______________________________________________
> > regext mailing list
> > regext@ietf.org <mailto:regext@ietf.org>
> > https://www.ietf.org/mailman/listinfo/regext <https://www.ietf.org/mailman/listinfo/regext>
> 
> _______________________________________________
> regext mailing list
> regext@ietf.org <mailto:regext@ietf.org>
> https://www.ietf.org/mailman/listinfo/regext <https://www.ietf.org/mailman/listinfo/regext>