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

From: "Gould, James" <[email-masked]>
Date: Wed, 14 Jul 2021 12:17:39 +0000

In reviewing the changes made to draft-ietf-regext-simple-registration-reporting-04, I have the following feedback:

1. The sentence "Each report definition MUST use only the data elements defined in the data element aforementioned data element registry, including all future reports." could be simplified to something like "Each registered report definition [4.1.2.1.2] MUST only use the registered data elements [4.1.2.1.1]".
2. The sentence "Note that a produced report MAY include data elements that are not registered, as described below" is a little confusing.  Is there a difference between the definition of a report definition and a produced report?  I imagine that a produced report may follow a non-registered report definition, since there will be many additional reports produced for registrars.  If that is the purpose of the sentence, then it may help to clarify the different types of reports (e.g., registered reports, registered report extensions, custom reports):
   a. registered reports - Reports produced that contain the exact set of data elements in a registered report definition.
   b. registered report extensions - Reports produced that contain the set of data elements in a registered report definition with additional appended data elements.  Is it possible to add data elements without having to register a new report definition?
   c. custom reports - Reports produced that don't have a registered report definition.  The report definition may be defined outside of the report definition registry.  
3. The naming of the data elements are inconsistent, where all but one (DateTime) use snake case with the use of an upper case letter for words (e.g., "Transaction_Type") and "In_use" doesn't use an uppercase Use, as in "In_Use".  My recommendation is to define the data element name approach to use, where word separation is done with a underscore ('_'),  acronym words are all upper case (e.g., "TLD"), and non-acronym words start with an uppercase character followed by lowercase characters (e.g., "Domain").  Having a pre-defined format used for data element names will help.
4. As previously stated, I think that the draft should define a report framework and not include the concrete report definitions (that leverage the framework).  Having a standard set of data elements makes sense, along with the registration process for data elements and report definitions.  But the structure of the actual reports are reflections of business decisions about what data elements should be included or excluded.  And thus are both variable in certain business contexts and also variable over time.  In contrast, the definition of data elements along with a registration process for report definitions is inherently flexible over time and adaptable across business contexts.   Limiting the scope to the framework should prove a lot simpler to agree upon.
5. The status field values for the Data Element Definition (4.1.2.1.1) and Report Definition (4.1.2.1.2) need to be defined, with the current values of active, inactive, and unknown.  It's unclear how to choose between the values.  I like the Document Status definition used in https://datatracker.ietf.org/doc/html/rfc7451#section-2.2.1 for EPP Extensions, where you may have "Informational" or "Standards Track" values.

-- 
 
JG

James Gould
Fellow Engineer
[email-masked] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email-masked]>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com <http://verisigninc.com/>

On 7/12/21, 6:40 PM, "regext on behalf of [email-masked]" <[email-masked] on behalf of [email-masked]> 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-04.txt
    	Pages           : 35
    	Date            : 2021-07-12

    Abstract:
       Domain name registries (the producer) and registrars (the consumer)
       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 a 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
       distribution of and access of the files is a matter of local policy.

    The IETF datatracker status page for this draft is:
    https://secure-web.cisco.com/1Q6pzLYG4781m7qj4VNwYC0BxrM1HV-2AqACUjG8L40CUjK0VeBOg26lZxF4LdTo5NH77PTZoz5gLXWYV9uyT1t1zALN8mFzlZKAnV1vgbNP1bGHGRJc90MDwMUeugyfSoLBE7KXubZAbpG-O0tP3q_zDnb2Xwkd8cx9L6uCqaGIsB3cMb079j3k0GeQUgCXaRkdds-YwzaGcf2cfuIJ6pA1VVOzV8HT-td-RjfC3gZuoHPK57G13Pue-cat4t_1HIXqEqcsH7U1UBiog7zMctw/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-simple-registration-reporting%2F

    There is also an HTML version available at:
    https://secure-web.cisco.com/1ehXigt8aRnBMseDzGr4ZsGOK_M81stnxr9NJe3KnQQ6MMGS0WwqkuBTyL5m4cs0PsfKpz1Hrn8RinMQ-l41VuCgwB-95cnQr4vP9Ra6oiz5Z3WCKMFPioGLZHfZ0HQZ_HRxjYp_G8v9rQg-kgVdzLw1qnhSycVwPt3YCF3W6drw13u7TTsHkC_1JWlvf97G-ADE_sRPb8b1DC1Cd_2ELnCAx2SgWYfM8rr30DPsjTulzDxPMjd9UnUzYt-BbBHB50vz50g30g2pdQYMAjc14Ig/https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-regext-simple-registration-reporting-04.html

    A diff from the previous version is available at:
    https://secure-web.cisco.com/1fzujF6x8UeJ4OwokT2gMh7InbWzPD-tEcr1Ywpo_QkKhYyIC3wXeheqnzAviCxXQRJlM8qks96_LeuZTjROFxy1StlVHtBJCXNzicWC1KTd_3WHzZ1mT-Q_ppjHGbm4npCfITdSHf68MF5yKvj7dFYheP6TIeqWiGjUdm4n0bD3m7xTzvaJyPBbkzJIfhoUMEraQPmw9ejKDz5Z7r732EGYhHX9dMTws4fvqenU3WRPnrW-JJeImi5yMbt_s8irrNXGnSHw2U0wj6XkO7kJvSg/https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-regext-simple-registration-reporting-04

    Internet-Drafts are also available by anonymous FTP at:
    ftp://ftp.ietf.org/internet-drafts/

    _______________________________________________
    regext mailing list
    [email-masked]
    https://secure-web.cisco.com/1HaXpYgkSaTyhpYJUj7cSXKGiVW_G2KDy2gr9qQm3jpX2H4hOa6YAqAD7AT3t_GBxH-nhTdS7Vtewo94pmAaPGyBL84zxyEzvIjdZtOKaejT9w604jpwFBMSiTBNb3pRASURRHEwnMe9Daf8Flys1u9sCc_nrd-rov78CkUnQtfo3BFgSaAWm3sNM4b6Y_ST6L1quSK3IjEigdu1OanMWhlXvupvluSE5Qqml1rxFvnhQrC0nljIgm2AaNNgmzWjLiwT3xE0A5cRaQ3RyZLllVQ/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext

---

From: Tobias Sattler <[email-masked]>
Date: Wed, 14 Jul 2021 22:23:01 +0200

Hi Jim,
Hi Joseph,

On Jim's item 4, I understand that there may be different approaches and preconditions for a producer to provide such reports; however, this is an informational draft and not on standards track. What do you think about framing Section 3 as Example Reports instead? That way, you can provide examples of how some reports can look, but it is not necessarily fixed if a producer decides to do it differently.

Best,
Tobias

> On 14. Jul 2021, at 14:17, Gould, James <jgould=[email-masked]> wrote:
> 
> https://www.ietf.org/mailman/listinfo/regext