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

[Joseph Yee <[e-mail]>]

Hi Jim,

Thanks for your feedback, and I am working on the revision (but also busy
from the day job).  Will send a follow up email with details about edits
and possibly questions for further discussion.

Thanks
Joseph



On Fri, Mar 25, 2022 at 10:44 AM Gould, James <jgould=
[e-mail]> wrote:

> Hi,
>
>
>
> I did a detailed review of
> draft-ietf-regext-simple-registration-reporting-06 and below is my feedback:
>
>
>
>    1. Introduction
>       1. I’m not sure whether there have been “a number of best practice
>       reports that have evolved”, but I do agree that there have been “a number
>       of best practices that have evolved”.
>       2. Nit – “data element aforementioned data element registry” to
>       “data element registry”.
>    2. Data Element Specification
>       1. Nit – “printed report” could simply be “report”.  I don’t
>       believe printed is relevant.
>       2. There is no definition of the format used for the data element
>       names (e.g., upper case, lower case, camel case, snake case).  The names
>       are inconsistent, but they primarily support the use of upper-case leading
>       words, with the use of underbars as a word separator.  My recommendation is
>       to formally define the expected data element names and ensure that all the
>       data element names follow the defined format.
>       3. Overall
>          1. We need to ensure that only elements that are standard
>          elements (non-proprietary) are pre-defined.
>          2. We need to ensure to use a consistent naming convention.
>          3. We need to look to support a candidate list of registration
>          elements that are in line with the elements defined and the naming
>          conventions used in the relevant EPP RFCs.
>       3. General Data Elements
>       1. Transaction_Type
>          1. How do you deal with extensions to the commands outlined in
>          RFC 5730, such as the restore request, restore response, or operations that
>          are not defined in RFC 5730, such as auto renew?
>       2. Object_Type
>          1. Since EPP extension can define a new object, then the
>          Object_Type also needs to be extensible, such as the definition of an Email
>          Forwarding, Defensive Registration, or NameWatch objects for .NAME.
>       3. DateTime
>          1. Shouldn’t this be Date_Time to be consistent with the format
>          of the other data elements?
>       4. Term
>          1. Why not use Period instead of Term to be consistent with the
>          element used in EPP?
>       5. Fee
>          1. I would reference the use of “decimal” for the format, since
>          referencing “balanceType” is unrelated to representing a fee.  The
>          “balanceType” is a decimal value to support a positive (fee) or negative
>          (credit) value, so referencing “decimal” is best.
>       6. Status
>          1. A status is an individual value.  How do you handle a report
>          that has more than one status?  Does that mean adding multiple rows to the
>          report, each with a different status value?  How do you handle representing
>          additional statuses, such as the RGP statuses?
>          2. My recommendation is to add a Statuses element that supports
>          a list of statuses that is an encoded element in double quotes, such as
>          “clientUpdateProhibited,clientRenewProhibited”.
>       7. Registrar
>          1. There is the chance that the free-form registrar name could
>          include the delimiter, so the use of quoting will be needed.
>       8. Period
>          1. Why not call this Unit to be consistent with the EPP term?
>          The term is reflected using the pUnitType in RFC 5731.
>       4. Domain Price Data Elements
>       1. Same feedback on the use of the unrelated “balanceType” in RFC
>       8748.  The recommendation is to simply refer to the type “decimal” to
>       support positive and negative values.  The alternative for fees is to only
>       support positive values with the “nonNegativeDecimal” type in RFC 8748,
>       since I don’t believe the price values should be negative.
>       2. I believe all the Price Data Element should include an
>       indication that it’s a price or a fee, such as prefixing “Price_” for each
>       of them.  So, it would be “Price_Domain_Create”, “Price_Domain_Renew”,
>       “Price_Domain_Transfer”, “Price_Domain_Restore”, and “Price_Domain_Trade”.
>       All the elements should include the object, since there are additional EPP
>       objects that support billable commands.
>       3. I assume that other billable commands could be supported by
>       defining new custom elements with the pattern “Price_”<Object>”_”<Command>,
>       such as the “Price_Domain_Sync” element for the proprietary sync command
>       defined in https://www.verisign.com/assets/consolidate-mapping.txt.
>
>       4. Trade
>          1. Where is a trade defined?  The concept of a trade seems like
>          a proprietary feature that should be moved outside the draft.
>       5. Timestamp Data Elements
>       1. Start_Date
>          1. Why not call this Available_Date to match its meaning?  Where
>          is this element used since it overlaps with the Purge_Date element for
>          domains in RGP?
>       2. RGP_Date
>          1. RGP_Date is not descriptive enough.  I believe this should be
>          Redemption_End_Date.
>          2. Purge_Date
>
> 1.      This could be Pending_Delete_End_Date, which is when the purge
> occurs, and the domain becomes available.
>
>    1. Where is Transfer_Date?
>          1. I believe that all the dates in RFC 5731 should be supported
>          at a minimum.
>       1. Registration Information Data Elements
>       1. Registrar_ID
>          1. You may want to separate Registrar_ID from IANA_ID or GURID
>          to enable inclusion of both.
>       2. Server_Registrant_ID
>          1. Where is a server registrant ID defined?  RFC 5733 defines
>          the use of client assigned identifiers.  This is a proprietary feature that
>          should be moved outside the draft.
>          2. My recommendation is to define a Registrant_ID element that
>          should be defined by the client, per RFC 5733.
>       3. Server_Contact_ID
>          1. Where is the contact ID defined?  RFC 5733 defines the use of
>          client assigned identifiers.  This is a proprietary feature that should be
>          moved outside the draft.
>          2. My recommendation is to define a Contact_ID element that
>          should be defined by the client, per RFC 5733.
>       4. In_Use
>          1. How about using Linked, which matches the language used in
>          RFC 5733?
>       5. Nameserver_Host
>          1. How about Host_Name to be in line with the naming in RFC
>          5732?
>       6. Nameserver_IP
>          1. How about Host_IP or Host_IPs to be in line with the naming
>          in RFC 5732?
>          2. How is the list of IPs handled in the report?
>       7. Client_Contact_ID
>          1. I recommend changing this to Contact_ID, which is assigned by
>          the client (registrar), per RFC 5733.
>       2. Report Definition Specification
>       1. “The remaining rows of the file are the unordered sets of data
>       elements, one set per row, where each row is one transaction in the report.”
>          1. The data elements are ordered based on the order defined in
>          the header row.  Each row is a record and not a transaction in the report.
>       2. I would not refer to them as “transaction rows”, but instead
>       “record rows”.
>       3. High-level, each report definition needs to include a
>       description of the report that defines its purpose.  I assume the frequency
>       of the report would be up to server policy.  As noted in a prior message on
>       the list, I believe the draft needs to focus only on the framework and not
>       the concrete reports.  The first step is to have the capability to formally
>       define the existing reports in a consistent manner and have the reports
>       follow some predefined requirements.
>       4. Domain Transaction
>          1. I would only include the Registrar_ID in place of including
>          the verbose Registrar for all the transactions, since there could be a very
>          large set of transactions and the Registrar Name can be derived from the
>          Registrar_ID when needed.
>          2. Would it be good to include the domain ROID to uniquely
>          identify the domain name instance?
>          3. The Transaction_Type values will need to support a broader
>          set of types.  We need to take a closer look on how to handle extensibility
>          of Transaction_Type values, since transactions that the registrar does not
>          recognize can be ignored, but at least they have the information available.
>          4. The Period, Term, Fee, and Currency will only apply to
>          certain Transaction_Types.
>          5. I’m not exactly sure what the purpose is for the Description
>          for an automated report that can have many transaction records.  I
>          recommend removing the Description unless there is a driving use case for
>          it.
>          6. Additional element to consider:
>
> 1.      Session_ID, Updated_By (could match to Registrar_ID where the
> Updated_By is more fine-grained to an individual user), ROID (Instance of a
> domain name), Parent_Transaction_ID if there is a composite transaction.
>
>    1. Premium Name
>          1. What is the purpose of the Status element?
>          2. What is the purpose of the Description element?  My
>          recommendation is to remove this element unless there is a concrete reason
>          for it.
>          3. Can the Start_Date be described?
>       2. Domain RGP
>          1. I assume that is all domain names in RGP.  Are domain names
>          that are pendingRestore included in this report or only domain names in the
>          RGP redemptionPeriod or pendingDelete?  A description of the purpose of the
>          report and what domain names are included would help.
>          2. As noted previously, the RGP_Date should be named to
>          something like Redemption_End_Date and Purge_Date should be named to
>          something like Pending_Delete_End_Date.
>       3. Reserved Domain
>          1. How does a reserved domain name have a Status since it should
>          be reserved?  Is the Status meant to indicate whether the reserved domain
>          exists or not, which could happen if an existing domain name is added to
>          the reserved list?
>       4. Domain Inventory
>          1. Is this the entire inventory of domain names replicated to
>          all registrars or is it a registrar-specific report for domains under
>          management?  Based on the elements shown, it looks more like a report used
>          to assist with name spinning than a report to support reconciliation of
>          domain data in the registrar database with the registry database.  The name
>          spinning use case would include the same inventory report to all
>          registrars, and the reconciliation use case would need to include more
>          attributes to fully support syncing the data.
>       5. Contact Inventory
>          1. There is a need for a description of the purpose of the
>          report, since it’s unclear whether this is generated per registrar and if
>          so, which contacts are included.  Is it all the contacts that is sponsored
>          by the registrar of the report or is it all contacts linked to domain names
>          sponsored by the registrar of the report?
>          2. It’s not clear whether this report is generated per registrar
>          and if it is why would the Registrar_ID element be needed.
>          3. I don’t get the purpose of the Server_Contact_ID, since that
>          doesn’t match RFC 5733.
>          4. I don’t get Domain since a contact can be linked to many
>          domain names.  My recommendation is to remove the Domain element for the
>          many-to-many relationship between domains and contacts.
>          5. What is the purpose of the Contact_Type unless this is meant
>          to represent the linkage of the domains to the contacts?
>          6. Is the Registrar_ID associated with the Domain or the
>          Contact.  I would assume the Contact, but I’m not sure.
>       6. Host Inventory
>          1. I recommend changing the Nameserer_Host to Host_Name, and the
>          Nameserver_IP to Host_IPs.  The IPs can be a list, so the element should be
>          defined to support a list, with the assumption that they are included in
>          double quotes as in “192.0.2.2,192.0.2.29,1080:0:0:0:8:800:200C:417A”.
>
>
>
>
>
> --
>
>
>
> JG
>
>
>
>
>
>
>
> James Gould
>
> Fellow Engineer
>
> [e-mail]
> <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>
>
>
>
> 703-948-3271
>
> 12061 Bluemont Way
>
> Reston, VA 20190
>
>
>
> Verisign.com <http://verisigninc.com/>
>
>
>
> On 3/7/22, 6:14 PM, "regext on behalf of [e-mail]" <
> [e-mail] on behalf of [e-mail]> 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-06.txt
>
>                 Pages           : 34
>
>                 Date            : 2022-03-07
>
>
>
>     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/1tuLsav6fXdwNwkI2hRgrcTAmGb46y63uhOddhrLcnDRGZ04vkpVWG6XoEjQ8_x2s_P_iQdnjHFea6CHfHkUea9osOV_kHBtQMFGIxT45AwpWJh9IA-C4bv530agFP_80lDJgaDI3nUgVmG3hvcyjKL6BfO3xU7UdsNlCTPpck9A7fEvmanTd-eu4x0g-N0r03uLNUmz0F-PgkmjOmwJokxKJYjvUEOokgBsMlZfUnF45hnDd16y5xfYS3qoPA_JL/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/1cxkfGzIwwaxtrPBc-dKkzTbrcM43rhKbUcgKnf4ju60UpDfHrfFurvadAKy0HYgtE8JPliw0q9wk-4yhfizxiU0C9ax9YTm50fwsT_HLO7i6Ziivb8mMUatBWzHgKF1KmXqVhYBeqkq8qWurYZJiexEGtpN8U5rG3agQe9aMpX3tdJcv6v8OAHLFqMSnwQhFiUz9gqtdugbT5HzzZZT6PSNHPgUuTkpB7ip3gjdPHXcizW_RFsz70xqT-k5jkQ4r/https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-regext-simple-registration-reporting-06.html
>
>
>
>     A diff from the previous version is available at:
>
>
> https://secure-web.cisco.com/1teV5_jYUfeW36P3uKs-wspFDm4tcZ3UcJREdHCcRKa1FyVsVaWoYz8HQ7TpgpTwJEWNlZHTuqMjOuY4PBr8qrbjZgiwD3-W0TydVlriSfv0cfMT0sE9tAAbmyTuZW5GL6R5NSxkF1xkAFOaTaBc08zroZa5Hb7fW8Zr1A_LsAfWvP8gU5LrKQp_MXoPiSZnq06QFiklpvqkq-EJNSExS4aYBCuMWha3oqkK64W48o98SVZpmMKuIXorVAWTbCZIm/https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-regext-simple-registration-reporting-06
>
>
>
>
>
>     Internet-Drafts are also available by rsync at rsync.ietf.org:
> :internet-drafts
>
>
>
>
>
>     _______________________________________________
>
>     regext mailing list
>
>     [e-mail]
>
>
> https://secure-web.cisco.com/1TWl_oSRF_6eFhgvki-ekeEEj_SaNZQscbHffcoWm5-7LPs33AxYAh6Dw1XyY-mzQLxkWiJF5mjSqCa6f0rTnKSmyYg_ytTWYAWt9Vwlfk0bfDfb0cCqdkm_bLYOWePsWzHqIB3SJEppnIYca5RbTb0Dweh83zA8VNM4wkq_aF5TsgAYjKpRf8VAPCCADGpsQ5eCHsgTIefjUQJIEXgUNIf11pBPngYHc-8DQ4tYshc7RyzLoVu7QiG0FzsKuni69/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext
>
>
> _______________________________________________
> regext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/regext
>