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

["Gould, James" <[e-mail]>]

Hi,



I did a detailed review of draft-ietf-regext-simple-registration-reporting-06 and below is my feedback:



  1.  Introduction
     *   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”.
     *   Nit – “data element aforementioned data element registry” to “data element registry”.
  2.  Data Element Specification
     *   Nit – “printed report” could simply be “report”.  I don’t believe printed is relevant.
     *   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.
     *   Overall
        *   We need to ensure that only elements that are standard elements (non-proprietary) are pre-defined.
        *   We need to ensure to use a consistent naming convention.
        *   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
     *   Transaction_Type
        *   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?
     *   Object_Type
        *   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.
     *   DateTime
        *   Shouldn’t this be Date_Time to be consistent with the format of the other data elements?
     *   Term
        *   Why not use Period instead of Term to be consistent with the element used in EPP?
     *   Fee
        *   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.
     *   Status
        *   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?
        *   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”.
     *   Registrar
        *   There is the chance that the free-form registrar name could include the delimiter, so the use of quoting will be needed.
     *   Period
        *   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
     *   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.
     *   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.
     *   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.
     *   Trade
        *   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
     *   Start_Date
        *   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?
     *   RGP_Date
        *   RGP_Date is not descriptive enough.  I believe this should be Redemption_End_Date.
        *   Purge_Date

1.      This could be Pending_Delete_End_Date, which is when the purge occurs, and the domain becomes available.

     *   Where is Transfer_Date?
        *   I believe that all the dates in RFC 5731 should be supported at a minimum.
  1.  Registration Information Data Elements
     *   Registrar_ID
        *   You may want to separate Registrar_ID from IANA_ID or GURID to enable inclusion of both.
     *   Server_Registrant_ID
        *   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.
        *   My recommendation is to define a Registrant_ID element that should be defined by the client, per RFC 5733.
     *   Server_Contact_ID
        *   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.
        *   My recommendation is to define a Contact_ID element that should be defined by the client, per RFC 5733.
     *   In_Use
        *   How about using Linked, which matches the language used in RFC 5733?
     *   Nameserver_Host
        *   How about Host_Name to be in line with the naming in RFC 5732?
     *   Nameserver_IP
        *   How about Host_IP or Host_IPs to be in line with the naming in RFC 5732?
        *   How is the list of IPs handled in the report?
     *   Client_Contact_ID
        *   I recommend changing this to Contact_ID, which is assigned by the client (registrar), per RFC 5733.
  2.  Report Definition Specification
     *   “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.”
        *   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.
     *   I would not refer to them as “transaction rows”, but instead “record rows”.
     *   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.
     *   Domain Transaction
        *   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.
        *   Would it be good to include the domain ROID to uniquely identify the domain name instance?
        *   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.
        *   The Period, Term, Fee, and Currency will only apply to certain Transaction_Types.
        *   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.
        *   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.

     *   Premium Name
        *   What is the purpose of the Status element?
        *   What is the purpose of the Description element?  My recommendation is to remove this element unless there is a concrete reason for it.
        *   Can the Start_Date be described?
     *   Domain RGP
        *   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.
        *   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.
     *   Reserved Domain
        *   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?
     *   Domain Inventory
        *   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.
     *   Contact Inventory
        *   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?
        *   It’s not clear whether this report is generated per registrar and if it is why would the Registrar_ID element be needed.
        *   I don’t get the purpose of the Server_Contact_ID, since that doesn’t match RFC 5733.
        *   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.
        *   What is the purpose of the Contact_Type unless this is meant to represent the linkage of the domains to the contacts?
        *   Is the Registrar_ID associated with the Domain or the Contact.  I would assume the Contact, but I’m not sure.
     *   Host Inventory
        *   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