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=40verisign....@dmarc.ietf.org> wrote:
>
> 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
> jgo...@verisign.com
> <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com>
>
> 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 internet-dra...@ietf.org"
> <regext-boun...@ietf.org on behalf of internet-dra...@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-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
> regext@ietf.org
>
> https://secure-web.cisco.com/1HaXpYgkSaTyhpYJUj7cSXKGiVW_G2KDy2gr9qQm3jpX2H4hOa6YAqAD7AT3t_GBxH-nhTdS7Vtewo94pmAaPGyBL84zxyEzvIjdZtOKaejT9w604jpwFBMSiTBNb3pRASURRHEwnMe9Daf8Flys1u9sCc_nrd-rov78CkUnQtfo3BFgSaAWm3sNM4b6Y_ST6L1quSK3IjEigdu1OanMWhlXvupvluSE5Qqml1rxFvnhQrC0nljIgm2AaNNgmzWjLiwT3xE0A5cRaQ3RyZLllVQ/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext
>
>
> _______________________________________________
> 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
