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

[Joseph Yee <[e-mail]>]

Hi Jim and all,

Please see my comment inline. The -07 should come out shortly or out
already.

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”.
>
> updated


>
>    1.
>       1.
>       2. Nit – “data element aforementioned data element registry” to
>       “data element registry”.
>
> updated


>
>    1.
>       1.
>    2. Data Element Specification
>       1. Nit – “printed report” could simply be “report”.  I don’t
>       believe printed is relevant.
>
> updated


>
>    1.
>       1.
>       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.
>
> Added text about naming convention.


>
>    1.
>       1.
>       2. 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.
>
> Agree as a general guideline, and *may* make exceptions on a case by
case basis.


>
>    1.
>       1.
>          1.
>       2. 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?
>
> [seeking more input] I intend to add the following paragraph under
'Transaction Type'.  Would love to hear more feedback before adding it.
"Well known and important transactions like restore where it was documented
inside EPP extension, and auto renew invoked by the registry system that
alter the domain's status are allowed."


>
>    1.
>       1.
>          1.
>       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.
>
> This seems to be getting into proprietary objects, or additional
information to the domain object, imo.


>
>    1.
>       1.
>          1.
>       2. DateTime
>          1. Shouldn’t this be Date_Time to be consistent with the format
>          of the other data elements?
>
> updated


>
>    1.
>       1.
>          1.
>       2. Term
>          1. Why not use Period instead of Term to be consistent with the
>          element used in EPP?
>
> Changed to 'Period', and the old Period (meant for unit) changed to
'Period_Unit'


>
>    1.
>       1.
>          1.
>       2. 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.
>
> I believe that balanceType is based on decimals.  I have not reviewed this
one fully.  Will revise after further review.


>
>    1.
>       1.
>          1.
>       2. 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”.
>
> Added text about multiple values, separated by comma, and enclosed them in
double quote as specified in RFC4180 (about csv)


>
>    1.
>       1.
>          1.
>       2. Registrar
>          1. There is the chance that the free-form registrar name could
>          include the delimiter, so the use of quoting will be needed.
>
> Added text about possible of having a comma in the string, and enclosed
them in double quote as specified in RFC4180 (about csv) if needed

>
>    1.
>       1.
>          1.
>       2. Period
>          1. Why not call this Unit to be consistent with the EPP term?
>          The term is reflected using the pUnitType in RFC 5731.
>
> Changed to 'Period_Unit' instead of just 'Unit'


>
>    1.
>       1.
>          1.
>       2. 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.
>
> Same feedback above.


>
>    1.
>       1.
>       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.
>
> Updated.

>
>    1.
>       1.
>
>
>    1.
>       1.
>       2. 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.
>
>
>
>    1.
>       1. Trade
>          1. Where is a trade defined?  The concept of a trade seems like
>          a proprietary feature that should be moved outside the draft.
>
> [seeking more input] for both proprietary command, sync and trade
Maybe expanding what's allowed in 'Transaction_Type' makes more sense?
Thoughts?


>
>    1.
>       1.
>          1.
>       2. 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.
>
Names updated.

>
>    1. Where is Transfer_Date?
>          1. I believe that all the dates in RFC 5731 should be supported
>          at a minimum.
>
> [seeking input]
I haven't added this one as it's not included in any report. Would love to
hear more from others of preference, and whether to add this to the report
(likely Domain Inventory report).


>
>    1.
>          1.
>       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.
>
> [seeking more feedback] Keep one or two? IMHO, it's redundant to keep
both. Would love to hear from others.
If we keep both, my preference is to name the non-IANA-ID one to
'Registrar_GUID'.
I'm keeping the name 'Registrar_ID' for now.



>
>    1.
>       1.
>          1.
>       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.
>
> I renamed this to just 'Registrant_ID'. This field is meant for mapping
the registrant ID shown in WHOIS/RDAP but has no indication of whether the
ID was issued by registry or registrar.  I have another two specific
contact ID data elements.


>
>    1.
>       1.
>          1.
>       2. 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.
>
> This referenced the ID from svTRID.


>
>    1.
>       1.
>          1.
>       2. In_Use
>          1. How about using Linked, which matches the language used in
>          RFC 5733?
>
> Updated.

>
>    1.
>       1.
>          1.
>       2. Nameserver_Host
>          1. How about Host_Name to be in line with the naming in RFC
>          5732?
>       3. 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?
>
> Updated.  Added text about multiple IP addresses separated by comma and
wrapped in double quotes.


>
>    1.
>       1.
>          1.
>       2. Client_Contact_ID
>          1. I recommend changing this to Contact_ID, which is assigned by
>          the client (registrar), per RFC 5733.
>
> This references the ID from clTRID.


>
>    1.
>       1.
>          1.
>       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.
>
> Although likely it's ordered by one of the column, we can't guarantee
that.  I updated it to 'each row is one record in the report'.

>
>    1.
>       1.
>          1.
>       2. I would not refer to them as “transaction rows”, but instead
>       “record rows”.
>
> Updated


>
>    1.
>       1.
>       2. 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.
>       3. 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.
>
> It helps the human reader.  Would love to get more feedback from others
whether to keep it or not.


>
>    1.
>       1.
>          1.
>          2. Would it be good to include the domain ROID to uniquely
>          identify the domain name instance?
>
> Would love to hear from others.  It's not that useful IMHO.  Would include
it if others find it useful in the report.


>
>    1.
>       1.
>          1.
>          2. 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.
>
> Discussed earlier about transaction_type above about 'restore' and
'autorenew'


>
>    1.
>       1.
>          1.
>          2. The Period, Term, Fee, and Currency will only apply to
>          certain Transaction_Types.
>
> Yes, some rows will have empty value. Do you want this draft to address
it, or just let RO to determine if and when they applied to what
transactions?


>
>    1.
>       1.
>          1.
>          2. 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.
>
> If nobody found them useful, I will remove them in the next iteration.


>
>    1.
>       1.
>          1.
>          2. 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.
>
This seems related to the EPP transactions/logs where I thought the report
to be about the record.


>
>    1. Premium Name
>          1. What is the purpose of the Status element?
>
>  Some names could be registered already.

>
>    1.
>          1.
>          2. What is the purpose of the Description element?  My
>          recommendation is to remove this element unless there is a concrete reason
>          for it.
>
> Could be additional information from the registry operator about the
premium name.

>
>    1.
>          1.
>          2. Can the Start_Date be described?
>
> This changed to Available_Date now. Of when the premium name is available
for registration.


>
>    1.
>          1.
>       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.
>
> Names updated.

>
>    1.
>          1.
>       2. 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?
>
> Similar to Premium Name.  It can be registered but still placed under the
reserve list.


>
>    1.
>          1.
>       2. 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.
>
> The latter one, specific to the registrar.
What other attributes do you think we need to include?


>
>    1. 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.
>
> It is for each registrar.  I removed 'Registrar_ID' from this report.


>
>    1.
>          1.
>          2. I don’t get the purpose of the Server_Contact_ID, since that
>          doesn’t match RFC 5733.
>
> svTRID


>
>    1.
>          1.
>          2. 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.
>
> The current design of this report has the many-to-many relationship. So
that it listed not only the contact object, but how it's being utilized
with the domain.
Would love to get more feedback from others on what the preference is.


>
>    1.
>          1.
>          2. What is the purpose of the Contact_Type unless this is meant
>          to represent the linkage of the domains to the contacts?
>
> admin/billing/tech, and yes, linkage to the domain


>
>    1.
>          1.
>          2. Is the Registrar_ID associated with the Domain or the
>          Contact.  I would assume the Contact, but I’m not sure.
>
> the latter one, associated with the contact object


>
>    1.
>          1.
>       2. 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”.
>
> Text added for it.

Best,
Joseph


>    1.
>          1.
>
>
>
>
>
> --
>
>
>
> 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
>